From dime-bounces@ietf.org Thu Mar 01 01:44:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMf15-00067m-Sv; Thu, 01 Mar 2007 01:43:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMf14-00067e-Ln for dime@ietf.org; Thu, 01 Mar 2007 01:43:50 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMf0y-0007ub-Mg for dime@ietf.org; Thu, 01 Mar 2007 01:43:50 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DDFE6204FD; Thu, 1 Mar 2007 07:43:33 +0100 (CET) X-AuditID: c1b4fb3c-a81bbbb000004e66-76-45e676155499 Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id B9723203E0; Thu, 1 Mar 2007 07:43:33 +0100 (CET) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 07:43:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Dime] RE: DCCA Date: Thu, 1 Mar 2007 07:43:32 +0100 Message-ID: In-Reply-To: <45E58905.8070600@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: DCCA Thread-Index: AcdbWMmwgAy1b0V8TLyhUxcbyha50QAc840w From: "Patrik Teppo \(KA/EAB\)" To: "Liyaqatali" , "Tolga Asveren" X-OriginalArrivalTime: 01 Mar 2007 06:43:33.0427 (UTC) FILETIME=[EE630030:01C75BCC] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 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="===============0419532179==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0419532179== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C75BCC.EE3EEA6F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C75BCC.EE3EEA6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 RFC 4006 section 8.17: A client is not required to implement all the unit types, and it must treat unknown or unsupported unit types in the answer message as an incorrect CCA answer. In this case, the client MUST terminate the credit-control session and indicate in the Termination-Cause AVP reason DIAMETER_BAD_ANSWER. =20 So the client must terminate if it can't handle the granted quota. =20 BR, Patrik ________________________________ From: Liyaqatali [mailto:a21917@motorola.com]=20 Sent: den 28 februari 2007 14:52 To: Patrik Teppo (KA/EAB); Tolga Asveren Cc: dime@ietf.org Subject: Re: [Dime] RE: DCCA There couple of scenarios. According to the sec 4.2.1.1 of the test suite used as a reference for the interop (http://tools.ietf.org/html/draft-fajardo-dime-interop-test-suite-04), in the first test case the client is not supposed to add Requested-Service-Unit AVP in the initial CCR. In this case the DCCA server can send back a CCA and have, say, more than one unit types included in Granted-Service-Unit AVP.=20 And according to RFC 4006, if the client is does not know the cost of the service it can request in terms of service events and if the client requests in time and if the service context at the server says that both Money and time are the supported unit types then the server might send back a CCA with both time and money.=20 Is there something that I am missing? Regards, Liyaqatali G Nadaf Patrik Teppo (KA/EAB) wrote:=20 Hi all, =09 If the DCC client is implemented to only handle cc-time then it can't measure money and report back USU/CC-Money. =09 The service-context should define which unit types that shall be used and in the case below there is a configuration error for the specific service-context. =09 BR, Patrik=20 =09 -----Original Message----- From: Tolga Asveren [mailto:asveren@ulticom.com]=20 Sent: den 26 februari 2007 17:35 To: Liyaqatali; dime@ietf.org Subject: [Dime] RE: DCCA =09 Hi Liyaqatali, =09 In the scenario you described, I would expect the client to report used units only in time. It does not have the knowledge to do the translation between time and money. =09 I couldn't think of a scenario, why the server would use both cc-time and cc-time in the answer. Does anybody have any idea about that? What could be the reason to do so? =09 Thanks, Tolga =09 -----Original Message----- From: Liyaqatali [mailto:a21917@motorola.com] Sent: Friday, February 23, 2007 4:42 AM To: dime@ietf.org; Tolga Asveren Subject: DCCA =09 =09 =09 Hi =09 Couple of questions. In RFC 4006, sec 5.2 which states "If several unit types are sent in the Answer message, the credit-control client MUST handle each unit type separately." What does it it actual mean to handle it separately? =09 Suppose the client requests some units in time but the server grants both in time and money i.e. server adds cc-time and cc-money avps in the granted service units AVP then how is the client suppose to handle this? if client can understand only time then? Should the client request and report used units in both time and money or is it fine to report in either ? =09 I would really appreciate if you can help me out here. =09 -- Regards, Liyaqatali G Nadaf =09 =09 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime =09 =20 ------_=_NextPart_001_01C75BCC.EE3EEA6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
RFC=20 4006 section 8.17:
A=20 client is not required to implement all the unit types, and it must = treat=20 unknown or unsupported unit types in the answer message as an incorrect=20 CCA answer.  In this case, the client MUST terminate the=20 credit-control session and indicate in the Termination-Cause AVP=20 reason DIAMETER_BAD_ANSWER.
 
So the=20 client must terminate if it can't handle the granted = quota.
 
BR,
Patrik

From: Liyaqatali = [mailto:a21917@motorola.com]=20
Sent: den 28 februari 2007 14:52
To: Patrik Teppo = (KA/EAB);=20 Tolga Asveren
Cc: dime@ietf.org
Subject: Re: [Dime] = RE:=20 DCCA



There couple of scenarios.

According to the = sec=20 4.2.1.1 of the test suite used as a reference for the interop (http://tools.ietf.org/html/draft-fajardo-dime-interop-test-suite-04),=20 in the first test case the client is not supposed to add = Requested-Service-Unit=20 AVP  in the initial CCR. In this case the DCCA server can send back = a CCA=20 and have, say, more than one unit types included in Granted-Service-Unit = AVP.=20

And according to RFC 4006, if the client is does not know the = cost of=20 the service it can request in terms of service events and if the client = requests=20 in time and if the service context at the server says that both Money = and time=20 are the supported unit types then the server might send back a CCA with = both=20 time and money.

Is there something that I am = missing?

Regards,
Liyaqatali G Nadaf


Patrik Teppo (KA/EAB) wrote:=20 
Hi all,

If the DCC client is implemented to only handle cc-time then it can't
measure money and report back USU/CC-Money.

The service-context should define which unit types that shall be used
and in the case below there is a configuration error for the specific
service-context.

BR,
Patrik=20

-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com]=20
Sent: den 26 februari 2007 17:35
To: Liyaqatali; dime@ietf.org
Subject: [Dime] RE: DCCA

Hi Liyaqatali,

In the scenario you described, I would expect the client to report used
units only in time. It does not have the knowledge to do the translation
between time and money.

I couldn't think of a scenario, why the server would use both cc-time
and cc-time in the answer. Does anybody have any idea about that? What
could be the reason to do so?

    Thanks,
    Tolga

-----Original Message-----
From: Liyaqatali [mailto:a21917@motorola.com]
Sent: Friday, February 23, 2007 4:42 AM
To: dime@ietf.org; Tolga Asveren
Subject: DCCA



Hi

Couple of questions.
In RFC 4006, sec 5.2 which states  "If several unit types are sent in
the Answer message, the credit-control client MUST handle each unit type
separately." What does it it actual mean to handle it separately?

Suppose the client requests some units in time but the server grants
both in time and money i.e. server adds cc-time and cc-money avps in the
granted service units AVP then how is the client suppose to handle this?
if client can understand only time then? Should the client request and
report used units  in both time and money or is it fine to report in
either ?

I would really appreciate if you can help me out here.

--
Regards,
Liyaqatali G Nadaf


_______________________________________________
DiME mailing list
DiME@ietf.org
https://www1.ietf.or=
g/mailman/listinfo/dime
------_=_NextPart_001_01C75BCC.EE3EEA6F-- --===============0419532179== 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 --===============0419532179==-- From dime-bounces@ietf.org Thu Mar 01 10:09:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmu6-0003yU-86; Thu, 01 Mar 2007 10:09:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMmu4-0003yG-7a for dime@ietf.org; Thu, 01 Mar 2007 10:09:08 -0500 Received: from mail.hostmaster.co.il ([62.219.83.3] helo=traffixsystems.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMmu2-0000Me-Ks for dime@ietf.org; Thu, 01 Mar 2007 10:09:08 -0500 Received: from TRAFFIXBEN [62.219.166.199] by traffixsystems.com with ESMTP (SMTPD32-8.03) id AB6F2550086; Thu, 01 Mar 2007 17:04:15 +0200 From: "Ben Volkow" To: Date: Thu, 1 Mar 2007 17:08:57 +0200 Message-ID: <006001c75c13$8aa0da80$6609a8c0@TRAFFIXBEN> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.2 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Subject: [Dime] Announcement - Open Source Diameter SIP Application implementation X-BeenThere: dime@ietf.org X-Mailman-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="===============1258917108==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1258917108== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C75C24.4E29AA80" This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C75C24.4E29AA80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I think you will be happy to know an Open Source implementation of the Diameter SIP Application - based on IETF RFC 4740 is now available. This is part of the OpenBloX Java GPL Diameter implementation; it can be downloaded at www.traffixsystems.com (under the Community section). We will keep updating it and support the growing community of developers. Please don't hesitate contacting me for support. Regards, Ben ------=_NextPart_000_0061_01C75C24.4E29AA80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,=

 

I think you will be happy to know an Open Source implementation of the = Diameter SIP Application – = based on IETF RFC 4740 is now = available.

 

This is part of the OpenBloX Java GPL Diameter implementation; it can be = downloaded at www.traffixsystems.com = (under the Community section).

 

We will keep updating it and support the growing community of = developers.

 

Please don't hesitate contacting me for support.

 

Regards,

Ben=

------=_NextPart_000_0061_01C75C24.4E29AA80-- --===============1258917108== 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 --===============1258917108==-- From dime-bounces@ietf.org Thu Mar 01 13:42:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqET-000429-TJ; Thu, 01 Mar 2007 13:42:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMqES-00041w-N6 for dime@ietf.org; Thu, 01 Mar 2007 13:42:24 -0500 Received: from clyde.disa.mil ([164.117.144.159]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMqEO-0007Xy-UM for dime@ietf.org; Thu, 01 Mar 2007 13:42:24 -0500 Received: from vanualevu.disanet.disa-u.mil ([164.117.144.226]) by clyde.disa.mil with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 13:42:20 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] Rechartering / Milestone Update (UNCLASSIFIED) Date: Thu, 1 Mar 2007 13:42:20 -0500 Message-ID: <9B4320CC9BC1D847AFFA97F25A422A59A9748C@vanualevu.disanet.disa-u.mil> In-Reply-To: <45E481AB.2050608@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Rechartering / Milestone Update (UNCLASSIFIED) Thread-Index: AcdaouToVeaddqdLQi2VAjDvd53M7wBjO39w References: <45E481AB.2050608@gmx.net> From: "Nguyen, An P CIV NCS NC2" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 01 Mar 2007 18:42:20.0717 (UTC) FILETIME=[584135D0:01C75C31] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Classification: UNCLASSIFIED=20 Caveats: NONE Hannes, Do you see DIAMETER is going to play a big role in the IMS-based Next Generation Networks. When I look at the NGN architecture, I see DIAMETER is one of many mandatory protocols. I wonder how this DIAMETER rechartering in the IETF is going to help the NGN effort? Thanks, An Nguyen -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Tuesday, February 27, 2007 2:08 PM To: dime@ietf.org Subject: [Dime] Rechartering / Milestone Update Hi all, here is the updated rechartering / milestone update: Mar 2007 Submit "Diameter API" to the IESG for consideration as an=20 Informational RFC Mar 2007 Submit "Diameter Application Design Guidelines" as a=20 workigg group item Aug 2007 Submit Revision of "Diameter Base Protocol" to the IESG for consideration as a Proposed Standard Aug 2007 Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standard: * "Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction" * "Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction" Sep 2007 Submit "Diameter QoS Application" to the IESG for=20 consideration as a Proposed Standard Sep 2007 Submit "Diameter Application Design Guidelines" to the IESG for consideration as an Informational RFC Comments? Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime Classification: UNCLASSIFIED=20 Caveats: NONE _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 01 14:16:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMql2-0000M2-CT; Thu, 01 Mar 2007 14:16:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMql1-0000Lq-5w for dime@ietf.org; Thu, 01 Mar 2007 14:16:03 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMqkz-0003v0-Nz for dime@ietf.org; Thu, 01 Mar 2007 14:16:03 -0500 Received: (qmail invoked by alias); 01 Mar 2007 19:16:00 -0000 X-Provags-ID: V01U2FsdGVkX19cqB48D5VcmCsX6Z6TsXKgjWYzqROd6zVQq99omP YPvNoy/RJIWB8k Message-ID: <45E7266B.4030007@gmx.net> Date: Thu, 01 Mar 2007 20:15:55 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Nguyen, An P CIV NCS NC2" Subject: Re: [Dime] Rechartering / Milestone Update (UNCLASSIFIED) References: <45E481AB.2050608@gmx.net> <9B4320CC9BC1D847AFFA97F25A422A59A9748C@vanualevu.disanet.disa-u.mil> In-Reply-To: <9B4320CC9BC1D847AFFA97F25A422A59A9748C@vanualevu.disanet.disa-u.mil> 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: 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 An, Yes. Diameter plays a major role in the IMS/NGN work. The rechartering is a purely technical stuff in this case. For some reason we forgot to include the "Diameter Mobility" work in the milestone list even though we included it in the charter text and have working group items for a long time already. Hence, we need to fix it. This requires a rechartering. The milestone update is needed because we are slower than initially expected. There is already a lot of work in the queue (based on interest from other SDOs and interested DIME WG members). Hence, we are doing fine, we have a lot of work. We just need to be a bit faster,. Ciao Hannes Nguyen, An P CIV NCS NC2 wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Hannes, > > Do you see DIAMETER is going to play a big role in the IMS-based Next > Generation Networks. When I look at the NGN architecture, I see DIAMETER > is one of many mandatory protocols. I wonder how this DIAMETER > rechartering in the IETF is going to help the NGN effort? > > Thanks, > > An Nguyen > > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > Sent: Tuesday, February 27, 2007 2:08 PM > To: dime@ietf.org > Subject: [Dime] Rechartering / Milestone Update > > Hi all, > > here is the updated rechartering / milestone update: > > Mar 2007 Submit "Diameter API" to the IESG for consideration as an > Informational RFC > Mar 2007 Submit "Diameter Application Design Guidelines" as a > workigg group item > Aug 2007 Submit Revision of "Diameter Base Protocol" to the IESG for > > consideration as a Proposed Standard > Aug 2007 Submit the following two Diameter Mobility documents to the > > IESG for consideration as a Proposed Standard: > * "Diameter Mobile IPv6: Support for Home Agent to Diameter > Server Interaction" > * "Diameter Mobile IPv6: Support for Network Access Server > to Diameter Server Interaction" > Sep 2007 Submit "Diameter QoS Application" to the IESG for > consideration as a Proposed Standard > Sep 2007 Submit "Diameter Application Design Guidelines" to the IESG > > for consideration as an Informational RFC > > Comments? > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > Classification: UNCLASSIFIED > Caveats: NONE > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 01 14:41:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMr99-0005Tl-9t; Thu, 01 Mar 2007 14:40:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMr97-0005SU-Q5 for dime@ietf.org; Thu, 01 Mar 2007 14:40:57 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HMr95-0008WR-Aq for dime@ietf.org; Thu, 01 Mar 2007 14:40:57 -0500 Received: (qmail invoked by alias); 01 Mar 2007 19:40:54 -0000 X-Provags-ID: V01U2FsdGVkX18nbvJwXd0ndt8TFobxIlWazxEgVoT9CjohnlVFIa 9AfBkTL2dVfUL9 Message-ID: <45E72C3F.8040908@gmx.net> Date: Thu, 01 Mar 2007 20:40:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Nguyen, An P CIV NCS NC2" Subject: Re: [Dime] Rechartering / Milestone Update (UNCLASSIFIED) References: <45E481AB.2050608@gmx.net> <9B4320CC9BC1D847AFFA97F25A422A59A9748C@vanualevu.disanet.disa-u.mil> <45E7266B.4030007@gmx.net> In-Reply-To: <45E7266B.4030007@gmx.net> 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: a2c12dacc0736f14d6b540e805505a86 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I forgot to mention that we also also want to remove the Diameter URI document from the charter. Based on the discussions we had I have sent a mail to IANA to register the AAA/AAAS URI scheme. There is currently an expert review ongoing. I hope to receive a response soon. Ciao Hannes Hannes Tschofenig wrote: > Hi An, > > Yes. Diameter plays a major role in the IMS/NGN work. > > The rechartering is a purely technical stuff in this case. For some > reason we forgot to include the "Diameter Mobility" work in the > milestone list even though we included it in the charter text and have > working group items for a long time already. Hence, we need to fix it. > This requires a rechartering. > > The milestone update is needed because we are slower than initially > expected. > > There is already a lot of work in the queue (based on interest from > other SDOs and interested DIME WG members). Hence, we are doing fine, > we have a lot of work. We just need to be a bit faster,. > > Ciao > Hannes > > Nguyen, An P CIV NCS NC2 wrote: >> Classification: UNCLASSIFIED Caveats: NONE >> >> Hannes, >> >> Do you see DIAMETER is going to play a big role in the IMS-based Next >> Generation Networks. When I look at the NGN architecture, I see DIAMETER >> is one of many mandatory protocols. I wonder how this DIAMETER >> rechartering in the IETF is going to help the NGN effort? >> >> Thanks, >> >> An Nguyen >> >> -----Original Message----- >> From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of >> Hannes Tschofenig >> Sent: Tuesday, February 27, 2007 2:08 PM >> To: dime@ietf.org >> Subject: [Dime] Rechartering / Milestone Update >> >> Hi all, >> >> here is the updated rechartering / milestone update: >> >> Mar 2007 Submit "Diameter API" to the IESG for consideration as >> an Informational RFC >> Mar 2007 Submit "Diameter Application Design Guidelines" as a >> workigg group item >> Aug 2007 Submit Revision of "Diameter Base Protocol" to the IESG for >> >> consideration as a Proposed Standard >> Aug 2007 Submit the following two Diameter Mobility documents to the >> >> IESG for consideration as a Proposed Standard: >> * "Diameter Mobile IPv6: Support for Home Agent to Diameter >> Server Interaction" >> * "Diameter Mobile IPv6: Support for Network Access Server >> to Diameter Server Interaction" >> Sep 2007 Submit "Diameter QoS Application" to the IESG for >> consideration as a Proposed Standard >> Sep 2007 Submit "Diameter Application Design Guidelines" to the IESG >> >> for consideration as an Informational RFC >> >> Comments? >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> Classification: UNCLASSIFIED Caveats: NONE >> > > > _______________________________________________ > DiME mailing 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 Mar 04 05:01:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNnWh-00022X-8p; Sun, 04 Mar 2007 05:01:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNnWf-00022S-Q4 for dime@ietf.org; Sun, 04 Mar 2007 05:01:09 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNnWe-0001n2-Ag for dime@ietf.org; Sun, 04 Mar 2007 05:01:09 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Mar 2007 02:01:08 -0800 X-IronPort-AV: i="4.14,246,1170662400"; d="scan'208"; a="117770527:sNHT44452287" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l24A178Q008101; Sun, 4 Mar 2007 02:01:07 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l24A1AqW019699; Sun, 4 Mar 2007 10:01:10 GMT 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); Sun, 4 Mar 2007 02:01:07 -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] Agenda Items for IETF 68 Date: Sun, 4 Mar 2007 02:01:05 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250384ADD2@xmb-sjc-215.amer.cisco.com> In-Reply-To: <8F6CBC7005099442AECDB784C9E9D7E7017466F0@MCHP7R6A.ww002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Agenda Items for IETF 68 Thread-Index: AcdGFFLfILoCBA0OQv2etW28gmCxAwYL5U+Q References: <8F6CBC7005099442AECDB784C9E9D7E7017466F0@MCHP7R6A.ww002.siemens.net> From: "Glen Zorn \(gwz\)" To: "Tschofenig, Hannes" X-OriginalArrivalTime: 04 Mar 2007 10:01:07.0268 (UTC) FILETIME=[0710D840:01C75E44] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1693; t=1173002467; x=1173866467; c=relaxed/simple; s=sjdkim1004; 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]=20Agenda=20Items=20for=20IETF=2068 |Sender:=20; bh=T2qMVUKK7mHEnjdJ2UEzBhNpaJjYxRxjRKDF7PKa18Q=; b=Pr1P749rmM7F3bPNExE4qpyISIU1/qwwoyPZyo6iZef2blVXZ+0ibEZsLx+Rx0OGr/C4bSnT lx7gxdq+dP1WJiS6O2PJnMXrKLIbuyTEO0PFSn6xL3v1HTUXbsqiKfIUYgzeP9AstfJ6xMYTGO sA+CzMRiaUY66Uz089UwaA8pg=; Authentication-Results: sj-dkim-1; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 Tschofenig, Hannes allegedly scribbled on Thursday, February 01, 2007 7:19 AM: > Hi all, >=20 > here is a first proposal for the DIME Meeting Agenda. > Please let me know if you would like to present something. > For the proposal please confirm whether you are willing to present > the listed topics.=20 Hi, are there still a few minutes to assign to the MIBs? >=20 > Ciao > Hannes & John >=20 >=20 > ----------------- >=20 >=20 > DIME Agenda >=20 >=20 > The discussions will focus on the charter items. > The goal is close open issues in order to progress the WG items. >=20 >=20 > WG Update & Interop Report > -------------------------- > Chairs >=20 >=20 > Diameter Base Protocol > ---------------------- > Victor Fajardo > http://www.ietf.org/internet-drafts/draft-ietf-dime-rfc3588bis-00.txt >=20 >=20 >=20 > Diameter Mobility > ----------------- >=20 > - Diameter Mobile IPv6: HA-to-AAAH support > Julien Bournelle > =20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt=20 >=20 > - Diameter Mobile IPv6: NAS <-> HAAA Support > Jouni Korhonen >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-integrated-02.t > xt >=20 >=20 > Diameter QoS > ------------ > Glen Zorn or Pete McCann or Tina Tsou or Avri Doria > http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-qos-00.txt >=20 >=20 > Diameter Application Design Guidelines > -------------------------------------- > TBD > TBD >=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 Sun Mar 04 16:58:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNyig-0002JX-C3; Sun, 04 Mar 2007 16:58:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNyie-0002IR-Qp for dime@ietf.org; Sun, 04 Mar 2007 16:58:16 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNyid-0003X2-Gt for dime@ietf.org; Sun, 04 Mar 2007 16:58:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2007 16:57:56 -0500 Message-ID: From: "Avi Lior" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org Subject: [Dime] Issue with draft-ietf-dime-mip6-split-01 - Application usage X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Folks, I have an issue or I am missing something. In the document you say: "it is recommended that, when EAP is used for authentication, the Diameter EAP application will be used only for Authentication purpose. " Then this will be followed by another Diameter interaction. Please tell me "This ain't so". I don't agree with this at all because this is highly inefficient and it doesn't make sense. I would think that an MSA that was serious about efficiencies etc will have a Diameter Application for MIPv6 that is built on top of Diameter EAP and extended to support MIP6 attributes. The HA will discover this existance (in the usual 35888 way) and it would use that application. If the MSA does not have that application then the HA will use the Diameter EAP application and followed by this other application called Diameter MIP6 Authz/Acc. Finally, you would think that an MSA having to invest on a Diamter Application for MIP will upgrade their Diameter EAP application no? =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Avi Lior =20 Bridgewater Systems Corporation=20 Phone : +1 (613) 591-9104 x6417 Cell : +1 (613) 796-4183 E-mail : mailto:avi@bridgewatersystems.com =20 www.bridgewatersystems.com =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sun Mar 04 17:31:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNzFB-0005ce-UG; Sun, 04 Mar 2007 17:31:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HNzFA-0005cY-Vh for dime@ietf.org; Sun, 04 Mar 2007 17:31:52 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HNzF9-0007lK-HJ for dime@ietf.org; Sun, 04 Mar 2007 17:31:52 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1086145ugd for ; Sun, 04 Mar 2007 14:31:50 -0800 (PST) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=d1SJ7rXgSWGcvkkf/Y4MwGh0i10XSTFGKkZ60V5j5JTtXK6+y/S0rpXyw9VNxsiJHsgBQpGmZFYu3ke/RL94cU4xxPinasFBfJ6r0PCHyiTIbvDz3BCYw9CftN49KNIsSMapw8/XKIU3w9awJyhQ8u876fO7q9Ma/H+DR6uljCE= 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=soHeIjKidGroEdAHx375VOz/3eQnxh7DJpWfKbjvspAof9kRo/y1lFqy9Qo1kLct7DDeUQtIi00ts5DsUuvTjJqQ5HovUKXzMFxDE+ApiVdhsUHILPFCrZpydG1D8/+FjAGYXTC3ndW/67RfSG6Net+8ah0zolmDOULhAXhhPwE= Received: by 10.114.151.13 with SMTP id y13mr1028689wad.1173047509479; Sun, 04 Mar 2007 14:31:49 -0800 (PST) Received: by 10.114.241.17 with HTTP; Sun, 4 Mar 2007 14:31:49 -0800 (PST) Message-ID: <5e2406980703041431k2c423949w66a1f38ff535fd88@mail.gmail.com> Date: Sun, 4 Mar 2007 23:31:49 +0100 From: "Julien Bournelle" To: "Avi Lior" Subject: Re: [Dime] Issue with draft-ietf-dime-mip6-split-01 - Application usage 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: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: dime@ietf.org, gerardo.giaretta@telecomitalia.it X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi, Thanks for reading the draft. Basically we have a long story with this application. To sum up, it appeared that we needed a new application ID for that AAA knows that it is performing AAA operations for MIP6 service, then it was thought better to separate Authentication and Authorization to avoid update of Diameter MIP in case of update of 4072. Then, we had lengthy debate on whether it is good or not from a security perspective. We are now in the process of launching a WG consensus call on moving with a Diameter MIP performing Authentication (with EAP) and Authorization in one application. This consensus call should be launched before next IETF meeting. Regards, Julien On 3/4/07, Avi Lior wrote: > Folks, > > I have an issue or I am missing something. > > In the document you say: > > "it is recommended that, when EAP is used > for authentication, the Diameter EAP application will be used only > for Authentication purpose. " > > Then this will be followed by another Diameter interaction. > > Please tell me "This ain't so". I don't agree with this at all because > this is highly inefficient and it doesn't make sense. > > I would think that an MSA that was serious about efficiencies etc will > have a Diameter Application for MIPv6 that is built on top of Diameter > EAP and extended to support MIP6 attributes. > > The HA will discover this existance (in the usual 35888 way) and it > would use that application. > > If the MSA does not have that application then the HA will use the > Diameter EAP application and followed by this other application called > Diameter MIP6 Authz/Acc. > > Finally, you would think that an MSA having to invest on a Diamter > Application for MIP will upgrade their Diameter EAP application no? > > > > > ======================== > > Avi Lior > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com > > www.bridgewatersystems.com > > > _______________________________________________ > DiME mailing 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 Mar 04 21:06:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2aR-0004UI-Dg; Sun, 04 Mar 2007 21:06:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO2aP-0004UB-VS for dime@ietf.org; Sun, 04 Mar 2007 21:06:01 -0500 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO2aO-0002Ls-IF for dime@ietf.org; Sun, 04 Mar 2007 21:06:01 -0500 Subject: RE: [Dime] Issue with draft-ietf-dime-mip6-split-01 - Application usage MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 4 Mar 2007 21:05:30 -0500 Message-ID: In-Reply-To: <5e2406980703041431k2c423949w66a1f38ff535fd88@mail.gmail.com> From: "Avi Lior" To: "Julien Bournelle" X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: dime@ietf.org, gerardo.giaretta@telecomitalia.it X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I know at least some of this story. I was dispointed though when I read through the draft. So I can you can guess which way I will lean. Again a single Diameter MIP6 Application built on top of EAP to do AuthN and AuthZ is the way to go. After all that is what RADIUS will do. You cant have RADIUS be better then Diameter right? The only sticking point -- and I know this is an issue for the draft -- is what to do about MIP Auth 4285. If you were also to handle it then this Application will not always do EAP. It will mean that the application will run on top of NASREQ as well. =20 -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com]=20 Sent: Sunday, March 04, 2007 5:32 PM To: Avi Lior Cc: gerardo.giaretta@telecomitalia.it; Hannes.Tschofenig@siemens.com; mnakhjiri@huawei.com; dime@ietf.org Subject: Re: [Dime] Issue with draft-ietf-dime-mip6-split-01 - Application usage Hi Avi, Thanks for reading the draft. Basically we have a long story with this application. To sum up, it appeared that we needed a new application ID for that AAA knows that it is performing AAA operations for MIP6 service, then it was thought better to separate Authentication and Authorization to avoid update of Diameter MIP in case of update of 4072. Then, we had lengthy debate on whether it is good or not from a security perspective. We are now in the process of launching a WG consensus call on moving with a Diameter MIP performing Authentication (with EAP) and Authorization in one application. This consensus call should be launched before next IETF meeting. Regards, Julien On 3/4/07, Avi Lior wrote: > Folks, > > I have an issue or I am missing something. > > In the document you say: > > "it is recommended that, when EAP is used > for authentication, the Diameter EAP application will be used only > for Authentication purpose. " > > Then this will be followed by another Diameter interaction. > > Please tell me "This ain't so". I don't agree with this at all because > this is highly inefficient and it doesn't make sense. > > I would think that an MSA that was serious about efficiencies etc will > have a Diameter Application for MIPv6 that is built on top of Diameter > EAP and extended to support MIP6 attributes. > > The HA will discover this existance (in the usual 35888 way) and it=20 > would use that application. > > If the MSA does not have that application then the HA will use the=20 > Diameter EAP application and followed by this other application called > Diameter MIP6 Authz/Acc. > > Finally, you would think that an MSA having to invest on a Diamter=20 > Application for MIP will upgrade their Diameter EAP application no? > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Avi Lior > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com=20 > > www.bridgewatersystems.com > > > _______________________________________________ > DiME mailing 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 Mar 05 00:33:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5pM-0004MT-Ap; Mon, 05 Mar 2007 00:33:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HO5pL-0004MK-Fw for dime@ietf.org; Mon, 05 Mar 2007 00:33:39 -0500 Received: from sfo-mta-39.taggedmail.com ([64.125.115.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HO5pK-0000yN-4Z for dime@ietf.org; Mon, 05 Mar 2007 00:33:39 -0500 Received: from taggedmail.com (10.15.10.16) by sfo-mta-39.taggedmail.com (PowerMTA(TM) v3.2r4) id htelqs0d9n46 for ; Sun, 4 Mar 2007 21:33:29 -0800 (envelope-from ) X-Log-Id: 1504276959 From: Ajay Kolambekar To: dime@ietf.org MIME-Version: 1.0 Accreditor: Habeas X-Habeas-Report: Please report use of this mark in spam to X-Spam-Score: 1.6 (+) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Subject: [Dime] Ajay has Tagged you! :) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ajay Kolambekar List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1357397578==" Errors-To: dime-bounces@ietf.org Message-Id: Date: Mon, 05 Mar 2007 00:33:40 -0500 --===============1357397578== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ajay has Tagged you! :)

Ajay K, 26
India
Ajay K has added you as a friend
Is Ajay K your friend?
 
Please respond or Ajay may think you said no :(
Click here to unsubscribe from Tagged, P.O. Box 193152 San Francisco, CA 94119-3152
--===============1357397578== 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 --===============1357397578==-- From dime-bounces@ietf.org Mon Mar 05 15:52:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOKAT-0003dJ-1N; Mon, 05 Mar 2007 15:52:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOK9P-0001jE-3e; Mon, 05 Mar 2007 15:51:19 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOK9G-0000Ux-Fw; Mon, 05 Mar 2007 15:51:18 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 49F3B329D3; Mon, 5 Mar 2007 20:50:04 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HOK8C-0005hU-51; Mon, 05 Mar 2007 15:50:04 -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: Mon, 05 Mar 2007 15:50:04 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: dime@ietf.org Subject: [Dime] I-D ACTION:draft-ietf-dime-rfc3588bis-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 Base Protocol Author(s) : V. Fajardo, J. Loughney Filename : draft-ietf-dime-rfc3588bis-02.txt Pages : 167 Date : 2007-3-5 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-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-rfc3588bis-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-rfc3588bis-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-3-5143647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dime-rfc3588bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dime-rfc3588bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-3-5143647.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 Mar 07 04:04:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOs4X-0006US-1O; Wed, 07 Mar 2007 04:04:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOiye-0005We-CN for dime@ietf.org; Tue, 06 Mar 2007 18:21:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOiD4-0006t8-NE for dime@ietf.org; Tue, 06 Mar 2007 17:32:46 -0500 Received: (qmail invoked by alias); 06 Mar 2007 22:32:36 -0000 Received: from unknown (EHLO chesteve) [201.72.55.73] by mail.gmx.net (mp018) with SMTP; 06 Mar 2007 23:32:36 +0100 X-Authenticated: #20559382 X-Provags-ID: V01U2FsdGVkX1+C0+M0s/aCD9cTNP2vkFvdT4oQKV8dddqNwIRwTw u+BjTtzKSv+miM From: "Christian Esteve" To: Date: Tue, 6 Mar 2007 19:32:05 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcdgPwuokajurwh8T5Gu3b57IL/Tmw== X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Dime] Comments on draft-ietf-dime-diameter-qos-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Message-Id: Hi Folks and Authors, Reading through draft-ietf-dime-diameter-qos-00, there are some comments I wanted to share with you. In 3.2 requirements (page 9), the first requirement "Inter-domain support" misses the MUST/SHOULD sentence for the QoS AAA Protocol. In 4.3 (page 17) the provided options a) and c) seem to be redundant and could be merged or more clearly separated. The table in page 31 does not contain the entry referring to the QoS-ID attribute introduced in page 32. I am new to the dime working group and would like to know what is the relationship of this I-D to others like draft-tschofenig-dime-diameter-qos-01 or draft-sun-dime-diameter-resource-control-requirements-00. I am missing the references to these documents in this I-D. Are there any relevant design differences or is this I-D just an update that already gathers the contents of previous work? Best regards, Christian Esteve _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 07 04:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOsAK-0000RV-8h; Wed, 07 Mar 2007 04:10:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOoGM-0002E7-Hl for dime@ietf.org; Wed, 07 Mar 2007 00:00:30 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOoGL-0001FG-7L for dime@ietf.org; Wed, 07 Mar 2007 00:00:30 -0500 Received: from psg.com ([147.28.0.62] helo=[127.0.0.1]) by psg.com with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1HOoGJ-000Ln0-Sp for dime@ietf.org; Wed, 07 Mar 2007 05:00:28 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <078DF454-E80B-4798-A804-01204E5F5D5E@acm.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: dime@ietf.org From: Avri Doria Date: Wed, 7 Mar 2007 00:00:26 -0500 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -104.0 (---------------------------------------------------) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Subject: [Dime] I-D ACTION:draft-bodin-dime-auditing-reqs-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 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Auditing Functionality in Diameter Author(s) : U. Bodin, et al. Filename : draft-bodin-dime-auditing-reqs-02.txt Pages : 15 Date : 2007-3-6 Diameter is being increasingly included in the work of other standards organizations and has become a key protocol in many architectures. One of the uses of Diameter includes setting and maintaining hard-state and soft-state during failover and in the event of delayed refresh messages respectively. Often there is a need to query for information on active sessions for backup or synchronization purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bodin-dime-auditing- reqs-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-bodin-dime-auditing-reqs-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-bodin-dime-auditing-reqs-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. Content-Type: text/plain Content-ID: <2007-3-6115219.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 07 05:51:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtkP-0007o8-DA; Wed, 07 Mar 2007 05:51:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtkM-0007mH-I5 for dime@ietf.org; Wed, 07 Mar 2007 05:51:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOti8-0006Zh-7m for dime@ietf.org; Wed, 07 Mar 2007 05:49:34 -0500 Received: (qmail invoked by alias); 07 Mar 2007 10:49:31 -0000 Received: from p54986A0E.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.106.14] by mail.gmx.net (mp045) with SMTP; 07 Mar 2007 11:49:31 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18uvCtMFnguZMokueELkIqainhgbSpgJtFxeZTGNj 24FzvkuQNH30UX Message-ID: <45EE98C5.40006@gmx.net> Date: Wed, 07 Mar 2007 12:49:41 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Christian Esteve Subject: Re: [Dime] Comments on draft-ietf-dime-diameter-qos-00.txt 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: 769a46790fb42fbb0b0cc700c82f7081 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 Christian, thanks for your comments. Christian Esteve wrote: > Hi Folks and Authors, > > Reading through draft-ietf-dime-diameter-qos-00, there are some comments I > wanted to share with you. > > In 3.2 requirements (page 9), the first requirement "Inter-domain support" > misses the MUST/SHOULD sentence for the QoS AAA Protocol. > Correct. > In 4.3 (page 17) the provided options a) and c) seem to be redundant and > could be merged or more clearly separated. > Correct. > The table in page 31 does not contain the entry referring to the QoS-ID > attribute introduced in page 32. > Correct. > I am new to the dime working group and would like to know what is the > relationship of this I-D to others like > draft-tschofenig-dime-diameter-qos-01 or > draft-sun-dime-diameter-resource-control-requirements-00. I am missing the > references to these documents in this I-D. Are there any relevant design > differences or is this I-D just an update that already gathers the contents > of previous work? > > Good hint. I should post a separate mail about this subject. Ciao Hannes > Best regards, > > Christian Esteve > > > _______________________________________________ > DiME mailing 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 Mar 07 06:08:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOu02-0003Jd-Na; Wed, 07 Mar 2007 06:08:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HOtkI-0007kd-RS for dime@ietf.org; Wed, 07 Mar 2007 05:51:46 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HOtjB-00071n-VS for dime@ietf.org; Wed, 07 Mar 2007 05:50:39 -0500 Received: (qmail invoked by alias); 07 Mar 2007 10:50:36 -0000 Received: from p54986A0E.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.106.14] by mail.gmx.net (mp011) with SMTP; 07 Mar 2007 11:50:36 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18b4MgBC2IbBOKEMfrmEhhAe00rwtWmXCBIG72gk7 JVuE0PPPp3vFcq Message-ID: <45EE9907.8030900@gmx.net> Date: Wed, 07 Mar 2007 12:50:47 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 25620135586de10c627e3628c432b04a Subject: [Dime] Updated QoS Drafts X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, new versions of the QoS documents are available as you have seen from the draft announcements. I would like to clarify the relationship between the documents: http://tools.ietf.org/html/draft-ietf-dime-diameter-qos-00 This document describes the Diameter QoS application. http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-parameters-00.txt This document contains QoS parameters taken from an NSIS working group document and placed into a separate document. We did this to (a) improve readability, (b) remove functionality that is not needed for the Diameter action and to (c) at the same time leverage existing work. Currently we assume that the same registry is used. The final decision depends on the policy for adding new parameters to the registry. These QoS parameters are utilized by , by and by corresponding RADIUS documents. http://tools.ietf.org/wg/dime/draft-korhonen-dime-qos-attributes-00.txt This document defines the Extended-QoS-Filter-Rule in the spirit of the QoS-Filter-Rule. Unlike the document it addresses scenarios where the updated QoS-Filter-Rule attribute is carried within other applications. It therefore only addresses a limited set of scenarios. One could compare the approach with the mobility documents. This document also assumes that an extended version of the IPFilterRule attribute is available. Currently, the required extensions are described in and "imported" into this document. There is ongoing work in the RADEXT working group to define a more powerful version of the IPFilterRule / NAS-Traffic-Rule, see http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-02.txt We obviously need to align our work with the RADEXT working group with regard to this aspect since the newly defined attribute will be made available as described in the Diameter Compatibility section of . http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requirements-01 This document takes a different spin and extends the document by supporting a "generic push" approach. By "generic push" I refer to the ability of an arbitrary entity, such as an SIP proxy, to signal to another box. Note that this is not the same as the server-initiated communication. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 07 15:15:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2XX-0002Ol-RK; Wed, 07 Mar 2007 15:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP2XX-0002OX-1c for dime@ietf.org; Wed, 07 Mar 2007 15:15:11 -0500 Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP2XQ-0005cy-7X for dime@ietf.org; Wed, 07 Mar 2007 15:15:11 -0500 Received: from mail3.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id l27KF3fb012351; Wed, 7 Mar 2007 21:15:03 +0100 Received: from mchp7wta.ww002.siemens.net (mchp7wta.ww002.siemens.net [139.25.131.193]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id l27KF02U031041; Wed, 7 Mar 2007 21:15:00 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp7wta.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 21:15:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Dime] Announcement - Open Source Diameter SIP Applicationimplementation Date: Wed, 7 Mar 2007 21:14:21 +0100 Message-ID: <8F6CBC7005099442AECDB784C9E9D7E7018815C6@MCHP7R6A.ww002.siemens.net> In-Reply-To: <006001c75c13$8aa0da80$6609a8c0@TRAFFIXBEN> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Announcement - Open Source Diameter SIP Applicationimplementation Thread-Index: AcdcE7rdJeosA+MRT3O1VlvfR39dCQE4T9sw From: "Tschofenig, Hannes" To: "Ben Volkow" , X-OriginalArrivalTime: 07 Mar 2007 20:15:00.0169 (UTC) FILETIME=[486CC390:01C760F5] X-Spam-Score: 0.2 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 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="===============0430771433==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0430771433== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C760F5.327B09C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C760F5.327B09C8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you Ben for the open source implementation and for informing us.=20 =20 If you encountered problems with the specification please let us know.=20 =20 Ciao Hannes =20 ________________________________ Von: Ben Volkow [mailto:bvolkow@traffixsystems.com]=20 Gesendet: Donnerstag, 1. M=E4rz 2007 16:09 An: dime@ietf.org Betreff: [Dime] Announcement - Open Source Diameter SIP = Applicationimplementation =09 =09 Hi, =20 I think you will be happy to know an Open Source implementation of the = Diameter SIP Application - based on IETF RFC 4740 is now available. =20 This is part of the OpenBloX Java GPL Diameter implementation; it can = be downloaded at www.traffixsystems.com = (under the Community section). =20 We will keep updating it and support the growing community of = developers. =20 Please don't hesitate contacting me for support. =20 Regards, Ben ------_=_NextPart_001_01C760F5.327B09C8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you Ben for the open source = implementation and=20 for informing us.
 
If you encountered problems with the = specification=20 please let us know.
 
Ciao
Hannes
 

Von: Ben Volkow=20 [mailto:bvolkow@traffixsystems.com]
Gesendet: Donnerstag, = 1. M=E4rz=20 2007 16:09
An: dime@ietf.org
Betreff: [Dime] = Announcement=20 - Open Source Diameter SIP = Applicationimplementation

Hi,

 

I think = you will be=20 happy to know an Open Source implementation of the Diameter SIP Application =96 = based on=20 IETF RFC 4740 is now=20 available.

 

This is = part of the=20 OpenBloX Java GPL Diameter implementation; it can be downloaded at www.traffixsystems.com = (under the=20 Community section).

 

We will = keep updating=20 it and support the growing community of=20 developers.

 

Please = don't hesitate=20 contacting me for support.

 

Regards,

Ben

------_=_NextPart_001_01C760F5.327B09C8-- --===============0430771433== 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 --===============0430771433==-- From dime-bounces@ietf.org Wed Mar 07 18:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5RZ-0005EQ-4k; Wed, 07 Mar 2007 18:21:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HP5RY-0005EL-4i for dime@ietf.org; Wed, 07 Mar 2007 18:21:12 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP5RV-00075U-5g for dime@ietf.org; Wed, 07 Mar 2007 18:21:12 -0500 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l27NL8Os022112 for ; Wed, 7 Mar 2007 17:21:08 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.12]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 17:21:08 -0600 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Dime] Updated QoS Drafts Date: Wed, 7 Mar 2007 17:21:08 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02AC6D@ILEXC2U01.ndc.lucent.com> In-Reply-To: <45EE9907.8030900@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Updated QoS Drafts Thread-Index: AcdgqPzE6gMzuyjDSH6D97ruErddGQAIVaKw References: <45EE9907.8030900@gmx.net> From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 07 Mar 2007 23:21:08.0482 (UTC) FILETIME=[49421620:01C7610F] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org =20 Hi, Some clarifications and comments: ~~~~~~~~~~~~~ -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Wednesday, March 07, 2007 5:51 AM To: dime@ietf.org Subject: [Dime] Updated QoS Drafts Hi all, ... ... " http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requ irements-01 This document takes a different spin and extends the=20 document by supporting a "generic push" approach. By "generic push" I=20 refer to the ability of an arbitrary entity, such as an SIP proxy, to signal to=20 another box. Note that this is not the same as the server-initiated communication. " ~~~~~~~~~~~~~~~~~ [Dong] The "Push model" defined in above I-D doesn't aim to define the ability of an arbitrary entity, such as a SIP proxy, to signal to another box. This document actually addresses the same interface as in the current QoS application (draft-ietf-dime-diameter-qos-00). Since the current QoS application only supports the Pull model that is not suitable for some circumstances (e.g. when the network elements cannot trigger the QoS authorization request and/or the endpoint does not support any QoS signaling/capability, which is quite common in wireline networks), the I-D intends to complement current QoS application document and make a generic framework in order to support various networks, endpoints and applications. Currently, this document mainly focuses on discussing the requirements and framework of a generic resource control system, and also proposes some potential solutions to solve the issue. IMO, it will be better to integrate this document with QoS application document together to formulate a single document on this subject since the scope and objective of these two are quite similar.=20 I'd like to get others' opinion on the integration of these two documents. P.S.: the solution proposed in this document is kind of Diameter server initiated communication. There are some discussions on this issue in the exploder recently triggered by an ITU-T liaison, it has not yet reached a consensus though.=20 Regards, Dong _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 08 05:04:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPFUT-0002dL-5U; Thu, 08 Mar 2007 05:04:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPFUS-0002ah-Ft for dime@ietf.org; Thu, 08 Mar 2007 05:04:52 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPFUR-0004yN-1j for dime@ietf.org; Thu, 08 Mar 2007 05:04:52 -0500 Received: (qmail invoked by alias); 08 Mar 2007 10:04:41 -0000 Received: from p549879C0.dip.t-dialin.net (EHLO [192.168.178.21]) [84.152.121.192] by mail.gmx.net (mp046) with SMTP; 08 Mar 2007 11:04:41 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18+myN2rDE+/6cQLHVUPLZ/oeg1yOy+eSMZkNL20X qtl35YG55o6FeN Message-ID: <45EFDFBA.7000203@gmx.net> Date: Thu, 08 Mar 2007 12:04:42 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: "Sun, Dong \(Dong\)" Subject: Re: [Dime] Updated QoS Drafts References: <45EE9907.8030900@gmx.net> <09C9068466B79E4C938DC7737562404D02AC6D@ILEXC2U01.ndc.lucent.com> In-Reply-To: <09C9068466B79E4C938DC7737562404D02AC6D@ILEXC2U01.ndc.lucent.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: 10d3e4e3c32e363f129e380e644649be 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 Dong, thanks for your clarifications. Please find some comments below: Sun, Dong (Dong) wrote: > > Hi, > Some clarifications and comments: > ~~~~~~~~~~~~~ > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, March 07, 2007 5:51 AM > To: dime@ietf.org > Subject: [Dime] Updated QoS Drafts > > Hi all, > ... > ... > " > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requ > irements-01 > > This document takes a different spin and extends the > > document by supporting a "generic push" approach. By "generic push" I > refer to the > ability of an arbitrary entity, such as an SIP proxy, to signal to > another box. > Note that this is not the same as the server-initiated communication. > " > ~~~~~~~~~~~~~~~~~ > > [Dong] The "Push model" defined in above I-D doesn't aim to define the > ability of an arbitrary entity, such as a SIP proxy, to signal to > another box. This document actually addresses the same interface as in > the current QoS application (draft-ietf-dime-diameter-qos-00). Since the > current QoS application only supports the Pull model that is not > suitable for some circumstances (e.g. when the network elements cannot > trigger the QoS authorization request and/or the endpoint does not > support any QoS signaling/capability, which is quite common in wireline > networks), the I-D intends to complement current QoS application > document and make a generic framework in order to support various > networks, endpoints and applications. > I agree that draft-ietf-dime-diameter-qos-00 is not particularly strong on the description of server-initiated communication. This is, however, a basic feature of the Diameter Base protocol. Typically, server-initiated messages are still sent after the initial session setup took place based on an interaction with the Diameter client. For example, you have a network access authentication procedure taking place. Then, during the lifetime of the session some authorization relevant aspects change at the Diameter server and it initiates a re-authorization exchange. > Currently, this document mainly focuses on discussing the requirements > and framework of a generic resource control system, and also proposes > some potential solutions to solve the issue. IMO, it will be better to > integrate this document with QoS application document together to > formulate a single document on this subject since the scope and > objective of these two are quite similar. > > I agree that it would be good to integrate features whenever possible. We just need to figure out how todo that. > I'd like to get others' opinion on the integration of these two > documents. > > P.S.: the solution proposed in this document is kind of Diameter server > initiated communication. There are some discussions on this issue in the > exploder recently triggered by an ITU-T liaison, it has not yet reached > a consensus though. > Ciao Hannes > Regards, > Dong > > > _______________________________________________ > DiME mailing 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 Mar 08 14:50:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOcx-0003zq-Ky; Thu, 08 Mar 2007 14:50:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOcw-0003zg-3A for dime@ietf.org; Thu, 08 Mar 2007 14:50:14 -0500 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPOct-0005yE-LQ for dime@ietf.org; Thu, 08 Mar 2007 14:50:14 -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 7F41C08588 for ; Thu, 8 Mar 2007 14:50:10 -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 l28JoAtQ005220 for ; Thu, 8 Mar 2007 14:50:10 -0500 (EST) From: "Tolga Asveren" To: Date: Thu, 8 Mar 2007 14:45:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Dime] Diaemter Application Design Guidelines draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi All, We put together a draft as a guideline for authors of Diameter application specifications. It is avialable via the following link: http://www.ietf.org/internet-drafts/draft-fajardo-dime-app-design-guide-00.t xt It addresses issues like when to allocate a new application identifier, routing of accounting messages, guidelines regarding extending commands, use of application layer timers etc... Thanks, Tolga _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 08 15:06:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOsy-0002mb-MX; Thu, 08 Mar 2007 15:06:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPOsx-0002mW-R6 for dime@ietf.org; Thu, 08 Mar 2007 15:06:47 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HPOsv-0000QU-CS for dime@ietf.org; Thu, 08 Mar 2007 15:06:47 -0500 Received: (qmail invoked by alias); 08 Mar 2007 20:06:44 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp037) with SMTP; 08 Mar 2007 21:06:44 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19wYfwHw8lwzZ6F0mMQYofKD2ods5BzymO5Dx9lHm ziP6ZTpqbO6yXM Message-ID: <45F06CCB.7020908@gmx.net> Date: Thu, 08 Mar 2007 22:06:35 +0200 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Tolga Asveren Subject: Re: [Dime] Diaemter Application Design Guidelines draft 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: b19722fc8d3865b147c75ae2495625f2 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Feedback from the group would be important given that we are very late on this document. Please let us know what type of content you would like to see in such a document and what would help you when extending Diameter. Ciao Hannes Tolga Asveren wrote: > Hi All, > > We put together a draft as a guideline for authors of Diameter application > specifications. It is avialable via the following link: > > http://www.ietf.org/internet-drafts/draft-fajardo-dime-app-design-guide-00.t > xt > > It addresses issues like when to allocate a new application identifier, > routing of accounting messages, guidelines regarding extending commands, use > of application layer timers etc... > > 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 Fri Mar 09 04:25:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbLV-0008Pb-4U; Fri, 09 Mar 2007 04:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPVE5-0003yz-Tj for dime@ietf.org; Thu, 08 Mar 2007 21:53:01 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPVE4-0008BO-Dm for dime@ietf.org; Thu, 08 Mar 2007 21:53:01 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-1.cisco.com with ESMTP; 08 Mar 2007 18:53:00 -0800 X-IronPort-AV: i="4.14,265,1170662400"; d="url'?txt'208?scan'208,208"; a="765997412:sNHT107427820" 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 l292qxwb025178 for ; Thu, 8 Mar 2007 18:52:59 -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 l292qxxR025796 for ; Fri, 9 Mar 2007 02:52:59 GMT 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); Thu, 8 Mar 2007 18:52:59 -0800 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_01C761F6.0BE7EE33" Date: Thu, 8 Mar 2007 18:52:56 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A8AC@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FYI: I-D ACTION:draft-zorn-dime-diameter-base-protocol-mib-01.txt Thread-Index: AcdhxYAbO9MKfEqHQYeVs8lPVUQ8awAMGcZw From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 09 Mar 2007 02:52:59.0490 (UTC) FILETIME=[0C05BC20:01C761F6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4294; t=1173408779; x=1174272779; 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:=20FYI=3A=20I-D=20ACTION=3Adraft-zorn-dime-diameter-base-protoco l-mib-01.txt=20 |Sender:=20; bh=Mjj7wnOV0U8Ieorpc1GDnqNrCZdNCxGdDsrw8Kd7TMo=; b=HSLvXtWzg2zyZjrg3VbbyYD4/lpPItuBvKdWbSm3ZSeT12i9afgxh0XXu5C4gx6jzo98is53 9lKg8b48rnp1c6SIco6IRcTfAAVkzb1ooInfol2bD9E0u207KB91342q; 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: 287c806b254c6353fcb09ee0e53bbc5e Subject: [Dime] FYI: I-D ACTION:draft-zorn-dime-diameter-base-protocol-mib-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C761F6.0BE7EE33 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Internet-Drafts@ietf.org allegedly scribbled on Thursday, March 08, 2007 12:50 PM: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 >=20 >=20 > Title : Diameter Base Protocol MIB > Author(s) : S. Comerica, G. Zorn > Filename : draft-zorn-dime-diameter-base-protocol-mib-01.txt > Pages : 53 > Date : 2007-3-8 >=20 > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter protocol is > designed to provide a framework for AAA applications. >=20 > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter protocol. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-base-protoc ol-mib-01.txt >=20 > 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. >=20 > 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-zorn-dime-diameter-base-protocol-mib-01.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-zorn-dime-diameter-base-protocol-mib-01.txt".=20 >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C761F6.0BE7EE33 Content-Type: application/octet-stream; name="ATT3364195.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT3364195.TXT Content-Disposition: attachment; filename="ATT3364195.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0zLTgxMjU1MDguSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtem9ybi1kaW1lLWRpYW1ldGVy LWJhc2UtcHJvdG9jb2wtbWliLTAxLnR4dA0K ------_=_NextPart_001_01C761F6.0BE7EE33 Content-Type: application/octet-stream; name="draft-zorn-dime-diameter-base-protocol-mib-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zorn-dime-diameter-base-protocol-mib-01.URL Content-Disposition: attachment; filename="draft-zorn-dime-diameter-base-protocol-mib-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16b3JuLWRpbWUtZGlhbWV0ZXItYmFzZS1wcm90b2NvbC1taWItMDEudHh0DQo= ------_=_NextPart_001_01C761F6.0BE7EE33 Content-Type: text/plain; name="ATT3364196.txt" Content-Transfer-Encoding: base64 Content-Description: ATT3364196.txt Content-Disposition: attachment; filename="ATT3364196.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C761F6.0BE7EE33 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_01C761F6.0BE7EE33-- From dime-bounces@ietf.org Fri Mar 09 04:25:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbLW-0008SR-GS; Fri, 09 Mar 2007 04:25:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPVFW-0004KY-JC for dime@ietf.org; Thu, 08 Mar 2007 21:54:30 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPVFV-0008PC-43 for dime@ietf.org; Thu, 08 Mar 2007 21:54:30 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2007 18:54:27 -0800 X-IronPort-AV: i="4.14,265,1170662400"; d="url'?txt'208?scan'208,208"; a="119418949:sNHT3895414974" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l292sQD2022795 for ; Thu, 8 Mar 2007 18:54:26 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l292sQYQ015793 for ; Fri, 9 Mar 2007 02:54:26 GMT 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); Thu, 8 Mar 2007 18:54:26 -0800 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_01C761F6.3F8BFCA2" Date: Thu, 8 Mar 2007 18:54:23 -0800 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250391A8AE@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FYI: I-D ACTION:draft-zorn-dime-diameter-cc-appl-mib-01.txt Thread-Index: AcdhxAeNX0HAzxWfSGmx6k5fohEi8gAMiQBA From: "Glen Zorn \(gwz\)" To: X-OriginalArrivalTime: 09 Mar 2007 02:54:26.0020 (UTC) FILETIME=[3F992A40:01C761F6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4266; t=1173408866; x=1174272866; c=relaxed/simple; s=sjdkim4002; 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:=20FYI=3A=20I-D=20ACTION=3Adraft-zorn-dime-diameter-cc-appl-mib- 01.txt=20 |Sender:=20; bh=nIMAKFcfUkgkDZQy3IZamikLgJW83rYbCS4EesgCKpw=; b=cHx1GaAGVcc+LymUr0Dhp5rGcITD2ySfvFCk79aQhbSS1vnlGQiDZFokW54c4ZGR7m8WNz0g 1T30FIaBQfH2UsXFDktNYLUE4XmqIcwOugzYCDTbzR7x5iOd31iljNda; Authentication-Results: sj-dkim-4; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Dime] FYI: I-D ACTION:draft-zorn-dime-diameter-cc-appl-mib-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C761F6.3F8BFCA2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Internet-Drafts@ietf.org allegedly scribbled on Thursday, March 08, 2007 12:50 PM: > A New Internet-Draft is available from the on-line Internet-Drafts > directories.=20 >=20 >=20 > Title : Diameter Credit Control Application MIB > Author(s) : S. Comerica, G. Zorn > Filename : draft-zorn-dime-diameter-cc-appl-mib-01.txt > Pages : 21 > Date : 2007-3-8 >=20 > Along with providing support for certain basic authentication, > authorization and accounting functions, the Diameter base protocol > is intended to provide a framework for AAA applications. >=20 > This document defines the Management Information Base (MIB) module > which describes the minimum set of objects needed to manage an > implementation of the Diameter Credit Control application. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-zorn-dime-diameter-cc-appl-mib -01.txt >=20 > 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. >=20 > 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-zorn-dime-diameter-cc-appl-mib-01.txt". >=20 > 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 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-zorn-dime-diameter-cc-appl-mib-01.txt". >=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------_=_NextPart_001_01C761F6.3F8BFCA2 Content-Type: application/octet-stream; name="ATT3364325.TXT" Content-Transfer-Encoding: base64 Content-Description: ATT3364325.TXT Content-Disposition: attachment; filename="ATT3364325.TXT" Q29udGVudC1UeXBlOiBNZXNzYWdlL0V4dGVybmFsLWJvZHk7IGFjY2Vzcy10eXBlPSJtYWlsLXNl cnZlciI7DQoJc2VydmVyPSJtYWlsc2VydkBpZXRmLm9yZyINCg0KQ29udGVudC1UeXBlOiB0ZXh0 L3BsYWluDQpDb250ZW50LUlEOiA8MjAwNy0zLTgxMzAwMjkuSS1EQGlldGYub3JnPg0KDQpFTkNP RElORyBtaW1lDQpGSUxFIC9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtem9ybi1kaW1lLWRpYW1ldGVy LWNjLWFwcGwtbWliLTAxLnR4dA0K ------_=_NextPart_001_01C761F6.3F8BFCA2 Content-Type: application/octet-stream; name="draft-zorn-dime-diameter-cc-appl-mib-01.URL" Content-Transfer-Encoding: base64 Content-Description: draft-zorn-dime-diameter-cc-appl-mib-01.URL Content-Disposition: attachment; filename="draft-zorn-dime-diameter-cc-appl-mib-01.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC16b3JuLWRpbWUtZGlhbWV0ZXItY2MtYXBwbC1taWItMDEudHh0DQo= ------_=_NextPart_001_01C761F6.3F8BFCA2 Content-Type: text/plain; name="ATT3364326.txt" Content-Transfer-Encoding: base64 Content-Description: ATT3364326.txt Content-Disposition: attachment; filename="ATT3364326.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C761F6.3F8BFCA2 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_01C761F6.3F8BFCA2-- From dime-bounces@ietf.org Fri Mar 09 04:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbNm-0003SI-Mz; Fri, 09 Mar 2007 04:27:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPXs5-0000Tp-AO for dime@ietf.org; Fri, 09 Mar 2007 00:42:29 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPXnP-0004OA-Uk for dime@ietf.org; Fri, 09 Mar 2007 00:37:43 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l295bUFk009495 for ; Thu, 8 Mar 2007 23:37:30 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 23:37:30 -0600 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: FW: [Dime] Updated QoS Drafts Date: Thu, 8 Mar 2007 23:37:30 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02AC7A@ILEXC2U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Updated QoS Drafts thread-index: AcdhaTZYwrhl5+faS6OEJ94JDugaKAAWlm9QABI+oUA= From: "Sun, Dong \(Dong\)" To: X-OriginalArrivalTime: 09 Mar 2007 05:37:30.0364 (UTC) FILETIME=[078593C0:01C7620D] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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. seems the following message was not posted to the exploder... -----Original Message----- From: Sun, Dong (Dong)=20 Sent: Thursday, March 08, 2007 5:10 PM To: 'Hannes Tschofenig' Cc: dime@ietf.org Subject: RE: [Dime] Updated QoS Drafts Hi Hannes, Concerning the integration of features into QoS application, I'd like to have discussion on some high level issues before getting into detailed edits.=20 some items could be considered in my mind. Once we have consensus on these items, the relevant mechanisms can be discussed afterwards. 1. Support of Push Model as defined in the "resource control application requirements" I feel it is critical to support both Pull and Push models in the same framework. The Push model here refers to the case that no Diameter session is pre-established from NE (Diameter Client) to authorizing entity (Diameter server). In fact, the Push model is perceived as the trend to support the policy control due to the merits of flexibility, complexity and scalability required on the underlying network technologies. Further details can be found in the aforementioned document.=20 2. Extension of the scope of QoS application The current QoS application mainly addresses one aspect of resource control/policy enforcement, i.e. bandwidth and performance metrics. Although it is one of the most important aspects, it would be good to include some other aspects, e.g. NAT traversal and NAPT control since these functions are commonly collocated with QoS policy enforcement in the same NE, which results in some correlation between them, e.g. the change of media flow IP 5-tuple. 3. Compatibility of command codes with other SDOs I have no strong preference on the command codes, but just concerned about the usage of the QoS application in reality due to the incompatibility. Just wondering if it is possible to make 3GPP/PP2 modify their specs according to the command codes currently defined in QoS application document? If not, who will use this document in the implementation? For which kind of use cases? Regards, Dong =20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, March 08, 2007 5:05 AM To: Sun, Dong (Dong) Cc: dime@ietf.org Subject: Re: [Dime] Updated QoS Drafts Hi Dong, thanks for your clarifications. Please find some comments below: Sun, Dong (Dong) wrote: > =20 > Hi, > Some clarifications and comments: > ~~~~~~~~~~~~~ > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, March 07, 2007 5:51 AM > To: dime@ietf.org > Subject: [Dime] Updated QoS Drafts > > Hi all, > ... > ... > " > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-re > qu > irements-01 > > This document takes a different spin and extends the=20 > > document by supporting a "generic push" approach. By "generic push"=20 > I refer to the > ability of an arbitrary entity, such as an SIP proxy, to signal to=20 > another box. > Note that this is not the same as the server-initiated communication. > " > ~~~~~~~~~~~~~~~~~ > > [Dong] The "Push model" defined in above I-D doesn't aim to define the > ability of an arbitrary entity, such as a SIP proxy, to signal to=20 > another box. This document actually addresses the same interface as in > the current QoS application (draft-ietf-dime-diameter-qos-00). Since=20 > the current QoS application only supports the Pull model that is not=20 > suitable for some circumstances (e.g. when the network elements cannot > trigger the QoS authorization request and/or the endpoint does not=20 > support any QoS signaling/capability, which is quite common in=20 > wireline networks), the I-D intends to complement current QoS=20 > application document and make a generic framework in order to support=20 > various networks, endpoints and applications. > =20 I agree that draft-ietf-dime-diameter-qos-00 is not particularly strong on the description of server-initiated communication. This is, however, a basic feature of the Diameter Base protocol. =20 Typically, server-initiated messages are still sent after the initial session setup took place based on an interaction with the Diameter client. For example, you have a network access authentication procedure taking place. Then, during the lifetime of the session some authorization relevant aspects change at the Diameter server and it initiates a re-authorization exchange. > Currently, this document mainly focuses on discussing the requirements > and framework of a generic resource control system, and also proposes=20 > some potential solutions to solve the issue. IMO, it will be better to > integrate this document with QoS application document together to=20 > formulate a single document on this subject since the scope and=20 > objective of these two are quite similar. > > =20 I agree that it would be good to integrate features whenever possible. We just need to figure out how todo that. > I'd like to get others' opinion on the integration of these two=20 > documents. > > P.S.: the solution proposed in this document is kind of Diameter=20 > server initiated communication. There are some discussions on this=20 > issue in the exploder recently triggered by an ITU-T liaison, it has=20 > not yet reached a consensus though. > =20 Ciao Hannes =20 > Regards, > Dong > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 09 04:48:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPbBD-0008Gy-F7; Fri, 09 Mar 2007 04:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPR4Q-0005LA-Vw for dime@ietf.org; Thu, 08 Mar 2007 17:26:47 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPQod-0004OV-Fq for dime@ietf.org; Thu, 08 Mar 2007 17:10:46 -0500 Received: from ilexp01.ndc.lucent.com (h135-3-39-1.lucent.com [135.3.39.1]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id l28M9oYw013561; Thu, 8 Mar 2007 16:10:22 -0600 (CST) Received: from ILEXC2U01.ndc.lucent.com ([135.3.39.10]) by ilexp01.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Mar 2007 16:10:15 -0600 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] Updated QoS Drafts Date: Thu, 8 Mar 2007 16:10:15 -0600 Message-ID: <09C9068466B79E4C938DC7737562404D02AC76@ILEXC2U01.ndc.lucent.com> In-Reply-To: <45EFDFBA.7000203@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Updated QoS Drafts thread-index: AcdhaTZYwrhl5+faS6OEJ94JDugaKAAWlm9Q References: <45EE9907.8030900@gmx.net> <09C9068466B79E4C938DC7737562404D02AC6D@ILEXC2U01.ndc.lucent.com> <45EFDFBA.7000203@gmx.net> From: "Sun, Dong \(Dong\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 08 Mar 2007 22:10:15.0652 (UTC) FILETIME=[8CC97A40:01C761CE] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 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, Concerning the integration of features into QoS application, I'd like to have discussion on some high level issues before getting into detailed edits.=20 some items could be considered in my mind. Once we have consensus on these items, the relevant mechanisms can be discussed afterwards. 1. Support of Push Model as defined in the "resource control application requirements" I feel it is critical to support both Pull and Push models in the same framework. The Push model here refers to the case that no Diameter session is pre-established from NE (Diameter Client) to authorizing entity (Diameter server). In fact, the Push model is perceived as the trend to support the policy control due to the merits of flexibility, complexity and scalability required on the underlying network technologies. Further details can be found in the aforementioned document.=20 2. Extension of the scope of QoS application=20 The current QoS application mainly addresses one aspect of resource control/policy enforcement, i.e. bandwidth and performance metrics. Although it is one of the most important aspects, it would be good to include some other aspects, e.g. NAT traversal and NAPT control since these functions are commonly collocated with QoS policy enforcement in the same NE, which results in some correlation between them, e.g. the change of media flow IP 5-tuple. 3. Compatibility of command codes with other SDOs I have no strong preference on the command codes, but just concerned about the usage of the QoS application in reality due to the incompatibility. Just wondering if it is possible to make 3GPP/PP2 modify their specs according to the command codes currently defined in QoS application document? If not, who will use this document in the implementation? For which kind of use cases? Regards, Dong =20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Thursday, March 08, 2007 5:05 AM To: Sun, Dong (Dong) Cc: dime@ietf.org Subject: Re: [Dime] Updated QoS Drafts Hi Dong, thanks for your clarifications. Please find some comments below: Sun, Dong (Dong) wrote: > =20 > Hi, > Some clarifications and comments: > ~~~~~~~~~~~~~ > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, March 07, 2007 5:51 AM > To: dime@ietf.org > Subject: [Dime] Updated QoS Drafts > > Hi all, > ... > ... > " > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-re > qu > irements-01 > > This document takes a different spin and extends the=20 > > document by supporting a "generic push" approach. By "generic push"=20 > I refer to the > ability of an arbitrary entity, such as an SIP proxy, to signal to=20 > another box. > Note that this is not the same as the server-initiated communication. > " > ~~~~~~~~~~~~~~~~~ > > [Dong] The "Push model" defined in above I-D doesn't aim to define the > ability of an arbitrary entity, such as a SIP proxy, to signal to=20 > another box. This document actually addresses the same interface as in > the current QoS application (draft-ietf-dime-diameter-qos-00). Since=20 > the current QoS application only supports the Pull model that is not=20 > suitable for some circumstances (e.g. when the network elements cannot > trigger the QoS authorization request and/or the endpoint does not=20 > support any QoS signaling/capability, which is quite common in=20 > wireline networks), the I-D intends to complement current QoS=20 > application document and make a generic framework in order to support=20 > various networks, endpoints and applications. > =20 I agree that draft-ietf-dime-diameter-qos-00 is not particularly strong on the description of server-initiated communication. This is, however, a basic feature of the Diameter Base protocol. =20 Typically, server-initiated messages are still sent after the initial session setup took place based on an interaction with the Diameter client. For example, you have a network access authentication procedure taking place. Then, during the lifetime of the session some authorization relevant aspects change at the Diameter server and it initiates a re-authorization exchange. > Currently, this document mainly focuses on discussing the requirements > and framework of a generic resource control system, and also proposes=20 > some potential solutions to solve the issue. IMO, it will be better to > integrate this document with QoS application document together to=20 > formulate a single document on this subject since the scope and=20 > objective of these two are quite similar. > > =20 I agree that it would be good to integrate features whenever possible. We just need to figure out how todo that. > I'd like to get others' opinion on the integration of these two=20 > documents. > > P.S.: the solution proposed in this document is kind of Diameter=20 > server initiated communication. There are some discussions on this=20 > issue in the exploder recently triggered by an ITU-T liaison, it has=20 > not yet reached a consensus though. > =20 Ciao Hannes =20 > Regards, > Dong > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > =20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 14 10:54:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUrr-0006K8-4R; Wed, 14 Mar 2007 10:54:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRUrp-0006Iy-Tu for dime@ietf.org; Wed, 14 Mar 2007 10:54:17 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRUrj-0006fV-SB for dime@ietf.org; Wed, 14 Mar 2007 10:54:17 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id B39475944D for ; Wed, 14 Mar 2007 09:54:11 -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 l2EEsAGV029591 for ; Wed, 14 Mar 2007 10:54:10 -0400 (EDT) From: "Tolga Asveren" To: Date: Wed, 14 Mar 2007 09:48:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0212_01C7661D.EB86C030" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Importance: Normal Received-SPF: none X-Spam-Score: 0.0 (/) X-Scan-Signature: 4bf50494b99065e6ffd61702a66bcf2c Subject: [Dime] Diameter Auditing Consideration Draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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_000_0212_01C7661D.EB86C030 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Ulf and I tried to prepare a draft to provide background information about Diameter auditing. It addresses issues like parameter to consider when designing state recovery mechanisms and different design choices. We couldn't finish the document before cut-off date but we believe it could be usefull for people which are interested in Diameter auditing work so we decided to send the unofficial 00 version of the draft to the list. Thanks, Tolga ------=_NextPart_000_0212_01C7661D.EB86C030 Content-Type: text/plain; name="draft-asveren-dime-state-recovery-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-asveren-dime-state-recovery-00.txt" =0A= =0A= =0A= Network Working Group T. Asveren=0A= Internet-Draft Ulticom Inc.=0A= Expires: September 21, 2007 U. Bodin=0A= Operax=0A= March 20, 2007=0A= =0A= =0A= Diameter State Recovery Considerations=0A= draft-asveren-dime-state-recovery-00.txt=0A= =0A= Status of this Memo=0A= =0A= By submitting this Internet-Draft, each author represents that any=0A= applicable patent or other IPR claims of which he or she is aware=0A= have been or will be disclosed, and any of which he or she becomes=0A= aware will be disclosed, in accordance with Section 6 of BCP 79.=0A= =0A= Internet-Drafts are working documents of the Internet Engineering=0A= Task Force (IETF), its areas, and its working groups. Note that=0A= other groups may also distribute working documents as Internet-=0A= Drafts.=0A= =0A= Internet-Drafts are draft documents valid for a maximum of six months=0A= and may be updated, replaced, or obsoleted by other documents at any=0A= time. It is inappropriate to use Internet-Drafts as reference=0A= material or to cite them other than as "work in progress."=0A= =0A= The list of current Internet-Drafts can be accessed at=0A= http://www.ietf.org/ietf/1id-abstracts.txt.=0A= =0A= The list of Internet-Draft Shadow Directories can be accessed at=0A= http://www.ietf.org/shadow.html.=0A= =0A= This Internet-Draft will expire on September 21, 2007.=0A= =0A= Copyright Notice=0A= =0A= Copyright (C) The IETF Trust (2007).=0A= =0A= Abstract=0A= =0A= This document discusses parameters to consider, different approaches=0A= and design strategies to synchronize and/or recover state in Diameter=0A= applications after failure of an active instance.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 1]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Table of Contents=0A= =0A= 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3=0A= 3. Session State and the Need for Recovery . . . . . . . . . . . 4=0A= 4. Proprietary Mechanisms . . . . . . . . . . . . . . . . . . . . 5=0A= 5. Protocol Assisted State Recovery . . . . . . . . . . . . . . . 6=0A= 5.1. Service Models . . . . . . . . . . . . . . . . . . . . . . 6=0A= 5.2. Parameters to Consider . . . . . . . . . . . . . . . . . . 8=0A= 5.2.1. Notification of the Peer About Failure . . . . . . . . 8=0A= 5.2.2. Transfer of Session Data . . . . . . . . . . . . . . . 8=0A= 5.2.3. Backup Server Selection . . . . . . . . . . . . . . . 9=0A= 5.2.4. Timing of State Reconstruction . . . . . . . . . . . . 10=0A= 5.3. Approaches . . . . . . . . . . . . . . . . . . . . . . . . 10=0A= 5.3.1. Using a New Session . . . . . . . . . . . . . . . . . 11=0A= 5.3.2. Backup Instance Triggered Recovery . . . . . . . . . . 11=0A= 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12=0A= 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12=0A= 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12=0A= 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12=0A= Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12=0A= Intellectual Property and Copyright Statements . . . . . . . . . . 14=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 2]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= 1. Introduction=0A= =0A= There are a variaety of Diameter applications defined to perform=0A= different tasks. For some of these tasks, synchronizing and/or=0A= recovering state for ongoing sessions after failure of a Diameter=0A= endpoint is desirable, e.g. Diameter Credit Control Application.=0A= The recovery could be achieved by a proprietary mechanism, could be=0A= assisted by protocol mechanisms or could be a combination thereof.=0A= This document focuses on issues associated with protocol assisted=0A= state recovery.=0A= =0A= =0A= 2. Terminology=0A= =0A= The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=0A= "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=0A= document are to be interpreted as described in [2].=0A= =0A= The following terms defines the functionality used in describing=0A= entities in this document.=0A= =0A= Ongoing Session=0A= =0A= A Diameter session, for which at least the first transaction has=0A= been completed but not the last transaction according to the=0A= application message flow.=0A= =0A= Terminated Session=0A= =0A= A Diameter session that existed in the past, for which the last=0A= transaction according to the application message flow has been=0A= completed.=0A= =0A= Initial message=0A= =0A= A Diameter message used to create a new Diameter session.=0A= =0A= Mid-session message=0A= =0A= A Diameter message used to refresh or modify an existing Diameter=0A= session.=0A= =0A= Service Instance=0A= =0A= An instance of service provided by a Diameter application to=0A= another entity, e.g. charging, authentication services.=0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 3]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Diameter Transaction=0A= =0A= A Diameter request/answer pair.=0A= =0A= =0A= 3. Session State and the Need for Recovery=0A= =0A= Some Diameter applications make use of sessions consisting of=0A= multiple transactions. The context necessary to be able to process/=0A= trigger further messages in an ongoing session constitutes the=0A= session state.=0A= =0A= In multi-transaction sessions, it is possible that one of the=0A= endpoints fail during a session. Depending on the application, it=0A= may not be possible/desirable to terminate the corresponding service=0A= instance. In such a case, it is necessary to utilize a backup node=0A= which can process messages for the ongoing session or to use a new=0A= session without terminating the service instance.=0A= =0A= Diameter Active Backup=0A= Peer Instance Instance=0A= | | |=0A= |----REQ1---->| |=0A= | (session1) | |=0A= | | |=0A= |<---ANS1-----| |=0A= | (session1) | |=0A= | | |=0A= | Active |=0A= | Instance |=0A= | Fails |=0A= | | |=0A= |----REQ2----------------->|=0A= | (session1) | |=0A= | | |=0A= |<---ANS2------------------|=0A= | (session1) | |=0A= | | |=0A= =0A= =0A= Figure 1: Session Failover to Backup Instance=0A= =0A= Another important aspect related with failing instances is the=0A= possibility of hanging resources on the peer Diameter entity. This=0A= could happen if the peer Diameter entity does not clean up session=0A= state unless the session is terminated according to the expected=0A= application message flow. It should be noted that while state=0A= recovery is a desirable feature for certain applications, hanging=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 4]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= resources is an unacceptable situation for all applications, hence=0A= although some of the mechanisms described in this document could be=0A= used to prevent the occurance of such a case, it is recommended that=0A= application layer mechanisms, e.g. application layer timers, are used=0A= for this purpose. Nonetheless, certain strategies mentioned in this=0A= document could be used to expedite session state cleanup after=0A= failovers.=0A= =0A= =0A= 4. Proprietary Mechanisms=0A= =0A= Proprietary mechanisms do not assume any specific behavior from their=0A= peers. They usually rely on some form of state replication between=0A= active and backup instances.=0A= =0A= +---------+ +----------+=0A= | Diameter|<------------->| Active |=0A= | Peer | Session | Instance |=0A= +---------+ Messaging +----------+=0A= ^=0A= | Session=0A= | State=0A= | Replication=0A= V=0A= +----------+=0A= | Backup |=0A= | Instance |=0A= +----------+=0A= =0A= =0A= Figure 2: Data Replication with a Proprietary Machanism=0A= =0A= It should be noted that Figure 2 is just an abstract representation=0A= of proprietary data replication between active and backup instances.=0A= Actual implementation may vary depending on the mechanims used.=0A= Proprietary state synchronization is a common technique utilized by=0A= Public Switched Telephone Network equipment vendors to provide 5 9's=0A= reliability. There are also initiatives to define a standard set of=0A= APIs for platforms/middleware providing data synchronization=0A= services, e.g. Application Interface Specification of Service=0A= Availability Forum.=0A= =0A= Proprietary data replication between active and backup instances may=0A= be asynchronous in nature. This means that they may not provide=0A= loss-less state replication at all times. Hence, after a failover to=0A= a backup instance, some session states may have been lost and other=0A= states may be wrongly kept by the backup instance. That is, states=0A= may have been terminated through session signalling to the initially=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 5]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= active instance but the removal of the corresponding session states=0A= were not properly reflected in the data replication process.=0A= =0A= =0A= 5. Protocol Assisted State Recovery=0A= =0A= Protocol assisted state recovery relies on contents of the messages=0A= exchanged between Diameter entities.=0A= =0A= 5.1. Service Models=0A= =0A= For each Diameter session Diameter messaging happens between a client=0A= and server. Although not a sender/receiver of Diameter messages,=0A= physical service/resource provided is also a parameter when designing=0A= state recovery mechanisms. The physical resource/service is=0A= application dependent and could be bandwith allocated on a router for=0A= QoS application, voice transfer resources used for a prepaid voice=0A= call application etc.=0A= =0A= Depending on Diameter application, physical resource/service could be=0A= at the client or server side. For example for Diameter Credit=0A= Control Application the physical resource is controlled by the=0A= client, whereas for QoS application with a push scenario it is=0A= controlled by the server.=0A= =0A= In case a proprietary data replication mechanism which is not loss-=0A= less is used between active and backup instances to support failover,=0A= it may be desirable to make use of the data present in the physical=0A= resource/service. This case can benefit from a synchronization phase=0A= before session data is transfered for purposes of rebuilding lost=0A= state.=0A= =0A= Physical resource/service could be used to extract some information=0A= regarding session state to be reconstructed. For certain scenarios=0A= this information could be enough for state reconstruction or could be=0A= used in addition to information obtained via other means, e.g. in a=0A= proprietary data replication mechanism, failovers could be followed=0A= by a synchronization phase based on information obtained from the=0A= physical resource/service.=0A= =0A= Below is given a conceptual diagram for the DCCA client side state=0A= recovery utilizing the state kept by service control logic.=0A= =0A= +-----+=0A= | +-------+=0A= | | (2) |=0A= ---(1)--->| |Service|=0A= Service | | Data-1|=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 6]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Start | +-------+ +---------+=0A= Request | | | |=0A= | |-----(3)------->| |=0A= | |Credit Control | DCCA |=0A= | | Request for | Client |---(4)----->=0A= | | Service Data-1 | Logic | CCR(Initial)=0A= | | | (Active)|=0A= | | | |<---(5)------=0A= | |<-----(6)-------| | CCA(Initial)=0A= | | Grant Service +---------+=0A= | |=0A= | S | (7)=0A= | e | DCCA Client=0A= | r | Logic (Active)=0A= | v | fails=0A= | i |=0A= | c | (8)=0A= | e | DCCA Client=0A= | | Logic (Standby)=0A= | C | detects failure=0A= | o |=0A= | n | +---------+=0A= | t |<-----(9)-------| |=0A= | r | Request for | |=0A= | o | State Retrieval| DCCA |=0A= | l | | Client |=0A= | |-------(10)---->| Logic |=0A= | | Credit Control |(Standby)|---(11)---->=0A= | | Request for | | CCR(Initial)=0A= | | Service Data-1 | |=0A= | | | |<---(12)-----=0A= | | | | CCA(Initial)=0A= | | | |=0A= | | | |---(13)---->=0A= | | | | CCR(Update)=0A= | | | |=0A= | | | |<---(14)-----=0A= ---(15)-->| | | | CCA(Update)=0A= Service | | | |=0A= End | | | |---(16)---->=0A= Request | | | | CCR(Terminate)=0A= | | | |=0A= | | | |<---(17)-----=0A= +-----+ +---------+ CCA(Terminate)=0A= =0A= =0A= Figure 3: Using Service Information for DCCA Client Side State=0A= Recovery=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 7]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= 5.2. Parameters to Consider=0A= =0A= There are several aspects which may be important for a protocol=0A= assisted session state recovery mechanism. They may or may not be=0A= part of the design choices for a protocol assisted session state=0A= recovery mechanism, depending on the strategy utilized.=0A= =0A= 5.2.1. Notification of the Peer About Failure=0A= =0A= Usually it is necessary for the remote peer to be informed about the=0A= failure of the active instance in the context of protocol assisted=0A= state recovery. This could be achieved in different ways:=0A= =0A= Application Layer Timers=0A= =0A= Application layer timers could be utilized to send new requests=0A= periodically. Lack of a new request or a corresponding answer for=0A= a sent request/receipt or UNABLE_TO_DELIVER error answer could=0A= indicate that the peer Diameter entity has failed.=0A= =0A= Notification from Standby Instance=0A= =0A= After failure of the active instance, standby instance can send a=0A= message to the remote Diameter peer to inform it about failure of=0A= the active instance.=0A= =0A= 5.2.2. Transfer of Session Data=0A= =0A= For protocol assisted recovery it is necessary to supply enough=0A= information to the backup instance so that session state can be=0A= constructed. What constitutes session state data needs to be defined=0A= on a per application basis. Also, in certain cases (e.g. when a=0A= separate mechanism for state replication is used in combination with=0A= protocol asisted state recovery) the transfer of session data may be=0A= preceeded by a state synchronization phase. For example, a generic=0A= message providing a list of all active sessions could be used for=0A= such a synchronization phase.=0A= =0A= Some approaches to transfer session data include:=0A= =0A= Using a New Session=0A= =0A= Upon detection of the failure of the active instance, remote=0A= Diameter peer may start a new session without terminating the=0A= service instance.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 8]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Using Application Messages=0A= =0A= Data necessary to reconstruct the session state may be transferred=0A= in an application defined message by AVP(s) specifically defined=0A= for that purpose. Alternatively, an AVP may be used to flag that=0A= all data carried in the message is sent for the purposes of state=0A= synchronization.=0A= =0A= Using a Generic Message=0A= =0A= Data necesary to reconstruct session state may be transferred in a=0A= message specifically defined for that purpose. Such a message may=0A= carry state information for one or multiple sessions.=0A= =0A= 5.2.3. Backup Server Selection=0A= =0A= A Diameter peer needs to know the identity of the backup instance, so=0A= that it can send the necessary data to reconstruct session state.=0A= Furthermore, loadbalancing of the ongoing sessions to different=0A= backup instances may be necessary as well, to prevent overloading of=0A= backup entities.=0A= =0A= Active Instance Guided Selection=0A= =0A= Active instance could communicate the identity of the backup=0A= instance(s) to the peer Diameter entity with an AVP. Information=0A= about how the load should be distributed among multiple backup=0A= instances could be communicated as well.=0A= =0A= Backup Instance Guided Selection=0A= =0A= If the notification of the peer Diameter entity about the failure=0A= of the active instance is performed via a message sent by the=0A= standby instance, the identity of the backup instance would be=0A= known to the the peer Diameter entity. This message could carry=0A= information about other backup instances and loadsharing=0A= information too.=0A= =0A= Selection Based on Configuration=0A= =0A= The Diameter peer may know the identities of backup servers=0A= through configuration and try to loadshare ongoing session based=0A= on a locally defined algorithm. For requests, which are rejected=0A= by a standby instance with TOO_BUSY_HERE error answer, another=0A= standby instance could be tried.=0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 9]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= 5.2.4. Timing of State Reconstruction=0A= =0A= When state reconstruction should happen may vary depending on the=0A= application. The following two models are foreseen:=0A= =0A= State Reconstruction After Failure=0A= =0A= It may be necessary to reconstruct the state after the backup=0A= instance detects failure of the active instance. This model is=0A= useful when the state for ongoing sessions is necessary to=0A= generate answers for requests belonging to new sessions. Care=0A= should be taken when determining the necessary information for=0A= such cases, it could be the case that what is needed is some=0A= cumulative data based on session states rather than the per=0A= session information and this could impact the design choices to=0A= recover/replicate the data or even the choice between a=0A= proprietary mechanism and protocol assisted recovery.=0A= =0A= Another use case is when autonomous requests need to be generated=0A= from the side, where the active instance has failed. In such a=0A= situation, backup instance needs to know ongoing sessions=0A= immediately after it detects failure of the active instance so=0A= that it can generate autonomous requests.=0A= =0A= If state reconstruction after failure is needed, notification of=0A= the Diameter peer about failure should be done by the backup=0A= instance.=0A= =0A= State Reconstruction Upon Receipt of a Request=0A= =0A= For certain applications, it could be enough if a backup server=0A= can reply for requests for ongoing sessions after the failure of=0A= the active instance. In such scenarios, state information=0A= contained in the new requests for ongoing sessions (i.e. mid-=0A= session messages) could be used to reconstruct session state on=0A= the standby instance.=0A= =0A= 5.3. Approaches=0A= =0A= The choice between a proprietary and protocol assisted state recovery=0A= mechanism is not a straightforward one. Depending on the application=0A= and the reliability level required a detailed analysis needs to be=0A= done to justify usage of one of the methods.=0A= =0A= If it is desired to use protocol assisted recovery, parameters=0A= discussed in Section 5.2 need to be considered. It should be noted=0A= that choices made for different parameters are not always independent=0A= of each other, e.g. if state reconstruction immediately after failure=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 10]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= detection is necessary, using a new session to transfer session data=0A= strategy can't be utilized. Below, two different approaches are=0A= discussed in detail.=0A= =0A= 5.3.1. Using a New Session=0A= =0A= As mentioned in Section 5.2.2 a new session can be used to rebuild=0A= state after failure. This approach can be sufficient if immediate=0A= state reconstruction after failure is not needed. That is, knowledge=0A= of the history of the session are not needed to proceed providing the=0A= service of the failed over Diameter node. An example diagram is=0A= given in Figure 3. It focuses on events happening on the client side=0A= for a DCCA session. On the server side, the sessions which were=0A= created by the active instance are cleaned up after expiry of Tcc=0A= timer.=0A= =0A= A variant of using a new session for rebuilding state is to use=0A= application messages. For example, regular mid-session messages=0A= maintaining soft-state can be used if they contain enough information=0A= for the desired state reconstruction. Such messages could contain an=0A= AVP carrying a flag indicating that it's a mid-session message and=0A= not an initial message issued to create a completely new session.=0A= The ability to separate between recreated session and new session can=0A= be important to some applications. For example, it may be desirable=0A= to give recreated sessions preference over new session to resources=0A= controlled by a Diameter server.=0A= =0A= 5.3.2. Backup Instance Triggered Recovery=0A= =0A= In case immediate state reconstruction is desired or strictly needed=0A= by a backup Diameter instance, this instance may need to trigger=0A= transfer of session data to recover state. This requires session=0A= data to be available and reachable to the backup Diameter instance.=0A= Possible locations of such data include the physical resource/service=0A= controlled by the failed over Diameter instance and the entities=0A= utilizing the service offered by the Diameter instance (i.e. entities=0A= issuing Diameter requests for the offered service).=0A= =0A= As mentioned in Section 5.2.2 application application messages or a=0A= generic message can be used to transfer session data for state=0A= reconstruction. Application messages or a generic message=0A= transferring the desired session data could be preceeded by a generic=0A= synchronization message providing the backup Diameter instance with a=0A= complete list of all active sessions. By that the backup Diameter=0A= instance can distribute the recovery of session data over time. This=0A= may be useful if this instance is to start provide its service=0A= imediately instead of waiting until the state reconstruction process=0A= is completed. Requesting session data in parallel with answering to=0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 11]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= service requests requires however that period with incomplete session=0A= state after that the backup Diameter instance starts providing the=0A= service is acceptable.=0A= =0A= A generic synchronization message can also be useful in a combined=0A= solution using both a proprietary mechanism for state replication and=0A= protocol aided state recovery. The complete list of all active=0A= sessions provided in such a message providing can be compared with=0A= the list of sessions replicated through a proprietary mechansism.=0A= Thereby a potential mis-match can be identified and missing session=0A= data can be explicitly requested by the backup Diameter instance.=0A= =0A= =0A= 6. IANA Considerations=0A= =0A= This document does not require any IANA action.=0A= =0A= =0A= 7. Security Considerations=0A= =0A= Certain procedures in protocol assisted state recovery, e.g.=0A= notification of the Diameter peer about failure of an active instance=0A= by the standby instance, could introduce security risks. It is=0A= expected that use of IPSec/TLS together with a transitive trust model=0A= should eliminate these concerns.=0A= =0A= =0A= 8. Acknowledgments=0A= =0A= =0A= 9. Normative References=0A= =0A= [1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,=0A= "Diameter Base Protocol", RFC 3588, September 2003.=0A= =0A= [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement=0A= Levels", BCP 14, RFC 2119, March 1997.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 12]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Authors' Addresses=0A= =0A= Tolga Asveren=0A= Ulticom Inc.=0A= 1020 Briggs Road=0A= Mount Laurel, NJ, 08054=0A= USA=0A= =0A= Email: asveren@ulticom.com=0A= =0A= =0A= Ulf Bodin=0A= Operax=0A= Aurorum Science Park 8=0A= SE-977 75 Lulea=0A= Sweden=0A= =0A= Email: uffe@operax.com=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 13]=0A= =0C=0A= Internet-Draft Diameter State Recovery Considerations March 2007=0A= =0A= =0A= Full Copyright Statement=0A= =0A= Copyright (C) The IETF Trust (2007).=0A= =0A= This document is subject to the rights, licenses and restrictions=0A= contained in BCP 78, and except as set forth therein, the authors=0A= retain all their rights.=0A= =0A= This document and the information contained herein are provided on an=0A= "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS=0A= OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND=0A= THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS=0A= OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=0A= THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=0A= WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.=0A= =0A= =0A= Intellectual Property=0A= =0A= The IETF takes no position regarding the validity or scope of any=0A= Intellectual Property Rights or other rights that might be claimed to=0A= pertain to the implementation or use of the technology described in=0A= this document or the extent to which any license under such rights=0A= might or might not be available; nor does it represent that it has=0A= made any independent effort to identify any such rights. Information=0A= on the procedures with respect to rights in RFC documents can be=0A= found in BCP 78 and BCP 79.=0A= =0A= Copies of IPR disclosures made to the IETF Secretariat and any=0A= assurances of licenses to be made available, or the result of an=0A= attempt made to obtain a general license or permission for the use of=0A= such proprietary rights by implementers or users of this=0A= specification can be obtained from the IETF on-line IPR repository at=0A= http://www.ietf.org/ipr.=0A= =0A= The IETF invites any interested party to bring to its attention any=0A= copyrights, patents or patent applications, or other proprietary=0A= rights that may cover technology that may be required to implement=0A= this standard. Please address the information to the IETF at=0A= ietf-ipr@ietf.org.=0A= =0A= =0A= Acknowledgment=0A= =0A= Funding for the RFC Editor function is provided by the IETF=0A= Administrative Support Activity (IASA).=0A= =0A= =0A= =0A= =0A= =0A= Asveren & Bodin Expires September 21, 2007 [Page 14]=0A= =0C=0A= =0A= ------=_NextPart_000_0212_01C7661D.EB86C030 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_000_0212_01C7661D.EB86C030-- From dime-bounces@ietf.org Wed Mar 14 17:21:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRauw-0001Vj-7P; Wed, 14 Mar 2007 17:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRauv-0001VZ-Jm for dime@ietf.org; Wed, 14 Mar 2007 17:21:53 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRauu-0006vd-5h for dime@ietf.org; Wed, 14 Mar 2007 17:21:53 -0400 Received: (qmail invoked by alias); 14 Mar 2007 21:21:50 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp027) with SMTP; 14 Mar 2007 22:21:50 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19QSLJ1pRBQDKqxOjn/2wvBTuyfo6VdFrdJLjyoPU BWOpbDKp5Vc40f Message-ID: <45F8676C.5090404@gmx.net> Date: Wed, 14 Mar 2007 22:21:48 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 93238566e09e6e262849b4f805833007 Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document (see http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) we defined a new Diameter application and we then decided that we should separate the authentication and authorization interaction to avoid an update of this specification when RFC 4072 is updated. This means that the Diameter MIPv6 app-ID is used for the authorization part and the Diameter EAP app-ID is used for the authentication part. Diameter routing may cause authentication and authorization messages to be routed to different servers. This caused a lengthy debate on security issues. It seems that there is a lot of complexity associated with this approach. I would therefore like to hear whether working group members are OK with performing authentication and authorization as part of one Diameter application. This would therefore mean that we are going to use the Diameter MIPv6 app-ID for authentication and for authorization. Please state your opinion. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 14 18:56:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRcOC-0007wH-JT; Wed, 14 Mar 2007 18:56:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRcOB-0007wC-Hx for dime@ietf.org; Wed, 14 Mar 2007 18:56:11 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRcO9-0006HN-E7 for dime@ietf.org; Wed, 14 Mar 2007 18:56:10 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 23:56:07 +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] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Date: Wed, 14 Mar 2007 23:55:39 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260462DF33@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Thread-Index: Acdmfy+Y0GPTMvkET0aYb14eCdiAOQAC/vsQ From: "MORAND Lionel RD-CORE-ISS" To: "Hannes Tschofenig" , X-OriginalArrivalTime: 14 Mar 2007 22:56:07.0701 (UTC) FILETIME=[F39D5450:01C7668B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I'm fine with that proposal. I would add that the authentication procedures defined for the Diameter = MIPv6 application must be flexible enough to support various = authentication modes/schemes. BR, Lionel > -----Message d'origine----- > De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Envoy=E9 : mercredi 14 mars 2007 22:22 > =C0 : dime@ietf.org > Objet : [Dime] Consensus Call regarding Diameter Mobile IPv6=20 > HA-to-AAAHsupport >=20 > Hi all, >=20 > with our work on the "Diameter Mobile IPv6 HA-to-AAAH=20 > support" document (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided=20 > that we should separate the authentication and authorization=20 > interaction to avoid an update of this specification when RFC=20 > 4072 is updated. This means that the Diameter MIPv6 app-ID is=20 > used for the authorization part and the Diameter EAP app-ID=20 > is used for the authentication part. Diameter routing may=20 > cause authentication and authorization messages to be routed=20 > to different servers. This caused a lengthy debate on=20 > security issues.=20 > It seems that there is a lot of complexity associated with=20 > this approach. >=20 > I would therefore like to hear whether working group members=20 > are OK with performing authentication and authorization as=20 > part of one Diameter application. This would therefore mean=20 > that we are going to use the Diameter MIPv6 app-ID for=20 > authentication and for authorization. >=20 > Please state your opinion. >=20 > Ciao > Hannes >=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 Mar 14 22:33:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRflo-0002Fz-AG; Wed, 14 Mar 2007 22:32:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRfln-0002Fu-5Z for dime@ietf.org; Wed, 14 Mar 2007 22:32:47 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRfll-0000Qs-Pp for dime@ietf.org; Wed, 14 Mar 2007 22:32:47 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2007 19:32:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l2F2WjIR023458; Wed, 14 Mar 2007 19:32:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l2F2WjEk006614; Thu, 15 Mar 2007 02:32:45 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Mar 2007 19:32:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Date: Wed, 14 Mar 2007 19:32:43 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250398A1D0@xmb-sjc-215.amer.cisco.com> In-Reply-To: <45F8676C.5090404@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Thread-Index: AcdmfzBLxGEX9pjPRuiGD2bjF2c+5QAKvBuA References: <45F8676C.5090404@gmx.net> From: "Glen Zorn \(gwz\)" To: "Hannes Tschofenig" X-OriginalArrivalTime: 15 Mar 2007 02:32:45.0040 (UTC) FILETIME=[36A1DF00:01C766AA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1423; t=1173925965; x=1174789965; c=relaxed/simple; s=sjdkim3002; 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]=20Consensus=20Call=20regarding=20Diameter=20Mo bile=20IPv6=20HA-to-AAAHsupport |Sender:=20; bh=YKEI7DU0ARRMHcO8H0kO+DiDeL0rve3KpyZVXKozb6Y=; b=fNez5Ue9SgsrgXsCCVzGY8Xd1guE6IKDpShDOTJJCSItZmwV9WJI6a3v/IATNup18vTbcv7n J95s6IJC6d5ybTyBzDgYem0u6v6gy+LiMGSmFQEVE0ckSM71syrWP8G7; Authentication-Results: sj-dkim-3; header.From=gwz@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Hannes Tschofenig allegedly scribbled on Wednesday, March 14, 2007 2:22 PM: > Hi all, >=20 > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > document (see=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we > should separate the authentication and authorization interaction to > avoid an update of this specification when RFC 4072 is updated. This > means that the Diameter MIPv6 app-ID is used for the authorization > part and the Diameter EAP app-ID is used for the authentication part. > Diameter routing may cause authentication and authorization messages > to be routed to different servers. This caused a lengthy debate on > security issues. It seems that there is a lot of complexity > associated with this approach. =20 >=20 > I would therefore like to hear whether working group members are OK > with performing authentication and authorization as part of one > Diameter application. This would therefore mean that we are going to > use the Diameter MIPv6 app-ID for authentication and for > authorization. =20 Works for me. >=20 > Please state your opinion. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 14 23:06:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgIQ-0003oK-NG; Wed, 14 Mar 2007 23:06:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRgIP-0003o4-Fp for dime@ietf.org; Wed, 14 Mar 2007 23:06:29 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRgIO-00077i-5t for dime@ietf.org; Wed, 14 Mar 2007 23:06:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Date: Wed, 14 Mar 2007 23:06:27 -0400 Message-ID: In-Reply-To: <45F8676C.5090404@gmx.net> From: "Avi Lior" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Yes. Authentication -- the EAP part and Authorization should happen in one Diameter Application.=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Wednesday, March 14, 2007 5:22 PM To: dime@ietf.org Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Hi all, with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document (see http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) we defined a new Diameter application and we then decided that we should separate the authentication and authorization interaction to avoid an update of this specification when RFC 4072 is updated. This means that the Diameter MIPv6 app-ID is used for the authorization part and the Diameter EAP app-ID is used for the authentication part. Diameter routing may cause authentication and authorization messages to be routed to different servers. This caused a lengthy debate on security issues.=20 It seems that there is a lot of complexity associated with this approach. I would therefore like to hear whether working group members are OK with performing authentication and authorization as part of one Diameter application. This would therefore mean that we are going to use the Diameter MIPv6 app-ID for authentication and for authorization. Please state your opinion. Ciao Hannes _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 02:49:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjlr-0006uJ-3i; Thu, 15 Mar 2007 02:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRjlp-0006u0-Km for dime@ietf.org; Thu, 15 Mar 2007 02:49:05 -0400 Received: from ceiling.dave.sonera.fi ([131.177.130.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRjlo-0003K7-3m for dime@ietf.org; Thu, 15 Mar 2007 02:49:05 -0400 Received: from ceiling.dave.sonera.fi (localhost [127.0.0.1]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l2F6n2DS004870 for ; Thu, 15 Mar 2007 08:49:03 +0200 (EET) Received: from [131.177.37.116] (l50029133.pool.sonera.fi [131.177.37.116]) by ceiling.dave.sonera.fi (Sendmail) with ESMTP id l2F6n2hD004867; Thu, 15 Mar 2007 08:49:02 +0200 (EET) Message-ID: <45F8EC5D.2020301@teliasonera.com> Date: Thu, 15 Mar 2007 08:49:01 +0200 From: Jouni Korhonen User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport References: <45F8676C.5090404@gmx.net> In-Reply-To: <45F8676C.5090404@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi, Hannes Tschofenig kirjoitti: [snip-sanp] > I would therefore like to hear whether working group members are OK with > performing authentication and authorization as part of one Diameter > application. This would therefore mean that we are going to use the > Diameter MIPv6 app-ID for authentication and for authorization. I prefer one application. Cheers, Jouni > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 03:45:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRkeW-0000vW-Lo; Thu, 15 Mar 2007 03:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRkeV-0000vL-Bm for dime@ietf.org; Thu, 15 Mar 2007 03:45:35 -0400 Received: from smtp.stumbleupon.com ([69.36.233.8] helo=zoe.stumbleupon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRkeR-0007QC-Uz for dime@ietf.org; Thu, 15 Mar 2007 03:45:35 -0400 Received: by zoe.stumbleupon.com (Postfix, from userid 48) id D767C24DB0D3; Thu, 15 Mar 2007 00:44:54 -0700 (PDT) To: dime@ietf.org Date: Thu, 15 Mar 2007 00:44:54 -0700 From: himanshu.rawat@gmail.com Message-ID: <872288a8400612516796c49be2703cd0@video.stumbleupon.com> X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 X-Spam-Score: -3.8 (---) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Dime] himanshu.rawat@gmail.com shared a video with you X-BeenThere: dime@ietf.org X-Mailman-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="===============1505287510==" Errors-To: dime-bounces@ietf.org --===============1505287510== Content-Type: multipart/alternative; boundary="b1_872288a8400612516796c49be2703cd0" --b1_872288a8400612516796c49be2703cd0 Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: quoted-printable StumbleVideo See what's on your channel! DJ Tiesto @ TMF Awards 2k5 - Google Video : http://video.stumbleupon.com?s=3D7aiea6gn26&i=3Dc6a94j1euyjkwstnczoq Check out this video. It's really cool! -- rawath (himanshu.rawat@gmail.com) Learn more about StumbleVideo or Try It Now at http://video.stumbleupon.com ! *About StumbleVideo* StumbleVideo allows you to channel-surf great videos from throughout the internet based upon your interests -- creating your own Personal Video Channel. You too can discover, rate and share videos. Learn More or Try It Now! (c) StumbleUpon 2001-2007 --b1_872288a8400612516796c49be2703cd0 Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D=

StumbleVideo

See what's o= n your channel

Check out this video. It's really cool!

=09 3D"Watch=

3D"Watch
DJ Tiesto @ TMF Awards 2k5 - Google= Video

- rawath (himanshu.rawat@gm= ail.com)
About StumbleVideo
StumbleVideo allows you to channel surf great videos from throughout t= he internet based upon your interests - creating your own Personal Video = Channel. You too can discover, rate and share videos.=20 Learn More or Try It Now!
© StumbleUpon 2001-2007
--b1_872288a8400612516796c49be2703cd0-- --===============1505287510== 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 --===============1505287510==-- From dime-bounces@ietf.org Thu Mar 15 05:00:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRloT-00069w-3A; Thu, 15 Mar 2007 04:59:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRloS-00069n-L6 for dime@ietf.org; Thu, 15 Mar 2007 04:59:56 -0400 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRloR-0007mg-AJ for dime@ietf.org; Thu, 15 Mar 2007 04:59:56 -0400 Received: by ug-out-1314.google.com with SMTP id 72so219260ugd for ; Thu, 15 Mar 2007 01:59:54 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oiPHe451QHQlLKnbRAzHwTSVopqGphN0ju6vwo77KWzFZT3cEAZ1hQVc6b4pq1x2ZuaiYvG9vFTI14HdLy+xmpBD5OhzQSCoC+GJxkJuY/xTWLLWk/7xKwykbgyo0e/qDAD77k0hrcnJiSNlNGbDi0jhFJyqzHBEXQejLcHDGT8= 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=CAZe8jIPyiHehrn2/UcPrqNC44eg3IRhOqnmmTvCe7Z5+B7wU+laGZ72b9d8FK8MbN2GG4zv+Uokb22IBYP24Hbc5w60f3a+mAsewgZ6HUiKYhovaobkzldOcG3uR60vTPecK0S4OZlCWg49wVPukGfz4hUpI+QDSlmYkQzVbSY= Received: by 10.66.250.17 with SMTP id x17mr2490718ugh.1173949194486; Thu, 15 Mar 2007 01:59:54 -0700 (PDT) Received: by 10.66.238.6 with HTTP; Thu, 15 Mar 2007 01:59:54 -0700 (PDT) Message-ID: Date: Thu, 15 Mar 2007 09:59:54 +0100 From: "Gerardo Giaretta" To: "Hannes Tschofenig" Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support In-Reply-To: <45F8676C.5090404@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45F8676C.5090404@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org One application is the right approach IMO. --Gerardo On 3/14/07, Hannes Tschofenig wrote: > Hi all, > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document > (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we should > separate the authentication and authorization interaction to avoid an > update of this specification when RFC 4072 is updated. This means that > the Diameter MIPv6 app-ID is used for the authorization part and the > Diameter EAP app-ID is used for the authentication part. Diameter > routing may cause authentication and authorization messages to be routed > to different servers. This caused a lengthy debate on security issues. > It seems that there is a lot of complexity associated with this approach. > > I would therefore like to hear whether working group members are OK with > performing authentication and authorization as part of one Diameter > application. This would therefore mean that we are going to use the > Diameter MIPv6 app-ID for authentication and for authorization. > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 05:04:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRltA-0001Ch-BZ; Thu, 15 Mar 2007 05:04:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlt9-0001Cc-85 for dime@ietf.org; Thu, 15 Mar 2007 05:04:47 -0400 Received: from mail.um.es ([155.54.212.109]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HRlt7-0000Bt-Kl for dime@ietf.org; Thu, 15 Mar 2007 05:04:47 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 04A5A23D3B9 for ; Thu, 15 Mar 2007 10:04:32 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06965-01-85 for ; Thu, 15 Mar 2007 10:04:31 +0100 (CET) Received: from [192.168.0.2] (host.176.215.23.62.rev.coltfrance.com [62.23.215.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 63A6023D3EC for ; Thu, 15 Mar 2007 10:04:31 +0100 (CET) Message-ID: <45F90C21.3070507@dif.um.es> Date: Thu, 15 Mar 2007 10:04:33 +0100 From: =?ISO-8859-1?Q?=22Antonio_F=2E_G=F3mez_Skarmeta=22?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: es-es, es MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support References: <45F8676C.5090404@gmx.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Gerardo Giaretta escribi=F3: > One application is the right approach IMO. > Agree with Gerardo IMHO Antonio > --Gerardo > > On 3/14/07, Hannes Tschofenig wrote: > >> Hi all, >> >> with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" docume= nt >> (see >> http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) >> we defined a new Diameter application and we then decided that we shou= ld >> separate the authentication and authorization interaction to avoid an >> update of this specification when RFC 4072 is updated. This means that >> the Diameter MIPv6 app-ID is used for the authorization part and the >> Diameter EAP app-ID is used for the authentication part. Diameter >> routing may cause authentication and authorization messages to be rout= ed >> to different servers. This caused a lengthy debate on security issues. >> It seems that there is a lot of complexity associated with this=20 >> approach. >> >> I would therefore like to hear whether working group members are OK wi= th >> performing authentication and authorization as part of one Diameter >> application. This would therefore mean that we are going to use the >> Diameter MIPv6 app-ID for authentication and for authorization. >> >> Please state your opinion. >> >> 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 > --=20 ------------------------------------------------------------ Antonio F. G=F3mez Skarmeta Dept. Ingenier=EDa de la Informaci=F3n y las Comunicaciones Facultad de Inform=E1tica Universidad de Murcia Apartado 4021 30001 Murcia Telf: +34-968-364607 fax: +34-968-364151 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 05:10:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlyE-0004Fv-5b; Thu, 15 Mar 2007 05:10:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRlyB-00042s-Fa for dime@ietf.org; Thu, 15 Mar 2007 05:09:59 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRly8-0001Ox-QQ for dime@ietf.org; Thu, 15 Mar 2007 05:09:59 -0400 Received: (qmail invoked by alias); 15 Mar 2007 09:03:16 -0000 Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26] by mail.gmx.net (mp038) with SMTP; 15 Mar 2007 10:03:16 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19NH8FpwzRNy44XRDmPsrsePmiMaNw6zUv+DlYlSP TB+iZ7So8QIRZo Message-ID: <45F90BD1.80205@gmx.net> Date: Thu, 15 Mar 2007 10:03:13 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: dime@ietf.org Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support References: <45F8676C.5090404@gmx.net> In-Reply-To: <45F8676C.5090404@gmx.net> 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: 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 I prefer one application. Hannes Tschofenig wrote: > Hi all, > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > document (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we > should separate the authentication and authorization interaction to > avoid an update of this specification when RFC 4072 is updated. This > means that the Diameter MIPv6 app-ID is used for the authorization > part and the Diameter EAP app-ID is used for the authentication part. > Diameter routing may cause authentication and authorization messages > to be routed to different servers. This caused a lengthy debate on > security issues. It seems that there is a lot of complexity associated > with this approach. > > I would therefore like to hear whether working group members are OK > with performing authentication and authorization as part of one > Diameter application. This would therefore mean that we are going to > use the Diameter MIPv6 app-ID for authentication and for authorization. > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 16:41:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwlH-0007MA-88; Thu, 15 Mar 2007 16:41:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwlF-0007Da-Rv for dime@ietf.org; Thu, 15 Mar 2007 16:41:21 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRwlD-0001WA-BM for dime@ietf.org; Thu, 15 Mar 2007 16:41:21 -0400 Received: (qmail invoked by alias); 15 Mar 2007 20:41:18 -0000 X-Provags-ID: V01U2FsdGVkX18Xpnk9pfgXJvG7yfBS5FAavMF+oVeW6plwjuhva3 W5SSIvdCP09g15 Message-ID: <45F9AF6C.1030009@gmx.net> Date: Thu, 15 Mar 2007 21:41:16 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: dime@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Subject: [Dime] [Fwd: [IANA #59681] "AAA" and "AAAS" Scheme Registration] X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, good news! It seems that we made progress with the IANA registration of the AAA and AAAS URI scheme. Ciao Hannes -------- Original Message -------- Subject: [IANA #59681] "AAA" and "AAAS" Scheme Registration Date: Thu, 15 Mar 2007 11:49:27 -0800 From: Mark McFadden via RT Reply-To: iana-matrix@icann.org To: Hannes.Tschofenig@gmx.net References: <45C09849.10201@gmx.net> <45C1DC40.8040604@gmx.net> <45DD91C5.9050701@gmx.net> Hannes: I'm happy to let you know (before Prague) that the expert review has been completed and you should see these schema in the official IANA list shortly. On behalf of the IANA, Mark McFadden On Thu Feb 22 04:52:20 2007, Hannes.Tschofenig@gmx.net wrote: > Hi, > > has any progress on the registration of the "AAA" and "AAAS" scheme > been > made? > Members of the IETF DIME working group waiting for a status report > from > my side. > > Ciao > Hannes > > Mark McFadden via RT wrote: > > Hannes: > > > > I'll pass along your offer to the expert reviewer and let you know. > The > > reviewer said that they would be done in about a week, so if I don't > hear by > > next Wednesday, I'll ping the reviewer for progress. > > > > Mark > > > > On Thu Feb 01 04:26:25 2007, Hannes.Tschofenig@gmx.net wrote: > > > >> Hi Mark > >> > >> thanks a lot for the help on this issue. > >> I am looking forward to hear something from the expert reviewer. It > >> might also be useful to interact with the expert reviewer given > that > >> our > >> problem is further complicated due to the fact that people already > >> implemented the AAA scheme as is. We are also aware that there are > >> some > >> bugs in the way it is currently described ..... > >> > >> Ciao > >> Hannes > >> > >> Mark McFadden via RT wrote: > >> > >>> Hannes: > >>> > >>> The process for getting shemas registered under URI schemes is > >>> > >> through expert > >> > >>> review. I've read through the Diameter document and it seems like > >>> > >> the schemeas > >> > >>> are documented weel enough there to avoid needing a separate > >>> > >> standards track > >> > >>> submission. > >>> > >>> I'm going to follow-up with the expert and ask for approval to go > >>> > >> ahead and > >> > >>> register the two URIs. > >>> > >>> I'll follow-up and let you know what happens. > >>> > >>> On behalf of IANA, > >>> > >>> Mark McFadden > >>> > >>> On Wed Jan 31 05:24:11 2007, Hannes.Tschofenig@gmx.net wrote: > >>> > >>> > >>>> Hi IANA, > >>>> > >>>> as part of the work in the DIME working group we noticed that the > >>>> > >> 'aaa' > >> > >>>> and 'aaas' scheme introduced in RFC 3588 was not registered with > >>>> > >> IANA. > >> > >>>> The problem was that the authors of RFC 3588 did not include any > >>>> instructions to IANA into the IANA consideration section. > >>>> Hence, the two scheme identifiers just appear in the middle of > the > >>>> document, for example on page 44. > >>>> > >>>> Hence, the 'aaa' and 'aaas' scheme does not appear in > >>>> http://www.iana.org/assignments/uri-schemes.html > >>>> > >>>> What should we do to register it? > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>> > >>>> > >>>> > >>> > >>> > > > > > > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 16:50:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwtq-0002kI-77; Thu, 15 Mar 2007 16:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRwto-0002jW-Oz for dime@ietf.org; Thu, 15 Mar 2007 16:50:12 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRwtb-0002iB-MH for dime@ietf.org; Thu, 15 Mar 2007 16:50:11 -0400 Received: (qmail invoked by alias); 15 Mar 2007 20:49:58 -0000 X-Provags-ID: V01U2FsdGVkX19/yWJqTUh/Jao/bdKe0sfMkmvARIQhLdJMJeNgrl cZm0Z+38YaGrtI Message-ID: <45F9B175.2000006@gmx.net> Date: Thu, 15 Mar 2007 21:49:57 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: MORAND Lionel RD-CORE-ISS Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport References: <7DBAFEC6A76F3E42817DF1EBE64CB0260462DF33@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <7DBAFEC6A76F3E42817DF1EBE64CB0260462DF33@FTRDMEL2.rd.francetelecom.fr> 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: 244a2fd369eaf00ce6820a760a3de2e8 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Lionel, MORAND Lionel RD-CORE-ISS wrote: > I'm fine with that proposal. > Thanks for the feedback. > I would add that the authentication procedures defined for the Diameter MIPv6 application must be flexible enough to support various authentication modes/schemes. > Based on the discussions in the MIP6 working group we have to support the EAP-based bootstrapping via IKEv2 and also RFC 4285. Ciao Hannes > BR, > > Lionel > > >> -----Message d'origine----- >> De : Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Envoyé : mercredi 14 mars 2007 22:22 >> À : dime@ietf.org >> Objet : [Dime] Consensus Call regarding Diameter Mobile IPv6 >> HA-to-AAAHsupport >> >> Hi all, >> >> with our work on the "Diameter Mobile IPv6 HA-to-AAAH >> support" document (see >> http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) >> we defined a new Diameter application and we then decided >> that we should separate the authentication and authorization >> interaction to avoid an update of this specification when RFC >> 4072 is updated. This means that the Diameter MIPv6 app-ID is >> used for the authorization part and the Diameter EAP app-ID >> is used for the authentication part. Diameter routing may >> cause authentication and authorization messages to be routed >> to different servers. This caused a lengthy debate on >> security issues. >> It seems that there is a lot of complexity associated with >> this approach. >> >> I would therefore like to hear whether working group members >> are OK with performing authentication and authorization as >> part of one Diameter application. This would therefore mean >> that we are going to use the Diameter MIPv6 app-ID for >> authentication and for authorization. >> >> Please state your opinion. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www1.ietf.org/mailman/listinfo/dime >> >> >> _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 17:16:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxIi-0001jf-AJ; Thu, 15 Mar 2007 17:15:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxIg-0001il-NY for dime@ietf.org; Thu, 15 Mar 2007 17:15:54 -0400 Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRxIf-0000Tm-D8 for dime@ietf.org; Thu, 15 Mar 2007 17:15:54 -0400 Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Mar 2007 14:15:50 -0700 Message-ID: <45F9B786.3080508@azairenet.com> Date: Thu, 15 Mar 2007 14:15:50 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Hannes Tschofenig , dime@ietf.org Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support References: <45F8676C.5090404@gmx.net> In-Reply-To: <45F8676C.5090404@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2007 21:15:50.0880 (UTC) FILETIME=[1BB90E00:01C76747] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I prefer using one Diameter application. Vijay Hannes Tschofenig wrote: > Hi all, > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document > (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we should > separate the authentication and authorization interaction to avoid an > update of this specification when RFC 4072 is updated. This means that > the Diameter MIPv6 app-ID is used for the authorization part and the > Diameter EAP app-ID is used for the authentication part. Diameter > routing may cause authentication and authorization messages to be routed > to different servers. This caused a lengthy debate on security issues. > It seems that there is a lot of complexity associated with this approach. > > I would therefore like to hear whether working group members are OK with > performing authentication and authorization as part of one Diameter > application. This would therefore mean that we are going to use the > Diameter MIPv6 app-ID for authentication and for authorization. > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 17:46:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxmH-00075d-J0; Thu, 15 Mar 2007 17:46:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRxmF-00075R-Ph for dime@ietf.org; Thu, 15 Mar 2007 17:46:27 -0400 Received: from bw.ulticom.com ([208.255.120.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRxmD-0005s8-8I for dime@ietf.org; Thu, 15 Mar 2007 17:46:27 -0400 Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id 105AEBC103 for ; Thu, 15 Mar 2007 16:46:24 -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 l2FLkIh5002354 for ; Thu, 15 Mar 2007 17:46:24 -0400 (EDT) From: "Tolga Asveren" To: Subject: RE: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Date: Thu, 15 Mar 2007 16:40:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 In-Reply-To: <45F90BD1.80205@gmx.net> Importance: Normal 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 I also think one application makes sense. I guess it may be technically possible to separate authentication and authorization parts to different applications but it seems reaching a consensus on how to do it would take a very long time and that it is practically not needed -at least for now-. Thanks, Tolga > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Thursday, March 15, 2007 4:03 AM > To: dime@ietf.org > Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 > HA-to-AAAHsupport > > > > > I prefer one application. > > Hannes Tschofenig wrote: > > Hi all, > > > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > > document (see > > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > > we defined a new Diameter application and we then decided that we > > should separate the authentication and authorization interaction to > > avoid an update of this specification when RFC 4072 is updated. This > > means that the Diameter MIPv6 app-ID is used for the authorization > > part and the Diameter EAP app-ID is used for the authentication part. > > Diameter routing may cause authentication and authorization messages > > to be routed to different servers. This caused a lengthy debate on > > security issues. It seems that there is a lot of complexity associated > > with this approach. > > > > I would therefore like to hear whether working group members are OK > > with performing authentication and authorization as part of one > > Diameter application. This would therefore mean that we are going to > > use the Diameter MIPv6 app-ID for authentication and for authorization. > > > > Please state your opinion. > > > > 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 Thu Mar 15 18:29:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyRU-0005Rb-VF; Thu, 15 Mar 2007 18:29:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRyRU-0005RW-Jf for dime@ietf.org; Thu, 15 Mar 2007 18:29:04 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRyRT-0005vw-9x for dime@ietf.org; Thu, 15 Mar 2007 18:29:04 -0400 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 l2FMT0W04657; Thu, 15 Mar 2007 22:29:00 GMT 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] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support Date: Thu, 15 Mar 2007 17:28:44 -0500 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711338C8E5@zrc2hxm2.corp.nortel.com> In-Reply-To: <45F8676C.5090404@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support thread-index: AcdmfzC7STGP/zuRSzKLkChkAguOEQA0fG3A References: <45F8676C.5090404@gmx.net> From: "Ahmad Muhanna" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I support. Regards, Ahmad =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, March 14, 2007 4:22 PM > To: dime@ietf.org > Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6=20 > HA-to-AAAH support >=20 > Hi all, >=20 > with our work on the "Diameter Mobile IPv6 HA-to-AAAH=20 > support" document (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided=20 > that we should separate the authentication and authorization=20 > interaction to avoid an update of this specification when RFC=20 > 4072 is updated. This means that the Diameter MIPv6 app-ID is=20 > used for the authorization part and the Diameter EAP app-ID=20 > is used for the authentication part. Diameter routing may=20 > cause authentication and authorization messages to be routed=20 > to different servers. This caused a lengthy debate on=20 > security issues.=20 > It seems that there is a lot of complexity associated with=20 > this approach. >=20 > I would therefore like to hear whether working group members=20 > are OK with performing authentication and authorization as=20 > part of one Diameter application. This would therefore mean=20 > that we are going to use the Diameter MIPv6 app-ID for=20 > authentication and for authorization. >=20 > Please state your opinion. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 19:27:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRzM0-0002o5-BU; Thu, 15 Mar 2007 19:27:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRzLy-0002nT-Ni for dime@ietf.org; Thu, 15 Mar 2007 19:27:26 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HRzLx-00086E-CW for dime@ietf.org; Thu, 15 Mar 2007 19:27:26 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2FNR0J5030495; Thu, 15 Mar 2007 18:27:02 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45F9D646.3050202@tari.toshiba.com> Date: Thu, 15 Mar 2007 19:27:02 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support References: <45F8676C.5090404@gmx.net> In-Reply-To: <45F8676C.5090404@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) 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 Hi Hannes, the single app proposal is ok with me. victor > Hi all, > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > document (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we > should separate the authentication and authorization interaction to > avoid an update of this specification when RFC 4072 is updated. This > means that the Diameter MIPv6 app-ID is used for the authorization > part and the Diameter EAP app-ID is used for the authentication part. > Diameter routing may cause authentication and authorization messages > to be routed to different servers. This caused a lengthy debate on > security issues. It seems that there is a lot of complexity associated > with this approach. > > I would therefore like to hear whether working group members are OK > with performing authentication and authorization as part of one > Diameter application. This would therefore mean that we are going to > use the Diameter MIPv6 app-ID for authentication and for authorization. > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 15 20:35:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0PN-0001Wc-Vf; Thu, 15 Mar 2007 20:35:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS0PM-0001WS-6X for dime@ietf.org; Thu, 15 Mar 2007 20:35:00 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS0PL-0005Ic-RT for dime@ietf.org; Thu, 15 Mar 2007 20:35:00 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2G0Y8dT030719; Thu, 15 Mar 2007 19:34:09 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 15 Mar 2007 20:34:07 -0400 To: Hannes Tschofenig Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support Message-ID: <20070316003407.GA29385@steelhead> References: <45F8676C.5090404@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <45F8676C.5090404@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 53 X-Spam-Score: -2.4 (--) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org As I repeatedly mentioned over this mailing list, I strongly believe that separation of authentication and authorization is the best way to proceed for MIPv6 HA-to-AAAH in terms of modularity. I failed to understand what exactly the actual complexity associated with approach is. I also do not understand how people who agree with the combined authentication and authorization approach can also agree with Diameter QoS application which is separately defined from authentication. Finally, I also have an implementation issue with the combined authentication and authorization approach for Open Diameter in which a philosophy of "no code duplicate" among different applications/libraries has been applied in order to avoid a problem with changing one Diameter application library but forgetting to make the same change for a similar Diameter application library as much as possible. There may be some ugly implementation technique to avoid code duplicate, which I don't like to see in Open Diameter. Best Regards, Yoshihiro Ohba On Wed, Mar 14, 2007 at 10:21:48PM +0100, Hannes Tschofenig wrote: > Hi all, > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document > (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we should > separate the authentication and authorization interaction to avoid an > update of this specification when RFC 4072 is updated. This means that > the Diameter MIPv6 app-ID is used for the authorization part and the > Diameter EAP app-ID is used for the authentication part. Diameter > routing may cause authentication and authorization messages to be routed > to different servers. This caused a lengthy debate on security issues. > It seems that there is a lot of complexity associated with this approach. > > I would therefore like to hear whether working group members are OK with > performing authentication and authorization as part of one Diameter > application. This would therefore mean that we are going to use the > Diameter MIPv6 app-ID for authentication and for authorization. > > Please state your opinion. > > Ciao > Hannes > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 16 05:13:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS8VT-00005k-SR; Fri, 16 Mar 2007 05:13:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HS8VS-0008TI-2G for dime@ietf.org; Fri, 16 Mar 2007 05:13:50 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HS8VP-0002qI-8H for dime@ietf.org; Fri, 16 Mar 2007 05:13:50 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Mar 2007 10:13:19 +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] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Date: Fri, 16 Mar 2007 10:13:17 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB0260462E4F3@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAHsupport Thread-Index: AcdnY4pqFdi0Ef+/TuCnav2pMY5l2wAQKaBQ From: "MORAND Lionel RD-CORE-ISS" To: "Yoshihiro Ohba" , "Hannes Tschofenig" X-OriginalArrivalTime: 16 Mar 2007 09:13:19.0029 (UTC) FILETIME=[566B4E50:01C767AB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I think that the discussion is at least focused on the Diameter MIPv6 = application in this thread ;) My point was and still is that if authentication procedures are required = by a given application, these procedures should be defined within the = same application because authentication and authorization are tighly = coupled (that is the case for me in the diameter MIPv6 application).=20 That doesn't preclude the definition of diameter applications not = relying on any authentication procedures. cf. some Diameter applications = defined in 3GPP or TISPAN (e.g. Sh application) mainly used for = user/service profile handling, unrelated to any authentication = procedure. It is therefore something that must be discussed case-by-case. And = another thread can be opened for Diameter QoS application if needed. Lionel > -----Message d'origine----- > De : Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]=20 > Envoy=E9 : vendredi 16 mars 2007 01:34 > =C0 : Hannes Tschofenig > Cc : dime@ietf.org > Objet : Re: [Dime] Consensus Call regarding Diameter Mobile=20 > IPv6 HA-to-AAAHsupport >=20 > As I repeatedly mentioned over this mailing list, I strongly=20 > believe that separation of authentication and authorization=20 > is the best way to proceed for MIPv6 HA-to-AAAH in terms of=20 > modularity. I failed to understand what exactly the actual=20 > complexity associated with approach is. I also do not=20 > understand how people who agree with the combined=20 > authentication and authorization approach can also agree with=20 > Diameter QoS application which is separately defined from=20 > authentication. >=20 > Finally, I also have an implementation issue with the=20 > combined authentication and authorization approach for Open=20 > Diameter in which a philosophy of "no code duplicate" among=20 > different applications/libraries has been applied in order to=20 > avoid a problem with changing one Diameter application=20 > library but forgetting to make the same change for a similar=20 > Diameter application library as much as possible. There may=20 > be some ugly implementation technique to avoid code=20 > duplicate, which I don't like to see in Open Diameter. >=20 > Best Regards, > Yoshihiro Ohba >=20 >=20 >=20 > On Wed, Mar 14, 2007 at 10:21:48PM +0100, Hannes Tschofenig wrote: > > Hi all, > >=20 > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support"=20 > > document (see > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > > we defined a new Diameter application and we then decided that we=20 > > should separate the authentication and authorization interaction to=20 > > avoid an update of this specification when RFC 4072 is=20 > updated. This=20 > > means that the Diameter MIPv6 app-ID is used for the authorization=20 > > part and the Diameter EAP app-ID is used for the=20 > authentication part.=20 > > Diameter routing may cause authentication and authorization=20 > messages=20 > > to be routed to different servers. This caused a lengthy=20 > debate on security issues. > > It seems that there is a lot of complexity associated with=20 > this approach. > >=20 > > I would therefore like to hear whether working group members are OK=20 > > with performing authentication and authorization as part of one=20 > > Diameter application. This would therefore mean that we are=20 > going to=20 > > use the Diameter MIPv6 app-ID for authentication and for=20 > authorization. > >=20 > > Please state your opinion. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 16 09:48:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCnc-0005HT-C8; Fri, 16 Mar 2007 09:48:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSCnb-0005Gc-Hq for dime@ietf.org; Fri, 16 Mar 2007 09:48:51 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSCna-0000uh-3H for dime@ietf.org; Fri, 16 Mar 2007 09:48:51 -0400 Received: (qmail invoked by alias); 16 Mar 2007 13:48:47 -0000 X-Provags-ID: V01U2FsdGVkX1+orTcEario7UqF9uIKsAjQgYE/oXHMLlwE8lucjj 1cWy9+36AFr5jo Message-ID: <45FAA03B.4000004@gmx.net> Date: Fri, 16 Mar 2007 14:48:43 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support References: <45F8676C.5090404@gmx.net> <20070316003407.GA29385@steelhead> In-Reply-To: <20070316003407.GA29385@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Yoshi, Yoshihiro Ohba wrote: > As I repeatedly mentioned over this mailing list, I strongly believe > that separation of authentication and authorization is the best way to > proceed for MIPv6 HA-to-AAAH in terms of modularity. I failed to > understand what exactly the actual complexity associated with approach > is. There is the impression that a) the separation is not necessary from a deployment point of view and can be accomplished via other means, and b) security issues have been raised. I guess you see no problems with (b) and you don't believe that (a) can be done. Right? > I also do not understand how people who agree with the combined > authentication and authorization approach can also agree with Diameter > QoS application which is separately defined from authentication. > For the Diameter QoS work we still need to investigate a number of discussions. I have asked a few experts to review the work in order to propose changes, if needed. I am sure that we will see a few changes in the next few weeks. > Finally, I also have an implementation issue with the combined > authentication and authorization approach for Open Diameter in which a > philosophy of "no code duplicate" among different > applications/libraries has been applied in order to avoid a problem > with changing one Diameter application library but forgetting to make > the same change for a similar Diameter application library as much as > possible. There may be some ugly implementation technique to avoid > code duplicate, which I don't like to see in Open Diameter. > Isn't that specific to the way how OpenDiameter is implemented rather than a generic problem? Ciao Hannes > Best Regards, > Yoshihiro Ohba > > > > On Wed, Mar 14, 2007 at 10:21:48PM +0100, Hannes Tschofenig wrote: > >> Hi all, >> >> with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document >> (see >> http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) >> we defined a new Diameter application and we then decided that we should >> separate the authentication and authorization interaction to avoid an >> update of this specification when RFC 4072 is updated. This means that >> the Diameter MIPv6 app-ID is used for the authorization part and the >> Diameter EAP app-ID is used for the authentication part. Diameter >> routing may cause authentication and authorization messages to be routed >> to different servers. This caused a lengthy debate on security issues. >> It seems that there is a lot of complexity associated with this approach. >> >> I would therefore like to hear whether working group members are OK with >> performing authentication and authorization as part of one Diameter >> application. This would therefore mean that we are going to use the >> Diameter MIPv6 app-ID for authentication and for authorization. >> >> Please state your opinion. >> >> 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 Sun Mar 18 10:55:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwnI-000458-1J; Sun, 18 Mar 2007 10:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HSwnH-000453-DQ for dime@ietf.org; Sun, 18 Mar 2007 10:55:35 -0400 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HSwnF-0004RA-AW for dime@ietf.org; Sun, 18 Mar 2007 10:55:35 -0400 Received: (qmail invoked by alias); 18 Mar 2007 14:55:32 -0000 X-Provags-ID: V01U2FsdGVkX19ToVNHEzNTpVdcm/xXNof4O2W4bF6UqsRITinlRa 05GOZslRAe6m+k Message-ID: <45FD52E4.2080600@gmx.net> Date: Sun, 18 Mar 2007 15:55:32 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0b2 (Windows/20070116) 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: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Dime] Presentations X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 send your presentation to us. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 09:27:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHtm-0001ak-C5; Mon, 19 Mar 2007 09:27:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTHtk-0001aU-It for dime@ietf.org; Mon, 19 Mar 2007 09:27:40 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTHtP-0006XE-5n for dime@ietf.org; Mon, 19 Mar 2007 09:27:40 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 7A93E7DB9; Mon, 19 Mar 2007 06:27:15 -0700 (PDT) Received: from [10.82.216.39] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 98F297DAA; Mon, 19 Mar 2007 06:27:12 -0700 (PDT) Message-ID: <45FE8FA9.8050400@frascone.com> Date: Mon, 19 Mar 2007 09:27:05 -0400 From: David Frascone User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Dime] Editorial Nits in draft-ietf-dime-rfc3588bis-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 There are some formatting issues in draft-ietf-dime-rfc3588bis-02.txt, possibly from tab or space conversions. They are noticeable in http://www.frascone.com/draft-ietf-dime-rfc3588bis-02-from-rfc3588.diff.html Indentation Issues: Page 26, line 18 Page 51, line 27 Page 55, line 17-19 Page 71, line 30, etc. off by one space this time. Page 72, line 44 Section 11.3 And, I found a few other grammatical nits: Page 84, "Relay agents does not require full validation of incoming messages. At the minimum, validation of the message header and relevant routing AVPs has to be done when relaying messages." Should read, "Relay agents do not require . . . " Page 96, should read, "To provide backward compatibility with existing implementations that follow [RFC..." Section 7.1.4, Transient Failures: "Note that these errors MUST be used in answer messages whose 'E' bit not is set." -- did you mean, "bit is not set." ? Section 7.1.5: "To provide backward compatibility with existing implementations that follows [RFC3588]" should be, "implementations that follow" -- and, last sentence, "the error values enumerated here maybe non-sequential." maybe -> may be. The definition of DIAMETER_NO_COMMON_APPLICATION 5010, does not pass my parser, I suggest the following replacement text: "This error is returned when a non-relay node, supporting a specific set of applications has an empty intersection with the set of applications advertised by its peer." -- David Frascone I'd love to, but I have to stay home and see if I snore _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 13:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLdu-00048Y-Q7; Mon, 19 Mar 2007 13:27:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLdt-00048R-7Z for dime@ietf.org; Mon, 19 Mar 2007 13:27:33 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTLdK-0007r2-6O for dime@ietf.org; Mon, 19 Mar 2007 13:27:33 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2JHQRGx046608; Mon, 19 Mar 2007 12:26:28 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <45FEC7AE.5010904@tari.toshiba.com> Date: Mon, 19 Mar 2007 13:26:06 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: David Frascone Subject: Re: [Dime] Editorial Nits in draft-ietf-dime-rfc3588bis-02.txt References: <45FE8FA9.8050400@frascone.com> In-Reply-To: <45FE8FA9.8050400@frascone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 David, Thanks for the review. Comments inline: > There are some formatting issues in draft-ietf-dime-rfc3588bis-02.txt, > possibly from tab or space conversions. They are noticeable in > http://www.frascone.com/draft-ietf-dime-rfc3588bis-02-from-rfc3588.diff.html > > Indentation Issues: > Page 26, line 18 > Page 51, line 27 > Page 55, line 17-19 > Page 71, line 30, etc. off by one space this time. > Page 72, line 44 > Section 11.3 > Ok > > And, I found a few other grammatical nits: > > Page 84, "Relay agents does not require full validation of incoming > messages. At the minimum, validation of the message header and relevant > routing AVPs has to be done when relaying messages." Should read, > "Relay agents do not require . . . " > Ok > Page 96, should read, "To provide backward compatibility with > existing implementations that follow [RFC..." > Ok > Section 7.1.4, Transient Failures: "Note that these errors MUST be > used in answer messages whose 'E' bit not is set." -- did you mean, "bit > is not set." ? > Ok > Section 7.1.5: "To provide backward compatibility with existing > implementations that follows [RFC3588]" should be, "implementations that > follow" -- and, last sentence, "the error values enumerated here maybe > non-sequential." maybe -> may be. > Ok > The definition of DIAMETER_NO_COMMON_APPLICATION 5010, does not pass my > parser, I suggest the following replacement text: > > "This error is returned when a non-relay node, supporting a specific > set of applications has an empty intersection with the set of > applications advertised by its peer." > If the text is too cryptic we can re-word to: "This error is returned by a Diameter node that is not acting as a relay when it receives a CER which advertises a set of applications that it does not support" regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 13:29:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLfN-0004I6-S8; Mon, 19 Mar 2007 13:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLfM-0004H8-EH for dime@ietf.org; Mon, 19 Mar 2007 13:29:04 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLfI-0006bi-5F for dime@ietf.org; Mon, 19 Mar 2007 13:29:04 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 68B697DDD; Mon, 19 Mar 2007 10:28:54 -0700 (PDT) Received: from [10.82.240.235] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id F10477DD5; Mon, 19 Mar 2007 10:28:51 -0700 (PDT) Message-ID: <45FEC851.7080003@frascone.com> Date: Mon, 19 Mar 2007 13:28:49 -0400 From: David Frascone User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Victor Fajardo Subject: Re: [Dime] Editorial Nits in draft-ietf-dime-rfc3588bis-02.txt References: <45FE8FA9.8050400@frascone.com> <45FEC7AE.5010904@tari.toshiba.com> In-Reply-To: <45FEC7AE.5010904@tari.toshiba.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I like yours even better. Simpler == better :) -Dave Victor Fajardo wrote: > > If the text is too cryptic we can re-word to: > > "This error is returned by a Diameter node that is not acting as a > relay when it receives a > CER which advertises a set of applications that it does not support" > > regards, > victor > -- David Frascone Back Up My Hard Drive? I Can't Find The Reverse Switch! _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 13:39:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLpD-0003Mj-Uw; Mon, 19 Mar 2007 13:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTLpD-0003Me-9d for dime@ietf.org; Mon, 19 Mar 2007 13:39:15 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTLpB-0007dj-0H for dime@ietf.org; Mon, 19 Mar 2007 13:39:15 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 955407DE1 for ; Mon, 19 Mar 2007 10:39:09 -0700 (PDT) Received: from [10.82.240.235] (rtp-isp-nat1.cisco.com [64.102.254.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id D14117DDA for ; Mon, 19 Mar 2007 10:39:07 -0700 (PDT) Message-ID: <45FECAB5.7090803@frascone.com> Date: Mon, 19 Mar 2007 13:39:01 -0400 From: David Frascone User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: dime@ietf.org X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=7.0 tests= X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Comments: 1. Introduction: However, static provisioning of this information becomes easily provisioning and network administratiOn burden for an operator. maybe change to: However, static provisioning of this information can easily become a provisioning and network administration burden for operators. Section 4.1 Diameter nodes conforming to this specification SHOULD include the value of 1 (NASREQ application) or 5 (EAP application) in the Auth- Application-Id or the Acct-Application-Id AVP in the Capabilities- Exchange-Request and Capabilities-Exchange-Answer commands Shouldn't that SHOULD be a MUST? In what scenarios would the Auth-Application-Id not be 1 or 5? Section 4.7.3, last sentance: There may be reasons for the Diameter server to dynamically assigning home link prefix to the MN, for example one that is in close proximity to the point of attachment. maybe change to: There may be reasons for the Diameter server to dynamically assign a home link prefix to the MN, for example if it is in close proximity to the point of attachment. Section 5.2 Are the SHOULD's in there really MUST's? In what cases would the Diameter server NOT send those AVPs, since we've already said that the server supports the assignment. General question What is sent by the Diameter Client to the Diameter Server in the new AVP's? Most of the information is not known, and will be provided by the Diameter Server. Are they just empty placeholders? If so, it seems like a lot of waste to essentially do a capabilities announcement. -- David Frascone If it's not your banana, don't eat it. _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 14:17:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMPb-0000cq-CV; Mon, 19 Mar 2007 14:16:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTMNz-00007L-3k for dime@ietf.org; Mon, 19 Mar 2007 14:15:11 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTMGv-0003UU-FL for dime@ietf.org; Mon, 19 Mar 2007 14:07:54 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Mar 2007 19:07:49 +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: RE: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt Date: Mon, 19 Mar 2007 19:07:49 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A40160@SEHAN021MB.tcad.telia.se> In-Reply-To: <45FECAB5.7090803@frascone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt Thread-Index: AcdqTbDPJLi27jNXSEWXTpgWcYY+RwAAPCEw From: To: , X-OriginalArrivalTime: 19 Mar 2007 18:07:49.0761 (UTC) FILETIME=[814DE710:01C76A51] X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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, Thanks for the review! See my comments inline.=20 > -----Original Message----- > From: David Frascone [mailto:dave@frascone.com]=20 > Sent: 19. maaliskuuta 2007 19:39 > To: dime@ietf.org > Subject: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt >=20 >=20 > Comments: >=20 > 1. Introduction: >=20 > However, static provisioning of this information becomes > easily provisioning and network administratiOn burden for an > operator. >=20 > maybe change to: >=20 > However, static provisioning of this information can easily > become a provisioning and network administration burden for > operators. OK. > Section 4.1 >=20 > Diameter nodes conforming to this specification SHOULD include the > value of 1 (NASREQ application) or 5 (EAP application) in the Auth- > Application-Id or the Acct-Application-Id AVP in the Capabilities- > Exchange-Request and Capabilities-Exchange-Answer commands >=20 > Shouldn't that SHOULD be a MUST? In what scenarios would the > Auth-Application-Id not be 1 or 5? Hmmm.. MUST works for me.=20 > Section 4.7.3, last sentance: >=20 > There may be reasons for > the Diameter server to dynamically assigning home link=20 > prefix to the > MN, for example one that is in close proximity to the point of > attachment. >=20 > maybe change to: >=20 > There may be reasons for the Diameter server to dynamically > assign a home link prefix to the MN, for example if it is > in close proximity to the point of attachment. OK. > Section 5.2 >=20 > Are the SHOULD's in there really MUST's? In what cases would the > Diameter server NOT send those AVPs, since we've already said > that the server supports the assignment. If the subscription does not have MIP6 provisioned but the Diameter server still provides access authentication for the said subscription. In this case the server would not send any MIP6 bootstrapping AVPs back to the NAS. > General question > What is sent by the Diameter Client to the Diameter Server in the > new AVP's? Most of the information is not known, and will be > provided by the Diameter Server. Are they just empty=20 > placeholders? > If so, it seems like a lot of waste to essentially do a=20 > capabilities > announcement. Hmm.. the Diameter client does not need to send all new AVPs. One is enough for the capability announcement. If the Diameter client does not have anything sensible to put into an AVP it should not send one. For the MIP6-Home-Agent-Address we actually defined the value to use when the information is unknown. Maybe we should limit the=20 capability announcment to only one AVP.. Actually, a specific AVP for the capability was proposed again. We are thinking to re-introduce a capability AVP back to accommodate one particular local HA assignment use case. Cheers, Jouni >=20 >=20 >=20 > --=20 >=20 > David Frascone >=20 > If it's not your banana, don't eat it. >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 19 16:07:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTO95-0008PD-O0; Mon, 19 Mar 2007 16:07:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTO94-0008P6-O1 for dime@ietf.org; Mon, 19 Mar 2007 16:07:54 -0400 Received: from bender-mail.tigertech.net ([64.62.209.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTO8f-0000Pj-4G for dime@ietf.org; Mon, 19 Mar 2007 16:07:54 -0400 Received: from localhost (localhost [127.0.0.1]) by bender.tigertech.net (Postfix) with ESMTP id 2F4B67DF3; Mon, 19 Mar 2007 13:07:23 -0700 (PDT) Received: from [213.175.39.53] (unknown [213.175.39.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bender.tigertech.net (Postfix) with ESMTP id 5C3327DD7; Mon, 19 Mar 2007 13:07:20 -0700 (PDT) Message-ID: <45FEED71.6070708@frascone.com> Date: Mon, 19 Mar 2007 16:07:13 -0400 From: David Frascone User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt References: <59D7431DE2527D4CB0F1EFEDA5683ED301A40160@SEHAN021MB.tcad.telia.se> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301A40160@SEHAN021MB.tcad.telia.se> X-Enigmail-Version: 0.94.0.0 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net X-Spam-Status: No, hits=0.1 tagged_above=-999.0 required=7.0 tests=HTML_40_50, HTML_MESSAGE X-Spam-Level: X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1112682183==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============1112682183== Content-Type: multipart/alternative; boundary="------------070502080702010506080006" This is a multi-part message in MIME format. --------------070502080702010506080006 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One comment below: jouni.korhonen@teliasonera.com wrote: > >> Section 5.2 >> >> Are the SHOULD's in there really MUST's? In what cases would the >> Diameter server NOT send those AVPs, since we've already said >> that the server supports the assignment. >> > > If the subscription does not have MIP6 provisioned but the Diameter > server still provides access authentication for the said subscription. > In this case the server would not send any MIP6 bootstrapping AVPs > back to the NAS. > > Would it be possible to add some text to explain that, then? Otherwise the SHOULD is kind of ambiguous. -Dave -- David Frascone Move your vowels every day or you'll get consonated. --------------070502080702010506080006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One comment below:

jouni.korhonen@teliasonera.com wrote: 

Section 5.2

    Are the SHOULD's in there really MUST's?  In what cases would the
    Diameter server NOT send those AVPs, since we've already said
    that the server supports the assignment.
    

If the subscription does not have MIP6 provisioned but the Diameter
server still provides access authentication for the said subscription.
In this case the server would not send any MIP6 bootstrapping AVPs
back to the NAS.
Would it be possible to add some text to explain that, then?  Otherwise the SHOULD is kind of ambiguous.

-Dave


-- 

David Frascone

              Move your vowels every day or you'll get consonated.
--------------070502080702010506080006-- --===============1112682183== 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 --===============1112682183==-- From dime-bounces@ietf.org Mon Mar 19 19:12:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTR1w-00022x-JN; Mon, 19 Mar 2007 19:12:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTR1v-00022s-Va for dime@ietf.org; Mon, 19 Mar 2007 19:12:44 -0400 Received: from mgw.toshibaamericaresearch.com ([165.254.55.12] helo=toshi17.tari.toshiba.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HTR1R-0002He-Sq for dime@ietf.org; Mon, 19 Mar 2007 19:12:43 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2JN5r6i048087; Mon, 19 Mar 2007 18:05:57 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Mon, 19 Mar 2007 19:05:52 -0400 To: Hannes Tschofenig Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6 HA-to-AAAH support Message-ID: <20070319230544.GD11771@steelhead> References: <45F8676C.5090404@gmx.net> <20070316003407.GA29385@steelhead> <45FAA03B.4000004@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <45FAA03B.4000004@gmx.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 92 X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Fri, Mar 16, 2007 at 02:48:43PM +0100, Hannes Tschofenig wrote: > Hi Yoshi, > > Yoshihiro Ohba wrote: > > As I repeatedly mentioned over this mailing list, I strongly believe > > that separation of authentication and authorization is the best way to > > proceed for MIPv6 HA-to-AAAH in terms of modularity. I failed to > > understand what exactly the actual complexity associated with approach > > is. > > There is the impression that > a) the separation is not necessary from a deployment point of view and > can be accomplished via other means, and > b) security issues have been raised. > > I guess you see no problems with (b) and you don't believe that (a) can > be done. > Right? I see no problem with (b). We discussed a sceanario of compromised HA, but compromised HA can do anything, so the scenario does not seem to affect this decision making. Regarding (a), it *can* be done, but to me it's just a superficial idea that is inherited from RADIUS to unnecessarily combine authentication and authorization. Lionel mentioned that it's case-by-case decision, but I would expect a very clear and convincing guidance as to which set of conditions combination is better than seperation, which may also affect QoS application discussion. > > > Finally, I also have an implementation issue with the combined > > authentication and authorization approach for Open Diameter in which a > > philosophy of "no code duplicate" among different > > applications/libraries has been applied in order to avoid a problem > > with changing one Diameter application library but forgetting to make > > the same change for a similar Diameter application library as much as > > possible. There may be some ugly implementation technique to avoid > > code duplicate, which I don't like to see in Open Diameter. > > > Isn't that specific to the way how OpenDiameter is implemented rather > than a generic problem? Right. Yoshihiro Ohba > > > Ciao > Hannes > > Best Regards, > > Yoshihiro Ohba > > > > > > > > On Wed, Mar 14, 2007 at 10:21:48PM +0100, Hannes Tschofenig wrote: > > > >> Hi all, > >> > >> with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document > >> (see > >> http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > >> we defined a new Diameter application and we then decided that we should > >> separate the authentication and authorization interaction to avoid an > >> update of this specification when RFC 4072 is updated. This means that > >> the Diameter MIPv6 app-ID is used for the authorization part and the > >> Diameter EAP app-ID is used for the authentication part. Diameter > >> routing may cause authentication and authorization messages to be routed > >> to different servers. This caused a lengthy debate on security issues. > >> It seems that there is a lot of complexity associated with this approach. > >> > >> I would therefore like to hear whether working group members are OK with > >> performing authentication and authorization as part of one Diameter > >> application. This would therefore mean that we are going to use the > >> Diameter MIPv6 app-ID for authentication and for authorization. > >> > >> Please state your opinion. > >> > >> 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 Tue Mar 20 04:26:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZfq-0008EU-RQ; Tue, 20 Mar 2007 04:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTZfp-0008Co-H1 for dime@ietf.org; Tue, 20 Mar 2007 04:26:29 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTZfo-00048a-4F for dime@ietf.org; Tue, 20 Mar 2007 04:26:29 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 09:26:20 +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: RE: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt Date: Tue, 20 Mar 2007 09:26:19 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A40161@SEHAN021MB.tcad.telia.se> In-Reply-To: <45FEED71.6070708@frascone.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Comments on draft-ietf-dime-mip6-integrated-03.txt Thread-Index: AcdqYje9jb8glMklS9a5VNteNnQ2KAAZlX7Q From: To: X-OriginalArrivalTime: 20 Mar 2007 08:26:20.0995 (UTC) FILETIME=[70647130:01C76AC9] X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Dave,=20 > One comment below: >=20 > jouni.korhonen@teliasonera.com wrote:=20 >=20 >=20 > Section 5.2 > =09 > Are the SHOULD's in there really MUST's? =20 > In what cases would the > Diameter server NOT send those AVPs, since=20 > we've already said > that the server supports the assignment. > =20 >=20 > =09 > If the subscription does not have MIP6 provisioned but=20 > the Diameter > server still provides access authentication for the=20 > said subscription. > In this case the server would not send any MIP6=20 > bootstrapping AVPs > back to the NAS. > =09 > =20 >=20 > Would it be possible to add some text to explain that, then? =20 > Otherwise the SHOULD is kind of ambiguous. Sure. I'll propose some clarifying text later on. Cheers, Jouni >=20 > -Dave >=20 >=20 >=20 > --=20 >=20 > David Frascone >=20 > Move your vowels every day or you'll get consonated. >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 20 14:49:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjOi-0003tl-8k; Tue, 20 Mar 2007 14:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTjOg-0003tb-Tp for dime@ietf.org; Tue, 20 Mar 2007 14:49:26 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTjOf-0006Ki-Dp for dime@ietf.org; Tue, 20 Mar 2007 14:49:26 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CA3999006B for ; Tue, 20 Mar 2007 13:49:21 -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 07614-18 for ; Tue, 20 Mar 2007 13:49:16 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 20 Mar 2007 13:49:16 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Mar 2007 14:49:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Consensus Call regarding Diameter Mobile IPv6HA-to-AAAHsupport Date: Tue, 20 Mar 2007 14:49:16 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D49@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter Mobile IPv6HA-to-AAAHsupport Thread-Index: AcdmrwR7v0grC38gQFmcZgsPVPFqxwEb6imw From: "Chowdhury, Kuntal" To: "Avi Lior" , "Hannes Tschofenig" , X-OriginalArrivalTime: 20 Mar 2007 18:49:16.0772 (UTC) FILETIME=[76176A40:01C76B20] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, I would agree with a single Diameter application for both authentication and authorization for MIP6 service with IKEv2/IPsec. In some scenarios, the IPsec gateway (e.g. 3GPP:PDG, 3GPP2:PDIF) may be collocated with the Home Agent. To support such scenarios, there should be a clear way to identify the type of service the MN is trying to access i.e. it is trying to only establish an IPsec session with the IPsec gateway or it wants to access MIPv6 service as well. The IDr field in the IKEv2 exchange can be used for this type of service selection.=20 So, I would suggest that MIPv6 Diameter application is used when such (IPsec or IPsec+MIP6) indication is available at the Home Agent. Best regards, Kuntal > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com] > Sent: Wednesday, March 14, 2007 10:06 PM > To: Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Consensus Call regarding Diameter Mobile IPv6HA-to- > AAAHsupport >=20 > Yes. >=20 > Authentication -- the EAP part and Authorization should happen in one > Diameter Application. >=20 >=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Wednesday, March 14, 2007 5:22 PM > To: dime@ietf.org > Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 > HA-to-AAAHsupport >=20 > Hi all, >=20 > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" document > (see > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > we defined a new Diameter application and we then decided that we should > separate the authentication and authorization interaction to avoid an > update of this specification when RFC 4072 is updated. This means that > the Diameter MIPv6 app-ID is used for the authorization part and the > Diameter EAP app-ID is used for the authentication part. Diameter > routing may cause authentication and authorization messages to be routed > to different servers. This caused a lengthy debate on security issues. > It seems that there is a lot of complexity associated with this > approach. >=20 > I would therefore like to hear whether working group members are OK with > performing authentication and authorization as part of one Diameter > application. This would therefore mean that we are going to use the > Diameter MIPv6 app-ID for authentication and for authorization. >=20 > Please state your opinion. >=20 > Ciao > Hannes >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Wed Mar 21 05:41:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxJX-0007h8-C2; Wed, 21 Mar 2007 05:41:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HTxJW-0007gr-84 for dime@ietf.org; Wed, 21 Mar 2007 05:41:02 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HTxJD-0006bN-SQ for dime@ietf.org; Wed, 21 Mar 2007 05:41:02 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Mar 2007 10:40:41 +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: RE: [Dime] Consensus Call regarding Diameter MobileIPv6HA-to-AAAHsupport Date: Wed, 21 Mar 2007 10:40:41 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301A4016F@SEHAN021MB.tcad.telia.se> In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D49@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter MobileIPv6HA-to-AAAHsupport Thread-Index: AcdmrwR7v0grC38gQFmcZgsPVPFqxwEb6imwAB9dzVA= From: To: , , , X-OriginalArrivalTime: 21 Mar 2007 09:40:41.0558 (UTC) FILETIME=[FD821760:01C76B9C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Kuntal, I would hesitate to 'define' any use of Idr in Dime drafts. Some text discussing that there are multiple ways of signaling the type of desired functionality of the IKEv2 gw, whether it is IPSec or IPSec+MIP6. Cheers, Jouni > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: 20. maaliskuuta 2007 20:49 > To: Avi Lior; Hannes Tschofenig; dime@ietf.org > Subject: RE: [Dime] Consensus Call regarding Diameter=20 > MobileIPv6HA-to-AAAHsupport >=20 > Hi all, >=20 > I would agree with a single Diameter application for both=20 > authentication and authorization for MIP6 service with IKEv2/IPsec. >=20 > In some scenarios, the IPsec gateway (e.g. 3GPP:PDG,=20 > 3GPP2:PDIF) may be collocated with the Home Agent. To support=20 > such scenarios, there should be a clear way to identify the=20 > type of service the MN is trying to access i.e. it is trying=20 > to only establish an IPsec session with the IPsec gateway or=20 > it wants to access MIPv6 service as well. The IDr field in=20 > the IKEv2 exchange can be used for this type of service selection.=20 >=20 > So, I would suggest that MIPv6 Diameter application is used=20 > when such (IPsec or IPsec+MIP6) indication is available at=20 > the Home Agent. >=20 > Best regards, > Kuntal >=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, March 14, 2007 10:06 PM > > To: Hannes Tschofenig; dime@ietf.org > > Subject: RE: [Dime] Consensus Call regarding Diameter Mobile > IPv6HA-to- > > AAAHsupport > >=20 > > Yes. > >=20 > > Authentication -- the EAP part and Authorization should=20 > happen in one=20 > > Diameter Application. > >=20 > >=20 > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, March 14, 2007 5:22 PM > > To: dime@ietf.org > > Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6=20 > > HA-to-AAAHsupport > >=20 > > Hi all, > >=20 > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > document > > (see > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > > we defined a new Diameter application and we then decided that we > should > > separate the authentication and authorization interaction=20 > to avoid an=20 > > update of this specification when RFC 4072 is updated. This=20 > means that=20 > > the Diameter MIPv6 app-ID is used for the authorization=20 > part and the=20 > > Diameter EAP app-ID is used for the authentication part. Diameter=20 > > routing may cause authentication and authorization messages to be > routed > > to different servers. This caused a lengthy debate on=20 > security issues. > > It seems that there is a lot of complexity associated with this=20 > > approach. > >=20 > > I would therefore like to hear whether working group members are OK > with > > performing authentication and authorization as part of one Diameter=20 > > application. This would therefore mean that we are going to use the=20 > > Diameter MIPv6 app-ID for authentication and for authorization. > >=20 > > Please state your opinion. > >=20 > > Ciao > > Hannes > >=20 > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > >=20 > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 00:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUF5Q-0005xY-EV; Thu, 22 Mar 2007 00:39:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUF5P-0005xT-1h for dime@ietf.org; Thu, 22 Mar 2007 00:39:39 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUF5N-0005XP-Hw for dime@ietf.org; Thu, 22 Mar 2007 00:39:39 -0400 MIME-Version: 1.0 Subject: RE: [Dime] Updated QoS Drafts From: Avi Lior In-Reply-To: <45EFDFBA.7000203@gmx.net> References: <45EE9907.8030900@gmx.net><09C9068466B79E4C938DC7737562404D02AC6D@ILEXC2U01.ndc.lucent.com>, <45EFDFBA.7000203@gmx.net> To: Hannes Tschofenig , "Sun, Dong (Dong)" Message-ID: Date: Thu, 22 Mar 2007 00:40:20 -0400 X-Spam-Score: 1.2 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0104366502==" Errors-To: dime-bounces@ietf.org --===============0104366502== Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Dime] Updated QoS Drafts
=  
 
The Diameter QoS Application was= written to server a particular need.
 
I think we should incorporate a = push and a pull model into that document.
 
Its not like some SDO is waiting= for us to finish this work.  We do probably need to work on the QoS a= ttributes and we should be using the approach of working on them outside th= is document.  We need to finish the QoS attribute work fast.
 
Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183
=

From: Hannes Tschofenig
Sent:= Thu 3/8/2007 5:04 AM
To: Sun, Dong (Dong)
Cc: dime@iet= f.org
Subject: Re: [Dime] Updated QoS Drafts

Hi Dong,

thanks for your clarifications. Please fi= nd some comments below:

Sun, Dong (Dong) wrote:
> 
>= ; Hi,
> Some clarifications and comments:
> ~~~~~~~~~~~~~
&g= t; -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@g= mx.net]
> Sent: Wednesday, March 07, 2007 5:51 AM
> To: dim= e@ietf.org
> Subject: [Dime] Updated QoS Drafts
>
> Hi al= l,
> ...
> ...
> "
> http= ://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-requ> irements-01
>
>   This document takes a differe= nt spin and extends the
> <draft-ietf-dime-diameter-qos-00>
= >   document by supporting a "generic push" approach. By "gene= ric push" I
> refer to the
>   ability of an arbitrar= y entity, such as an SIP proxy, to signal to
> another box.
>&n= bsp;  Note that this is not the same as the server-initiated communica= tion.
> "
> ~~~~~~~~~~~~~~~~~
>
> [Dong] The "Push = model" defined in above I-D doesn't aim to define the
> ability of an= arbitrary entity, such as a SIP proxy, to signal to
> another box. T= his document actually addresses the same interface as in
> the curren= t QoS application (draft-ietf-dime-diameter-qos-00). Since the
> curr= ent QoS application only supports the Pull model that is not
> suitab= le for some circumstances (e.g. when the network elements cannot
> tr= igger the QoS authorization request and/or the endpoint does not
> su= pport any QoS signaling/capability, which is quite common in wireline
&g= t; networks), the I-D intends to complement current QoS application
>= document and make a generic framework in order to support various
> = networks, endpoints and applications.
>  
I agree that d= raft-ietf-dime-diameter-qos-00 is not particularly strong
on the descrip= tion of  server-initiated  communication.
This is, however, a = basic feature of the Diameter Base protocol.

Typically, server-initi= ated messages are still sent after the initial
session setup took place = based on an interaction with the Diameter client.
For example, you have = a network access authentication procedure taking
place. Then, during the= lifetime of the session some authorization
relevant aspects change at t= he Diameter server and it initiates a
re-authorization exchange.

= > Currently, this document mainly focuses on discussing the requirements=
> and framework of a generic resource control system, and also propo= ses
> some potential solutions to solve the issue. IMO, it will be be= tter to
> integrate this document with QoS application document toget= her to
> formulate a single document on this subject since the scope = and
> objective of these two are quite similar.
>
> =  
I agree that it would be good to integrate features whenever poss= ible.
We just need to figure out how todo that.

> I'd like to = get others' opinion on the integration of these two
> documents.
&= gt;
> P.S.: the solution proposed in this document is kind of Diamete= r server
> initiated communication. There are some discussions on thi= s issue in the
> exploder recently triggered by an ITU-T liaison, it = has not yet reached
> a consensus though.
>  

= Ciao
Hannes

> Regards,
> Dong
>
>
> __= _____________________________________________
> DiME mailing list
= > DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
= >  


_______________________________________________=
DiME mailing list
DiME@ietf.org
https://www1.ietf.org/mailman/listin= fo/dime

--===============0104366502== 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 --===============0104366502==-- From dime-bounces@ietf.org Thu Mar 22 03:42:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUHw4-0008AU-3O; Thu, 22 Mar 2007 03:42:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUHw0-0008A3-SX for dime@ietf.org; Thu, 22 Mar 2007 03:42:08 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUHvv-0003u0-T1 for dime@ietf.org; Thu, 22 Mar 2007 03:42:08 -0400 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2M7fC7C060652; Thu, 22 Mar 2007 02:41:13 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 22 Mar 2007 03:41:13 -0400 To: "Chowdhury, Kuntal" Subject: Re: [Dime] Consensus Call regarding Diameter Mobile IPv6HA-to-AAAHsupport Message-ID: <20070322074113.GB1146@steelhead> References: <7CCD07160348804497EF29E9EA5560D7024D9D49@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D49@exchtewks2.starentnetworks.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 91 X-Spam-Score: -2.4 (--) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org On Tue, Mar 20, 2007 at 02:49:16PM -0400, Chowdhury, Kuntal wrote: > > In some scenarios, the IPsec gateway (e.g. 3GPP:PDG, 3GPP2:PDIF) may be > collocated with the Home Agent. To support such scenarios, there should > be a clear way to identify the type of service the MN is trying to > access i.e. it is trying to only establish an IPsec session with the > IPsec gateway or it wants to access MIPv6 service as well. The IDr field > in the IKEv2 exchange can be used for this type of service selection. > > So, I would suggest that MIPv6 Diameter application is used when such > (IPsec or IPsec+MIP6) indication is available at the Home Agent. I think that separation of authentication and authorization fits better to this scenario. Diameter EAP application is used for EAP over IKEv2 for both cases (IPsec and IPsec+MIP6). For IPsec+MIP6, you additionally run Diameter MIP6 application to obtain MIP6 parameters. Yoshihiro Ohba > > Best regards, > Kuntal > > > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, March 14, 2007 10:06 PM > > To: Hannes Tschofenig; dime@ietf.org > > Subject: RE: [Dime] Consensus Call regarding Diameter Mobile > IPv6HA-to- > > AAAHsupport > > > > Yes. > > > > Authentication -- the EAP part and Authorization should happen in one > > Diameter Application. > > > > > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, March 14, 2007 5:22 PM > > To: dime@ietf.org > > Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 > > HA-to-AAAHsupport > > > > Hi all, > > > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > document > > (see > > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > > we defined a new Diameter application and we then decided that we > should > > separate the authentication and authorization interaction to avoid an > > update of this specification when RFC 4072 is updated. This means that > > the Diameter MIPv6 app-ID is used for the authorization part and the > > Diameter EAP app-ID is used for the authentication part. Diameter > > routing may cause authentication and authorization messages to be > routed > > to different servers. This caused a lengthy debate on security issues. > > It seems that there is a lot of complexity associated with this > > approach. > > > > I would therefore like to hear whether working group members are OK > with > > performing authentication and authorization as part of one Diameter > > application. This would therefore mean that we are going to use the > > Diameter MIPv6 app-ID for authentication and for authorization. > > > > Please state your opinion. > > > > 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 > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 04:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIMF-0003pL-PV; Thu, 22 Mar 2007 04:09:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUIME-0003pD-8Q for dime@ietf.org; Thu, 22 Mar 2007 04:09:14 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUIMC-0000yQ-Jd for dime@ietf.org; Thu, 22 Mar 2007 04:09:14 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 09:09:11 +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: RE: [Dime] Updated QoS Drafts Date: Thu, 22 Mar 2007 09:09:07 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301B53396@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Updated QoS Drafts Thread-Index: AcdsPJhE7w2SR3saSVyH10MYJs6hRwAG0YJg From: To: , , X-OriginalArrivalTime: 22 Mar 2007 08:09:11.0143 (UTC) FILETIME=[5F60FF70:01C76C59] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Avi,=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: 22. maaliskuuta 2007 6:40 > To: Hannes Tschofenig; Sun, Dong (Dong) > Cc: dime@ietf.org > Subject: RE: [Dime] Updated QoS Drafts >=20 > =20 > =20 > The Diameter QoS Application was written to server a particular need.=20 > =20 > I think we should incorporate a push and a pull model into=20 > that document. > =20 > Its not like some SDO is waiting for us to finish this work. =20 3GPP wants it now for rel-7.. even though the reference is still to draft-tschofenig-dime-diameter-qos-01. The stuff 3GPP is after is in the WG qos draft as well. Cheers, Jouni > We do probably need to work on the QoS attributes and we=20 > should be using the approach of working on them outside this=20 > document. We need to finish the QoS attribute work fast. > =20 > Avi Lior Office: +1 613 591-9104 x 6417 Cell : +1 613 796-4183 >=20 > ________________________________ >=20 > From: Hannes Tschofenig > Sent: Thu 3/8/2007 5:04 AM > To: Sun, Dong (Dong) > Cc: dime@ietf.org > Subject: Re: [Dime] Updated QoS Drafts >=20 >=20 >=20 > Hi Dong, >=20 > thanks for your clarifications. Please find some comments below: >=20 > Sun, Dong (Dong) wrote: > >=20 > > Hi, > > Some clarifications and comments: > > ~~~~~~~~~~~~~ > > -----Original Message----- > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > Sent: Wednesday, March 07, 2007 5:51 AM > > To: dime@ietf.org > > Subject: [Dime] Updated QoS Drafts > > > > Hi all, > > ... > > ... > > " > >=20 > http://tools.ietf.org/html/draft-sun-dime-diameter-resource-control-re > > qu > > irements-01 > > > > This document takes a different spin and extends the=20 > > > > document by supporting a "generic push" approach. By=20 > "generic push"=20 > > I refer to the > > ability of an arbitrary entity, such as an SIP proxy, to=20 > signal to=20 > > another box. > > Note that this is not the same as the server-initiated=20 > communication. > > " > > ~~~~~~~~~~~~~~~~~ > > > > [Dong] The "Push model" defined in above I-D doesn't aim to=20 > define the=20 > > ability of an arbitrary entity, such as a SIP proxy, to signal to=20 > > another box. This document actually addresses the same=20 > interface as in=20 > > the current QoS application=20 > (draft-ietf-dime-diameter-qos-00). Since=20 > > the current QoS application only supports the Pull model=20 > that is not=20 > > suitable for some circumstances (e.g. when the network=20 > elements cannot=20 > > trigger the QoS authorization request and/or the endpoint does not=20 > > support any QoS signaling/capability, which is quite common in=20 > > wireline networks), the I-D intends to complement current QoS=20 > > application document and make a generic framework in order=20 > to support=20 > > various networks, endpoints and applications. > > =20 > I agree that draft-ietf-dime-diameter-qos-00 is not=20 > particularly strong on the description of server-initiated =20 > communication. > This is, however, a basic feature of the Diameter Base protocol. >=20 > Typically, server-initiated messages are still sent after the=20 > initial session setup took place based on an interaction with=20 > the Diameter client. > For example, you have a network access authentication=20 > procedure taking place. Then, during the lifetime of the=20 > session some authorization relevant aspects change at the=20 > Diameter server and it initiates a re-authorization exchange. >=20 > > Currently, this document mainly focuses on discussing the=20 > requirements=20 > > and framework of a generic resource control system, and=20 > also proposes=20 > > some potential solutions to solve the issue. IMO, it will=20 > be better to=20 > > integrate this document with QoS application document together to=20 > > formulate a single document on this subject since the scope and=20 > > objective of these two are quite similar. > > > > =20 > I agree that it would be good to integrate features whenever possible. > We just need to figure out how todo that. >=20 > > I'd like to get others' opinion on the integration of these two=20 > > documents. > > > > P.S.: the solution proposed in this document is kind of Diameter=20 > > server initiated communication. There are some discussions on this=20 > > issue in the exploder recently triggered by an ITU-T=20 > liaison, it has=20 > > not yet reached a consensus though. > > =20 >=20 > Ciao > Hannes >=20 > > Regards, > > Dong > > > > > > _______________________________________________ > > 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 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 05:20:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJSY-0003gR-VB; Thu, 22 Mar 2007 05:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUJSX-0003gC-3a for dime@ietf.org; Thu, 22 Mar 2007 05:19:49 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUJSW-0000gJ-9D for dime@ietf.org; Thu, 22 Mar 2007 05:19:49 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFA00FI2SL64K@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 22 Mar 2007 09:19:55 +0000 (GMT) Received: from IBM4307EA0CEF3 (dhcp-135c.ietf68.org [130.129.19.92]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFA001RTSL57N@lhrga01-in.huawei.com> for dime@ietf.org; Thu, 22 Mar 2007 09:19:54 +0000 (GMT) Date: Thu, 22 Mar 2007 10:19:33 +0100 From: Tina TSOU To: vfajardo@tari.toshiba.com, MORAND Lionel RD-CORE-ISS Message-id: <00e501c76c63$34b6dd30$5c138182@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 4166dd0e0c668adc975c3d3e0f1bce3b Cc: dime@ietf.org Subject: [Dime] Vendor-Specific-Application-Id 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="===============0497536553==" Errors-To: dime-bounces@ietf.org This is a multi-part message in MIME format. --===============0497536553== Content-type: multipart/alternative; boundary="Boundary_(ID_UR8Hh7iLcy7hbBa2l3Ixfg)" This is a multi-part message in MIME format. --Boundary_(ID_UR8Hh7iLcy7hbBa2l3Ixfg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable ----- Original Message -----=20 From: Tina TSOU=20 To: MORAND Lionel RD-CORE-ISS ; vfajardo@tari.toshiba.com=20 Cc: Tom-PT Taylor ; dime@ietf.org=20 Sent: Thursday, March 22, 2007 9:45 AM Subject: Vendor-Specific-Application-Id AVP Hi Victor and Lionel, Issue 33: Why is there a need to Vendor-Specific-Application-Id AVP=20 =E2=80=A2Details: If application id is flat and vendor app ids are in = this same space, why is there a need to indicate the Vendor-Id ? The = intent and usage of the AVP is never fully understood.=20 =E2=80=A2Status: No activity Attached please find ITU-T Rs (Comparable to 3GPP Rx, Gq) which = related to this issue. Does it work in a reasonable way? B. R. Tina 8 Use of the Diameter base protocol With the clarifications listed in the following sub-clauses the = Diameter Base Protocol defined by IETF RFC 3588 shall apply. 8.1 Securing Diameter Messages For secure transport of Diameter messages, the method defined in ETSI = TS 133 210 (3GPP TS 33.210) shall be used. 8.2 Accounting functionality Accounting functionality (Accounting Session State Machine, related = command codes and AVPs) is not used on the Rs interface. 8.3 Use of sessions As described in sub-clauses 6.1 and 6.2, operation for a given session = may be stateful or stateless. Stateless operation is always indicated = definitively by a value of NO_STATE_MAINTAINED in an Auth-Session-State = AVP returned by the PD-PE in the AA-Answer response to the initial = AA-Request. For stateful operation, the Session-Id AVP shall be present = in all messages passing between the SCE and the PD-PE, as described in = RFC 3588. The Session-Termination-Request (STR) and = Session-Termination-Answer (STA) commands defined in RFC 3588 shall be = used in order to terminate the Diameter user sessions. For stateless = operation, the Class AVP returned in the AA-Answer response to the = initial AA-Request shall be present in all messages passing between the = SCE and the PD-PE. The Diameter user session shall be terminated by = sending an AA-Request containing the Class AVP and the = Resource-Reservation-Mode AVP with a value of RESOURCE_RELEASE (3). 8.4 Transport protocol Diameter messages over the Rs interface shall make use of SCTP (RFC = 2960) and shall utilize the new SCTP checksum method specified in RFC = 3309. 8.5 Routing considerations This sub-clause specifies the use of the Diameter routing AVPs = Destination-Realm and Destination-Host for routing. The SCE obtains the contact address of the PD-PE for a given user = through the means identified in sub-clause 7.3.1/Y.2111. Both the = Destination-Realm and Destination-Host AVPs shall be present in the = request.=20 To ensure that messages are routed to the correct application at the = destination host, the Diameter message header of each message sent shall = contain either the Rs application identifier (16777235) or the Gq = application identifier (16777222) as agreed during CER/CEA negotiation. = (See the next sub-clause.) 8.6 Advertising Application Support The Capabilities-Exchange-Request and Capabilities-Exchange-Answer = commands are specified in the Diameter Base Protocol (RFC 3588). The = Diameter base application identifier (0) shall be used in the Diameter = message header of these messages. The SCE and the PD-PE shall advertise the support of the Rs and/or Gq = applications by including an instance of the = Vendor-Specific-Application-Id grouped AVP within the = Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands = for each application supported, according to the following rules: (1) The SCE shall advertise support of the Rs application if = it supports stateless operation and of the Gq application if it supports = stateful operation. It shall advertise both applications if it supports = both operating modes. (2) The PD-PE shall respond by indicating the subset of = applications it is prepared to support, out of those offered by the SCE. = If this subset is empty, the PD-PE's response shall be as described in = section 5.3/RFC 3588. If both the SCE and the PD-PE indicate support of the Rs application, = then the Rs application identifier (16777235) shall be used in the = Diameter message header of all subsequent messages exchanged within this = association. Otherwise the Gq application identifier (16777222) shall be = placed in those headers. =20 Support of the Rs application within the CER/CEA is indicated by = supplying an instance of the Vendor-Specific-Application-Id containing a = Vendor-Id AVP set to ITU-T (11502) and an Auth-Application-Id AVP set to = Rs (16777235). Support of the Gq application within the CER/CEA is = indicated by supplying an instance of the Vendor-Specific-Application-Id = containing a Vendor-Id AVP set to 3GPP (10415) and an = Auth-Application-Id AVP set to Gq (16777222). NOTE =E2=80=93 The Vendor-Id AVP included in = Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands = at the command level (as opposed to the Vendor-Id instances within the = Vendor-Specific-Application-Id AVPs as described in the previous = paragraph) shall indicate the manufacturer of the Diameter node as per = RFC 3588. The SCE and PD-PE shall advertise the support of AVPs specified in = 3GPP, ETSI, and ITU-T documents by including the values 10415 (3GPP), = 13019 (ETSI) and 11502 (ITU-T) in three different instances of the = Supported-Vendor-Id AVP in the CER and CEA commands respectively. --Boundary_(ID_UR8Hh7iLcy7hbBa2l3Ixfg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable =EF=BB=BF
 
----- Original Message -----
From:=20 Tina = TSOU
To: MORAND Lionel = RD-CORE-ISS ;=20 vfajardo@tari.toshiba.com =
Sent: Thursday, March 22, 2007 = 9:45=20 AM
Subject: = Vendor-Specific-Application-Id=20 AVP

Hi Victor and Lionel,
Issue 33: = Why is there a=20 need to Vendor-Specific-Application-Id AVP
=E2=80=A2Details: If = application id is=20 flat and vendor app ids are in this same space, why is there a need to = indicate the Vendor-Id ? The intent and usage of the AVP is never = fully=20 understood.
=E2=80=A2Status: No activity
 
Attached please find ITU-T Rs = (Comparable to 3GPP=20 Rx, Gq) which related to this issue.
Does it work in a reasonable = way?
 
B. R.
Tina
 

8          =20 Use of the Diameter base protocol

With the=20 clarifications listed in the following sub-clauses the Diameter Base = Protocol=20 defined by IETF RFC 3588 shall apply.

8.1       =20 Securing Diameter Messages

For secure=20 transport of Diameter messages, the method defined in ETSI TS 133 210 = (3GPP TS=20 33.210) shall be used.

8.2       =20 Accounting functionality

Accounting=20 functionality (Accounting Session State Machine, related command codes = and=20 AVPs) is not used on the Rs interface.

8.3        = Use=20 of sessions

As described=20 in sub-clauses 6.1 and 6.2, operation for a given session may be = stateful or=20 stateless. Stateless operation is always indicated definitively by a = value of=20 NO_STATE_MAINTAINED in an Auth-Session-State AVP returned by the PD-PE = in the=20 AA-Answer response to the initial AA-Request. For stateful operation, = the=20 Session-Id AVP shall be present in all messages passing between the = SCE and=20 the PD-PE, as described in RFC 3588. The Session-Termination-Request = (STR) and=20 Session-Termination-Answer (STA) commands defined in RFC 3588 shall be = used in=20 order to terminate the Diameter user sessions. For stateless = operation, the=20 Class AVP returned in the AA-Answer response to the initial AA-Request = shall=20 be present in all messages passing between the SCE and the PD-PE. The = Diameter=20 user session shall be terminated by sending an AA-Request containing = the Class=20 AVP and the Resource-Reservation-Mode AVP = with a value=20 of RESOURCE_RELEASE = (3).

8.4       =20 Transport protocol

Diameter=20 messages over the Rs interface shall make use of SCTP (RFC 2960) and = shall=20 utilize the new SCTP checksum method specified in RFC=20 3309.

8.5       =20 Routing considerations

This=20 sub-clause specifies the use of the Diameter routing AVPs = Destination-Realm=20 and Destination-Host for routing.

The SCE=20 obtains the contact address of the PD-PE for a given user through the = means=20 identified in sub-clause 7.3.1/Y.2111. Both the Destination-Realm and=20 Destination-Host AVPs shall be present in the request. =

To ensure that=20 messages are routed to the correct application at the destination = host, the=20 Diameter message header of each message sent shall contain either the = Rs=20 application identifier (16777235) or the Gq application identifier = (16777222)=20 as agreed during CER/CEA negotiation. (See the next=20 sub-clause.)

8.6       =20 Advertising Application Support

The=20 Capabilities-Exchange-Request and Capabilities-Exchange-Answer = commands are=20 specified in the Diameter Base Protocol (RFC 3588). The Diameter base=20 application identifier (0) shall be used in the Diameter message = header of=20 these messages.

The SCE and=20 the PD-PE shall advertise the support of the Rs and/or Gq applications = by=20 including an instance of the Vendor-Specific-Application-Id grouped = AVP within=20 the Capabilities-Exchange-Request and Capabilities-Exchange-Answer = commands=20 for each application supported, according to the following=20 rules:

(1)        =20 The SCE shall advertise support of the Rs application if it = supports=20 stateless operation and of the Gq application if it supports stateful=20 operation. It shall advertise both applications if it supports both = operating=20 modes.

(2)        =20 The PD-PE shall respond by indicating the subset of = applications it is=20 prepared to support, out of those offered by the SCE. If this subset = is empty,=20 the PD-PE's response shall be as described in section 5.3/RFC=20 3588.

If both the=20 SCE and the PD-PE indicate support of the Rs application, then the Rs=20 application identifier (16777235) shall be used in the Diameter = message header=20 of all subsequent messages exchanged within this association. = Otherwise the Gq=20 application identifier (16777222) shall be placed in those = headers. 

Support of the=20 Rs application within the CER/CEA is indicated by supplying an = instance of the=20 Vendor-Specific-Application-Id containing a Vendor-Id AVP set to ITU-T = (11502)=20 and an Auth-Application-Id AVP set to Rs (16777235). Support of the Gq = application within the CER/CEA is indicated by supplying an instance = of the=20 Vendor-Specific-Application-Id containing a Vendor-Id AVP set to 3GPP = (10415)=20 and an Auth-Application-Id AVP set to Gq = (16777222).

NOTE =E2=80=93=20 The = Vendor-Id AVP=20 included in Capabilities-Exchange-Request and = Capabilities-Exchange-Answer=20 commands at the command level (as opposed to the Vendor-Id instances = within=20 the Vendor-Specific-Application-Id AVPs as described in the previous=20 paragraph) shall indicate the manufacturer of the Diameter node as per = RFC=20 3588.

The SCE and=20 PD-PE shall advertise the support of AVPs specified in 3GPP, ETSI, and = ITU-T=20 documents by including the values 10415 (3GPP), 13019 (ETSI) and 11502 = (ITU-T)=20 in three=20 different instances of the = Supported-Vendor-Id=20 AVP = in the CER and CEA commands=20 respectively.

--Boundary_(ID_UR8Hh7iLcy7hbBa2l3Ixfg)-- --===============0497536553== 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 --===============0497536553==-- From dime-bounces@ietf.org Thu Mar 22 07:56:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULuX-0002oF-Ep; Thu, 22 Mar 2007 07:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HULuV-0002o1-Vy for dime@ietf.org; Thu, 22 Mar 2007 07:56:51 -0400 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HULuU-00015V-KV for dime@ietf.org; Thu, 22 Mar 2007 07:56:51 -0400 Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id l2MBuQ1q061834; Thu, 22 Mar 2007 06:56:27 -0500 (EST) (envelope-from vfajardo@tari.toshiba.com) Message-ID: <46026EEB.70405@tari.toshiba.com> Date: Thu, 22 Mar 2007 07:56:27 -0400 From: Victor Fajardo User-Agent: Thunderbird 1.5.0.10 (X11/20070221) MIME-Version: 1.0 To: Tina TSOU References: <00e501c76c63$34b6dd30$5c138182@IBM4307EA0CEF3> In-Reply-To: <00e501c76c63$34b6dd30$5c138182@IBM4307EA0CEF3> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by toshi17.tari.toshiba.com id l2MBuQ1q061834 X-Spam-Score: 0.4 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: dime@ietf.org Subject: [Dime] Re: Vendor-Specific-Application-Id 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 Hi Tina, I'm assuming you meant 8.6, comments inline: > > 8.6 Advertising Application Support > > The Capabilities-Exchange-Request and Capabilities-Exchange-Answer > commands are specified in the Diameter Base Protocol (RFC 3588). > The Diameter base application identifier (0) shall be used in the > Diameter message header of these messages. > > The SCE and the PD-PE shall advertise the support of the Rs and/or > Gq applications by including an instance of the > Vendor-Specific-Application-Id grouped AVP within the > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > commands for each application supported, according to the > following rules: > > (1) The SCE shall advertise support of the Rs application > if it supports stateless operation and of the Gq application if it > supports stateful operation. It shall advertise both applications > if it supports both operating modes. > > (2) The PD-PE shall respond by indicating the subset of > applications it is prepared to support, out of those offered by > the SCE. If this subset is empty, the PD-PE's response shall be as > described in section 5.3/RFC 3588. > > If both the SCE and the PD-PE indicate support of the Rs > application, then the Rs application identifier (16777235) shall > be used in the Diameter message header of all subsequent messages > exchanged within this association. Otherwise the Gq application > identifier (16777222) shall be placed in those headers. > Ok. Are you planning to populate any other app-id avps as well ? > Support of the Rs application within the CER/CEA is indicated by > supplying an instance of the Vendor-Specific-Application-Id > containing a Vendor-Id AVP set to ITU-T (11502) and an > Auth-Application-Id AVP set to Rs (16777235). Support of the Gq > application within the CER/CEA is indicated by supplying an > instance of the Vendor-Specific-Application-Id containing a > Vendor-Id AVP set to 3GPP (10415) and an Auth-Application-Id AVP > set to Gq (16777222). > > NOTE/ /=E2=80=93 The Vendor-Id AVP included in > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > commands at the command level (as opposed to the Vendor-Id > instances within the Vendor-Specific-Application-Id AVPs as > described in the previous paragraph) shall indicate the > manufacturer of the Diameter node as per RFC 3588. > > The SCE and PD-PE shall advertise the support of AVPs specified in > 3GPP, ETSI, and ITU-T documents by including the values 10415 > (3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different > instances of the Supported-Vendor-Id AVP in the CER and CEA > commands respectively. > This seems ok to me. In relation to issue #33, the vendor-id would be=20 more interesting to the Rs/Gq application rather than anything else to=20 do with diameter processing so using it in CER/CEA is ok. As I=20 mentioned, this means that the vendor-id will not be relevant in any=20 diameter base protocol decision making, i.e. routing. regards, victor _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 08:26:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMNb-0006rO-VR; Thu, 22 Mar 2007 08:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMNa-0006rE-MR for dime@ietf.org; Thu, 22 Mar 2007 08:26:54 -0400 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMNZ-00016Q-8G for dime@ietf.org; Thu, 22 Mar 2007 08:26:54 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:26:51 +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 Date: Thu, 22 Mar 2007 13:26:47 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D0@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIP6 NAS-HAAA issue #2 Thread-Index: AcdsfVxBJmef4RVxTW2piD2cvOqpzA== From: To: X-OriginalArrivalTime: 22 Mar 2007 12:26:51.0216 (UTC) FILETIME=[5E4CED00:01C76C7D] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Dime] MIP6 NAS-HAAA issue #2 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org As mentioned in the Dime WG meeting here is some background and=20 proposal for the presented issue #2. So this is about capability announcement AVP and local HA allocation/authorization: o in DER/AAR the ASP/NAS needs to have a mechanism to indicate it has a local HA that could be allocated for the MN. o in DEA/AAA the MSA(/MSP) needs to be able to return its own HA info as well as authorize the ASP/NAS proposed HA. Currently this scenario does not work too well in -03. Proposal 1) For the above situation we probably need an explicit AVP to ask and grant authorization of the local HA in the ASP. This approach does not, however, work too well if the ASP/NAS has multiple local HAs that it wants to be authorized. Proposal 2) Another proposal that I have been thinking uses the implicit capability signaling we have currently in -03. Just put all local HA infos into MIP6 bootstrapping AVPs. The MSA returns those back in DEA/AAA that are authorized and if needed the MSA also includes its own HA infos. For the case when ASP/NAS does not have a local HA to propose the DER/AAR would for example just contain a HA address AVP with unspecified ::/128 address. Now I would like to ask from the WG which way would be better. Or is there yet another solution that should be considered? Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 08:37:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMYB-0007XQ-8W; Thu, 22 Mar 2007 08:37:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUMYA-0007X6-1z for dime@ietf.org; Thu, 22 Mar 2007 08:37:50 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUMY8-0002on-L6 for dime@ietf.org; Thu, 22 Mar 2007 08:37:50 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 13:37:47 +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 Date: Thu, 22 Mar 2007 13:37:44 +0100 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIP6 NAS-HAAA issue #1 Thread-Index: AcdsfuOHC3+c5oNVQU68Yh1z7rQnJA== From: To: X-OriginalArrivalTime: 22 Mar 2007 12:37:47.0832 (UTC) FILETIME=[E5AC9380:01C76C7E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Dime] MIP6 NAS-HAAA issue #1 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org About the issue #1 presented during the Dime WG meeting. If the ASP/NAS needs to send or the MSA needs to return more than one HA information the current AVP formulation does not work. This is because we have defined AVP counts as "at most one". Furthermore, if we are about to allow "zero or more" AVPs we need to have a way to group HA address, FQDN, home link prefix etc together. For that purpose a grouped AVP would be OK. So the question is (also related to the issue #2) whether=20 "zero or more" HAs must be supported. At least the recent discussion in MIP6 list points to this direction. Anyway, my personal opinion is that defining a grouped AVP does-no-harm anyway. Below is one proposal for a grouped AVP: MIP6-Info ::=3D < AVP Header: 297 > [ MIP6-Home-Agent-Address ] [ MIP6-Home-Agent-FQDN ] [ MIP6-Home-Link-Prefix ] [ MIP6-Home-Address ] ... Any opinions? Cheers, Jouni _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 10:38:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOR4-0003ug-Ps; Thu, 22 Mar 2007 10:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUOR3-0003ua-I0 for dime@ietf.org; Thu, 22 Mar 2007 10:38:37 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUOR1-0001Na-KO for dime@ietf.org; Thu, 22 Mar 2007 10:38:37 -0400 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Mar 2007 15:38:34 +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 Date: Thu, 22 Mar 2007 15:37:54 +0100 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02604699024@FTRDMEL2.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vendor-Specific-Application-Id AVP Thread-Index: AcdseS/jTVdDlcz5TbqJRko71lJbrAAFTX+A From: "MORAND Lionel RD-CORE-ISS" To: "Victor Fajardo" , "Tina TSOU" X-OriginalArrivalTime: 22 Mar 2007 14:38:34.0093 (UTC) FILETIME=[C4C841D0:01C76C8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: dime@ietf.org Subject: [Dime] RE: Vendor-Specific-Application-Id 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 It was exactly my point during the meeting session. And what is true for Rs/Gq is also true for Cx, Sh and other SDO = specific diameter applications, where the vendor-id identifies either = the SDO or the vendor. BR, Lionel =20 > -----Message d'origine----- > De : Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20 > Envoy=E9 : jeudi 22 mars 2007 12:56 > =C0 : Tina TSOU > Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org; Tom-PT Taylor > Objet : Re: Vendor-Specific-Application-Id AVP >=20 > Hi Tina, >=20 > I'm assuming you meant 8.6, comments inline: >=20 > > > > 8.6 Advertising Application Support > > > > The Capabilities-Exchange-Request and=20 > Capabilities-Exchange-Answer > > commands are specified in the Diameter Base Protocol (RFC 3588). > > The Diameter base application identifier (0) shall be=20 > used in the > > Diameter message header of these messages. > > > > The SCE and the PD-PE shall advertise the support of=20 > the Rs and/or > > Gq applications by including an instance of the > > Vendor-Specific-Application-Id grouped AVP within the > > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > > commands for each application supported, according to the > > following rules: > > > > (1) The SCE shall advertise support of the Rs=20 > application > > if it supports stateless operation and of the Gq=20 > application if it > > supports stateful operation. It shall advertise both=20 > applications > > if it supports both operating modes. > > > > (2) The PD-PE shall respond by indicating the subset of > > applications it is prepared to support, out of those offered by > > the SCE. If this subset is empty, the PD-PE's response=20 > shall be as > > described in section 5.3/RFC 3588. > > > > If both the SCE and the PD-PE indicate support of the Rs > > application, then the Rs application identifier (16777235) shall > > be used in the Diameter message header of all=20 > subsequent messages > > exchanged within this association. Otherwise the Gq application > > identifier (16777222) shall be placed in those headers. > > >=20 > Ok. Are you planning to populate any other app-id avps as well ? >=20 >=20 > > Support of the Rs application within the CER/CEA is indicated by > > supplying an instance of the Vendor-Specific-Application-Id > > containing a Vendor-Id AVP set to ITU-T (11502) and an > > Auth-Application-Id AVP set to Rs (16777235). Support of the Gq > > application within the CER/CEA is indicated by supplying an > > instance of the Vendor-Specific-Application-Id containing a > > Vendor-Id AVP set to 3GPP (10415) and an Auth-Application-Id AVP > > set to Gq (16777222). > > > > NOTE/ /- The Vendor-Id AVP included in > > Capabilities-Exchange-Request and Capabilities-Exchange-Answer > > commands at the command level (as opposed to the Vendor-Id > > instances within the Vendor-Specific-Application-Id AVPs as > > described in the previous paragraph) shall indicate the > > manufacturer of the Diameter node as per RFC 3588. > > > > The SCE and PD-PE shall advertise the support of AVPs=20 > specified in > > 3GPP, ETSI, and ITU-T documents by including the values 10415 > > (3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different > > instances of the Supported-Vendor-Id AVP in the CER and CEA > > commands respectively. > > >=20 > This seems ok to me. In relation to issue #33, the vendor-id=20 > would be more interesting to the Rs/Gq application rather=20 > than anything else to do with diameter processing so using it=20 > in CER/CEA is ok. As I mentioned, this means that the=20 > vendor-id will not be relevant in any diameter base protocol=20 > decision making, i.e. routing. >=20 >=20 > regards, > victor >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 13:32:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR8n-0003QM-1Q; Thu, 22 Mar 2007 13:31:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUR8l-0003Oa-Hb for dime@ietf.org; Thu, 22 Mar 2007 13:31:55 -0400 Received: from ug-out-1314.google.com ([66.249.92.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HUR8k-0003OU-0n for dime@ietf.org; Thu, 22 Mar 2007 13:31:55 -0400 Received: by ug-out-1314.google.com with SMTP id 72so727690ugd for ; Thu, 22 Mar 2007 10:31:53 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bzs3DDvOdmJvWqzDxWhYYvWGUxh345vol5Maz8rmvENayiAP+cNKmG9pQxY3I/WX2ICSdutiJNbwJGZ4aFfWTy9O0HOKpEyw7DLxgEGIFpFJkBcWqMeFbaPR0NxVlGVA//Li6nJ8i34X04x8Hi8syg3mFE2hn5ael3qvEpUd1tQ= 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=IApvmToZOIAwpLjP4bTJtldcCckXw7TiMklf8dd6KmWdaMY7+192+Zt6V54eQrpM6s3LzU7/pWut4xCaJVM277Fsjpi/dbqXktNPMjO9ShezuvnXW3Z9ooFgzxe57G+q+xOMJ053P3ruIp6zydwAxSV2UvIf6Zx7S9U22k3TvBM= Received: by 10.67.119.13 with SMTP id w13mr5226183ugm.1174584712741; Thu, 22 Mar 2007 10:31:52 -0700 (PDT) Received: by 10.66.238.9 with HTTP; Thu, 22 Mar 2007 10:31:52 -0700 (PDT) Message-ID: Date: Thu, 22 Mar 2007 18:31:52 +0100 From: "Gerardo Giaretta" To: "jouni.korhonen@teliasonera.com" Subject: Re: [Dime] MIP6 NAS-HAAA issue #2 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D0@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D0@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.5 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, one question: why would the MSA need to authorize a specific local HA? I guess that the MSA will authorize a local HA assignment based on user's profile; I see the assignment of a specific HA among the possible local HAs as something that is controlled by the ASP/MSP. Can you give me some examples you have in mind that needs the authorization of an explicit local HA? Thanks, --Gerardo On 3/22/07, jouni.korhonen@teliasonera.com wrote: > > As mentioned in the Dime WG meeting here is some background and > proposal for the presented issue #2. So this is about capability > announcement AVP and local HA allocation/authorization: > > o in DER/AAR the ASP/NAS needs to have a mechanism to indicate > it has a local HA that could be allocated for the MN. > > o in DEA/AAA the MSA(/MSP) needs to be able to return its own > HA info as well as authorize the ASP/NAS proposed HA. > > Currently this scenario does not work too well in -03. > > Proposal 1) > > For the above situation we probably need an explicit AVP to ask > and grant authorization of the local HA in the ASP. This approach > does not, however, work too well if the ASP/NAS has multiple > local HAs that it wants to be authorized. > > Proposal 2) > > Another proposal that I have been thinking uses the implicit > capability signaling we have currently in -03. Just put all > local HA infos into MIP6 bootstrapping AVPs. The MSA returns > those back in DEA/AAA that are authorized and if needed the > MSA also includes its own HA infos. > > For the case when ASP/NAS does not have a local HA to propose > the DER/AAR would for example just contain a HA address AVP > with unspecified ::/128 address. > > Now I would like to ask from the WG which way would be better. > Or is there yet another solution that should be considered? > > Cheers, > Jouni > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Thu Mar 22 13:38:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUREp-0002Uh-HI; Thu, 22 Mar 2007 13:38:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUREo-0002Sz-7m for dime@ietf.org; Thu, 22 Mar 2007 13:38:10 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUREm-0005t6-R3 for dime@ietf.org; Thu, 22 Mar 2007 13:38:10 -0400 Received: by ug-out-1314.google.com with SMTP id 72so729543ugd for ; Thu, 22 Mar 2007 10:38:08 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aqn2BvW4Ety2g6+XVC0nthHYqfDerrjVgN1JUkUK2xcgLwV/42eWYecLkTJJnuqsx/juXe4OpirQyQmfafvjit0aUi9oTU/CgHsYIRrASooZevCddAs/uvoLFlshusXGs/yf2tebneN+12dL6SkblV79UZNTI2PiiReGNuCQbao= 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=TVhxb9sP/SB5xIY2BoV8/Pg0TNjwc7M8G6mccfFifCaguAUHF8qNccsRLyHjmpopRAKM7W/VTRk8kbwFpTW2xoGwbQ+uUj79ssjOyN/etM1vLjkwpMNmbnSA/xj2hNTlXo3idjNCJbZTJJ355nr4g451D8n7aYRAWRxIDwCPFCQ= Received: by 10.67.101.10 with SMTP id d10mr5190972ugm.1174585088018; Thu, 22 Mar 2007 10:38:08 -0700 (PDT) Received: by 10.66.238.9 with HTTP; Thu, 22 Mar 2007 10:38:07 -0700 (PDT) Message-ID: Date: Thu, 22 Mar 2007 18:38:07 +0100 From: "Gerardo Giaretta" To: "jouni.korhonen@teliasonera.com" Subject: Re: [Dime] MIP6 NAS-HAAA issue #1 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.5 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Again I don't see any reason to send multiple HAs from ASP to MSA. The other direction makes more sense. The grouped AVP is fine with me. One side note: the usage of DHCP for HoA assigment is still under discussion in MIP6. --Gerardo On 3/22/07, jouni.korhonen@teliasonera.com wrote: > > About the issue #1 presented during the Dime WG meeting. If > the ASP/NAS needs to send or the MSA needs to return more than > one HA information the current AVP formulation does not work. > This is because we have defined AVP counts as "at most one". > Furthermore, if we are about to allow "zero or more" AVPs we > need to have a way to group HA address, FQDN, home link prefix > etc together. For that purpose a grouped AVP would be OK. > > So the question is (also related to the issue #2) whether > "zero or more" HAs must be supported. At least the recent > discussion in MIP6 list points to this direction. > > Anyway, my personal opinion is that defining a grouped AVP > does-no-harm anyway. Below is one proposal for a grouped AVP: > > MIP6-Info ::= < AVP Header: 297 > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > ... > > Any opinions? > > Cheers, > Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 23 06:56:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUhRQ-0006wx-71; Fri, 23 Mar 2007 06:56:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUhRP-0006tf-HO for dime@ietf.org; Fri, 23 Mar 2007 06:56:15 -0400 Received: from lhrga01-in.huawei.com ([195.33.106.110]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUhRK-0000JD-LD for dime@ietf.org; Fri, 23 Mar 2007 06:56:15 -0400 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFC009J0RPQFA@lhrga01-in.huawei.com> for dime@ietf.org; Fri, 23 Mar 2007 10:56:15 +0000 (GMT) Received: from IBM4307EA0CEF3 (dhcp-4009.ietf68.org [130.129.64.9]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFC0029FRPPIY@lhrga01-in.huawei.com> for dime@ietf.org; Fri, 23 Mar 2007 10:56:14 +0000 (GMT) Date: Fri, 23 Mar 2007 11:55:53 +0100 From: Tina TSOU To: Victor Fajardo , MORAND Lionel RD-CORE-ISS Message-id: <002f01c76d39$d46809e0$a201000a@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 Content-type: text/plain; reply-type=original; charset=ISO-8859-1; format=flowed Content-transfer-encoding: QUOTED-PRINTABLE X-Priority: 3 X-MSMail-priority: Normal References: <7DBAFEC6A76F3E42817DF1EBE64CB02604699024@FTRDMEL2.rd.francetelecom.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: dime@ietf.org Subject: [Dime] Re: Vendor-Specific-Application-Id 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 ----- Original Message -----=20 =46rom: "MORAND Lionel RD-CORE-ISS" To: "Victor Fajardo" ; "Tina TSOU"=20 Cc: ; "Tom-PT Taylor" Sent: Thursday, March 22, 2007 3:37 PM Subject: RE: Vendor-Specific-Application-Id AVP It was exactly my point during the meeting session. And what is true for Rs/Gq is also true for Cx, Sh and other SDO spec= ific=20 diameter applications, where the vendor-id identifies either the SDO = or the=20 vendor. BR, Lionel > -----Message d'origine----- > De : Victor Fajardo [mailto:vfajardo@tari.toshiba.com] > Envoy=E9 : jeudi 22 mars 2007 12:56 > =C0 : Tina TSOU > Cc : MORAND Lionel RD-CORE-ISS; dime@ietf.org; Tom-PT Taylor > Objet : Re: Vendor-Specific-Application-Id AVP > > Hi Tina, > > I'm assuming you meant 8.6, comments inline: > > > > > 8.6 Advertising Application Support > > > > The Capabilities-Exchange-Request and > Capabilities-Exchange-Answer > > commands are specified in the Diameter Base Protocol (RFC 358= 8). > > The Diameter base application identifier (0) shall be > used in the > > Diameter message header of these messages. > > > > The SCE and the PD-PE shall advertise the support of > the Rs and/or > > Gq applications by including an instance of the > > Vendor-Specific-Application-Id grouped AVP within the > > Capabilities-Exchange-Request and Capabilities-Exchange-Answe= r > > commands for each application supported, according to the > > following rules: > > > > (1) The SCE shall advertise support of the Rs > application > > if it supports stateless operation and of the Gq > application if it > > supports stateful operation. It shall advertise both > applications > > if it supports both operating modes. > > > > (2) The PD-PE shall respond by indicating the subset = of > > applications it is prepared to support, out of those offered = by > > the SCE. If this subset is empty, the PD-PE's response > shall be as > > described in section 5.3/RFC 3588. > > > > If both the SCE and the PD-PE indicate support of the Rs > > application, then the Rs application identifier (16777235) sh= all > > be used in the Diameter message header of all > subsequent messages > > exchanged within this association. Otherwise the Gq applicati= on > > identifier (16777222) shall be placed in those headers. > > > > Ok. Are you planning to populate any other app-id avps as well ? No...:) > > > > Support of the Rs application within the CER/CEA is indicated= by > > supplying an instance of the Vendor-Specific-Application-Id > > containing a Vendor-Id AVP set to ITU-T (11502) and an > > Auth-Application-Id AVP set to Rs (16777235). Support of the = Gq > > application within the CER/CEA is indicated by supplying an > > instance of the Vendor-Specific-Application-Id containing a > > Vendor-Id AVP set to 3GPP (10415) and an Auth-Application-Id = AVP > > set to Gq (16777222). > > > > NOTE/ /- The Vendor-Id AVP included in > > Capabilities-Exchange-Request and Capabilities-Exchange-Answe= r > > commands at the command level (as opposed to the Vendor-Id > > instances within the Vendor-Specific-Application-Id AVPs as > > described in the previous paragraph) shall indicate the > > manufacturer of the Diameter node as per RFC 3588. > > > > The SCE and PD-PE shall advertise the support of AVPs > specified in > > 3GPP, ETSI, and ITU-T documents by including the values 10415 > > (3GPP), 13019 (ETSI) and 11502 (ITU-T) in three different > > instances of the Supported-Vendor-Id AVP in the CER and CEA > > commands respectively. > > > > This seems ok to me. In relation to issue #33, the vendor-id > would be more interesting to the Rs/Gq application rather > than anything else to do with diameter processing so using it > in CER/CEA is ok. As I mentioned, this means that the > vendor-id will not be relevant in any diameter base protocol > decision making, i.e. routing. > > > regards, > victor >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 23 10:13:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUkVn-0003DD-Dt; Fri, 23 Mar 2007 10:12:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUkVm-0003Cp-5U for dime@ietf.org; Fri, 23 Mar 2007 10:12:58 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUkVk-0005mQ-Rd for dime@ietf.org; Fri, 23 Mar 2007 10:12:58 -0400 Received: by nf-out-0910.google.com with SMTP id l36so2006521nfa for ; Fri, 23 Mar 2007 07:12:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Buiwvr/Zm2lBIKZYMLCarkuBCbf/CRg9UbiUO2XVxQxaYuhYbAzuim7byNFEu5+en+nXoEhjU70ll+BsByrtaq+GQrdPt3qe3maMNHBM3zmgHfpjvC/P+mL/k1fpm/0laj41rA1ENzQ3d/H7b54OR/Iv/srp2HXXQCf+myrU7y8= 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=uI1tAERkWzUoF67nAt6YjrSVm3qt7EjIT7djOLLBisWSvb8900qE/5nfpQzCI/Jp5JQt5YhiO3stj6hHZz5Q4d2TcrRwlpSZYhqxcJDXC5LQJ0w76s7zZFsG27+K/V5X6Qf8KwZbdKW4omz5okwNKjRKxItSk/Df0LEjr8eWebA= Received: by 10.78.166.7 with SMTP id o7mr1564145hue.1174659175733; Fri, 23 Mar 2007 07:12:55 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Fri, 23 Mar 2007 07:12:55 -0700 (PDT) Message-ID: <5e2406980703230712t6982f6a5u7b3803275ba98ea@mail.gmail.com> Date: Fri, 23 Mar 2007 15:12:55 +0100 From: "Julien Bournelle" To: "jouni.korhonen@teliasonera.com" Subject: Re: [Dime] MIP6 NAS-HAAA issue #1 In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED301B533D7@SEHAN021MB.tcad.telia.se> X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Jouni, all, I'm ok with this grouped AVP. Julien On 3/22/07, jouni.korhonen@teliasonera.com wrote: > > About the issue #1 presented during the Dime WG meeting. If > the ASP/NAS needs to send or the MSA needs to return more than > one HA information the current AVP formulation does not work. > This is because we have defined AVP counts as "at most one". > Furthermore, if we are about to allow "zero or more" AVPs we > need to have a way to group HA address, FQDN, home link prefix > etc together. For that purpose a grouped AVP would be OK. > > So the question is (also related to the issue #2) whether > "zero or more" HAs must be supported. At least the recent > discussion in MIP6 list points to this direction. > > Anyway, my personal opinion is that defining a grouped AVP > does-no-harm anyway. Below is one proposal for a grouped AVP: > > MIP6-Info ::= < AVP Header: 297 > > [ MIP6-Home-Agent-Address ] > [ MIP6-Home-Agent-FQDN ] > [ MIP6-Home-Link-Prefix ] > [ MIP6-Home-Address ] > ... > > Any opinions? > > Cheers, > Jouni > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Fri Mar 23 13:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUnSn-0006ZA-Uq; Fri, 23 Mar 2007 13:22:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUnSl-0006TS-WE for dime@ietf.org; Fri, 23 Mar 2007 13:22:04 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUnSV-0002WC-A1 for dime@ietf.org; Fri, 23 Mar 2007 13:22:03 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id CD1FE900C1 for ; Fri, 23 Mar 2007 12:21:30 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06191-06 for ; Fri, 23 Mar 2007 12:21:26 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 23 Mar 2007 12:21:26 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Mar 2007 13:21:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] Consensus Call regarding Diameter MobileIPv6HA-to-AAAHsupport Date: Fri, 23 Mar 2007 13:21:26 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D52@exchtewks2.starentnetworks.com> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301A4016F@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] Consensus Call regarding Diameter MobileIPv6HA-to-AAAHsupport Thread-Index: AcdmrwR7v0grC38gQFmcZgsPVPFqxwEb6imwAB9dzVAAcxRXwA== From: "Chowdhury, Kuntal" To: , , , X-OriginalArrivalTime: 23 Mar 2007 17:21:27.0101 (UTC) FILETIME=[B05CAED0:01C76D6F] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Jouni, The IDr field is one way to indicate whether the MN wants to establish an IPsec session or it wants to establish IPsec+MIP6 session. At the time of authentication i.e. IKE_AUTH this is the ONLY field available to the IKE responder to make this determination, IMHO. There may be other ways e.g. some new field in the BU that can be used to determine this. The problem I see is that if we cannot determine IPsec vs. IPsec+MIP6 at the time of IKE_AUTH, we will have to send two AAA messages i.e. one for IKE_AUTH (use MIP6 app ID: for authentication only) and second when the BU is received (use MIP6 app ID for authorization only). The downside of this is obvious, double AAA transaction each for authentication and authorization even when both use same MIP6 app ID. -Kuntal > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Wednesday, March 21, 2007 4:41 AM > To: Chowdhury, Kuntal; avi@bridgewatersystems.com; > Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: RE: [Dime] Consensus Call regarding Diameter MobileIPv6HA-to- > AAAHsupport >=20 > Hi Kuntal, >=20 > I would hesitate to 'define' any use of Idr in Dime drafts. Some > text discussing that there are multiple ways of signaling the type > of desired functionality of the IKEv2 gw, whether it is IPSec > or IPSec+MIP6. >=20 > Cheers, > Jouni >=20 > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: 20. maaliskuuta 2007 20:49 > > To: Avi Lior; Hannes Tschofenig; dime@ietf.org > > Subject: RE: [Dime] Consensus Call regarding Diameter > > MobileIPv6HA-to-AAAHsupport > > > > Hi all, > > > > I would agree with a single Diameter application for both > > authentication and authorization for MIP6 service with IKEv2/IPsec. > > > > In some scenarios, the IPsec gateway (e.g. 3GPP:PDG, > > 3GPP2:PDIF) may be collocated with the Home Agent. To support > > such scenarios, there should be a clear way to identify the > > type of service the MN is trying to access i.e. it is trying > > to only establish an IPsec session with the IPsec gateway or > > it wants to access MIPv6 service as well. The IDr field in > > the IKEv2 exchange can be used for this type of service selection. > > > > So, I would suggest that MIPv6 Diameter application is used > > when such (IPsec or IPsec+MIP6) indication is available at > > the Home Agent. > > > > Best regards, > > Kuntal > > > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, March 14, 2007 10:06 PM > > > To: Hannes Tschofenig; dime@ietf.org > > > Subject: RE: [Dime] Consensus Call regarding Diameter Mobile > > IPv6HA-to- > > > AAAHsupport > > > > > > Yes. > > > > > > Authentication -- the EAP part and Authorization should > > happen in one > > > Diameter Application. > > > > > > > > > -----Original Message----- > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > > > Sent: Wednesday, March 14, 2007 5:22 PM > > > To: dime@ietf.org > > > Subject: [Dime] Consensus Call regarding Diameter Mobile IPv6 > > > HA-to-AAAHsupport > > > > > > Hi all, > > > > > > with our work on the "Diameter Mobile IPv6 HA-to-AAAH support" > > document > > > (see > > > > > http://www.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-01.txt) > > > we defined a new Diameter application and we then decided that we > > should > > > separate the authentication and authorization interaction > > to avoid an > > > update of this specification when RFC 4072 is updated. This > > means that > > > the Diameter MIPv6 app-ID is used for the authorization > > part and the > > > Diameter EAP app-ID is used for the authentication part. Diameter > > > routing may cause authentication and authorization messages to be > > routed > > > to different servers. This caused a lengthy debate on > > security issues. > > > It seems that there is a lot of complexity associated with this > > > approach. > > > > > > I would therefore like to hear whether working group members are OK > > with > > > performing authentication and authorization as part of one Diameter > > > application. This would therefore mean that we are going to use the > > > Diameter MIPv6 app-ID for authentication and for authorization. > > > > > > Please state your opinion. > > > > > > 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 > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 24 06:59:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV3xJ-0000ml-Tg; Sat, 24 Mar 2007 06:58:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV3xI-0000fo-Mo for dime@ietf.org; Sat, 24 Mar 2007 06:58:40 -0400 Received: from smtp.stumbleupon.com ([69.36.233.8] helo=zoe.stumbleupon.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV3xH-0003Lc-9m for dime@ietf.org; Sat, 24 Mar 2007 06:58:40 -0400 Received: by zoe.stumbleupon.com (Postfix, from userid 48) id 5C93224DA6D4; Sat, 24 Mar 2007 03:57:55 -0700 (PDT) To: dime@ietf.org Date: Sat, 24 Mar 2007 03:57:55 -0700 From: himanshu.rawat@gmail.com Message-ID: X-Priority: 3 X-Mailer: PHPMailer [version 1.73] MIME-Version: 1.0 X-Spam-Score: -3.8 (---) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Dime] himanshu.rawat@gmail.com shared a video with you X-BeenThere: dime@ietf.org X-Mailman-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="===============0860898556==" Errors-To: dime-bounces@ietf.org --===============0860898556== Content-Type: multipart/alternative; boundary="b1_d79542a6ff0abdabde6cc90c20ceb3be" --b1_d79542a6ff0abdabde6cc90c20ceb3be Content-Type: text/plain; charset = "iso-8859-1" Content-Transfer-Encoding: quoted-printable StumbleVideo See what's on your channel! YouTube - NBC.COM EXCLUSIVE PREVIEW SPIDER-MAN 3 IN HD : http://video.stumbleupon.com?s=3Dsdcbs649eg&i=3Dc6a94j1euyjkwstnczoq Check out this video. It's really cool! -- rawath (himanshu.rawat@gmail.com) Learn more about StumbleVideo or Try It Now at http://video.stumbleupon.com ! *About StumbleVideo* StumbleVideo allows you to channel-surf great videos from throughout the internet based upon your interests -- creating your own Personal Video Channel. You too can discover, rate and share videos. Learn More or Try It Now! (c) StumbleUpon 2001-2007 --b1_d79542a6ff0abdabde6cc90c20ceb3be Content-Type: text/html; charset = "iso-8859-1" Content-Transfer-Encoding: quoted-printable
3D=

StumbleVideo

See what's o= n your channel

Check out this video. It's really cool!

=09 3D"Watch=

3D"Watch
YouTube - NBC.COM EXCLUSIVE PREVIEW = SPIDER-MAN 3 IN HD

- rawath (himanshu.rawat@gm= ail.com)
About StumbleVideo
StumbleVideo allows you to channel surf great videos from throughout t= he internet based upon your interests - creating your own Personal Video = Channel. You too can discover, rate and share videos.=20 Learn More or Try It Now!
© StumbleUpon 2001-2007
--b1_d79542a6ff0abdabde6cc90c20ceb3be-- --===============0860898556== 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 --===============0860898556==-- From dime-bounces@ietf.org Sat Mar 24 08:47:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV5eb-0002H1-QS; Sat, 24 Mar 2007 08:47:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HV5eb-0002Gu-A7 for dime@ietf.org; Sat, 24 Mar 2007 08:47:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HV5eZ-0000hn-QG for dime@ietf.org; Sat, 24 Mar 2007 08:47:29 -0400 Received: by nf-out-0910.google.com with SMTP id l36so2357084nfa for ; Sat, 24 Mar 2007 05:47:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=Xlq+qTlw+XQlDfKAZXdVmT+xSXQNyUXqMq5y/P/sdjAyqzzqyhAgxFMoH7g3WcAUrU1WkSeKwfLz7lBy3BV7+Ye17wc3gg+g4gt1IjsyKRZKoqrG2IIpn0SIqu2v4+cDS2pNRgtwhtWYQxJ4wrP/hZ+YP5DFiB17Vc3YaSoBaJo= 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=BdEEB8S86YL6Kvb7ZzPmFhqyHCNWtOY07iER8ufMjYKQ7sFzQPXYjCv0A9ofPgDFu/YYf9zOCioRjubxOlUi5ff1GPjFzqpSvQTvZkEDmjztLdC/ORaSw9rJ2qHlt+ISACQsefK2ODDF3l/YKZ1uk8AGK534qzi3SXl3XUnGGTY= Received: by 10.78.149.13 with SMTP id w13mr2058924hud.1174740446765; Sat, 24 Mar 2007 05:47:26 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Sat, 24 Mar 2007 05:47:26 -0700 (PDT) Message-ID: <5e2406980703240547w311fe326h4d0b780ce8f19750@mail.gmail.com> Date: Sat, 24 Mar 2007 13:47:26 +0100 From: "Julien Bournelle" To: "Chowdhury, Kuntal" 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: d6b246023072368de71562c0ab503126 Cc: dime@ietf.org Subject: [Dime] HA acting as a VPN X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 changed the thread subject. A quick comment: The problem that I can see is that we have decided to use a Application-ID because we are doing AAA for Mobile IPv6. So, we shouldn't use the same Application to handle the case where IKEv2 is used for VPN. Diameter EAP should be used in this case. Concerning IDr to know the purpose for which IKEv2 is used, are you suggesting to define a specific FQDN that would say if it is for mip6 or not ? Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 24 15:36:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVC1h-0000I2-Rj; Sat, 24 Mar 2007 15:35:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVC1g-0000Hv-Mz for dime@ietf.org; Sat, 24 Mar 2007 15:35:44 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVC1c-0007Dq-BQ for dime@ietf.org; Sat, 24 Mar 2007 15:35:44 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id C07FC90001 for ; Sat, 24 Mar 2007 14:35:36 -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 01432-18 for ; Sat, 24 Mar 2007 14:35:32 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Sat, 24 Mar 2007 14:35:32 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 24 Mar 2007 15:35:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 24 Mar 2007 15:35:31 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D71@exchtewks2.starentnetworks.com> In-Reply-To: <5e2406980703240547w311fe326h4d0b780ce8f19750@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: HA acting as a VPN Thread-Index: AcduMcYvHeWbo2bHSUu/0SWH4iwqMAAGO0fQ From: "Chowdhury, Kuntal" To: "Julien Bournelle" X-OriginalArrivalTime: 24 Mar 2007 19:35:31.0956 (UTC) FILETIME=[95E1E340:01C76E4B] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: dime@ietf.org Subject: [Dime] RE: HA acting as a VPN X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be collocated with the Home Agent function. This collocation makes sense in many deployment scenarios. So, the Home Agent/PDG/PDIF can initiate the correct Diameter application based on IDr field. If the IDr is set to "mip6" or any other string/fqdn indicating mip6, the appropriate Diameter application ID for mip6 can be used. If not, regular Diameter base or Diameter EAP application IDs should be used. -Kuntal > -----Original Message----- > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > Sent: Saturday, March 24, 2007 7:47 AM > To: Chowdhury, Kuntal > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com; > Hannes.Tschofenig@gmx.net; dime@ietf.org > Subject: HA acting as a VPN >=20 > Hi all, >=20 > I changed the thread subject. >=20 > A quick comment: >=20 > The problem that I can see is that we have decided to use > a Application-ID because we are doing AAA for Mobile IPv6. > So, we shouldn't use the same Application to handle the case > where IKEv2 is used for VPN. Diameter EAP should be used > in this case. >=20 > Concerning IDr to know the purpose for which IKEv2 is used, > are you suggesting to define a specific FQDN that would say > if it is for mip6 or not ? >=20 > Regards, >=20 > Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 26 09:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpdX-0008Ap-Rw; Mon, 26 Mar 2007 09:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVpdW-0008Ak-VZ for dime@ietf.org; Mon, 26 Mar 2007 09:53:26 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVpdV-0001rO-KT for dime@ietf.org; Mon, 26 Mar 2007 09:53:26 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1607714ugd for ; Mon, 26 Mar 2007 06:53:24 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kyzQUzXBJsTnA6zCgkUd2sIVwVUolnkJ09tNXcvjmKwTMtG0l1/985eO1n8vjfaaXexq1bEaxIHum8jqFv4pMa7w4Th7KFitcv74UiQ8cjP97NDGahQY6n3Qb6hmPHWlshhIK12rRlmOmeN1CY/60UFRTVJM0XPHa8MUse0AOYI= 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=Z5q08b66a+5X2me5no+IN3SugDEU/CwtNrXW5VV8u/419W+Ph8SaP1HPG7sU7hvhr7u2go9qAxFR10hPf3cqprM368GWPOT34B3jc4t0si8L+K4ylRVTahTH76G+5Hx10o2BCee+KLJ5qEB1V/aywuiwUtxeyB4i/KtZlcTsAn4= Received: by 10.67.98.9 with SMTP id a9mr12225185ugm.1174917204802; Mon, 26 Mar 2007 06:53:24 -0700 (PDT) Received: by 10.66.238.9 with HTTP; Mon, 26 Mar 2007 06:53:24 -0700 (PDT) Message-ID: Date: Mon, 26 Mar 2007 15:53:24 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Dime] RE: HA acting as a VPN In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D71@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5e2406980703240547w311fe326h4d0b780ce8f19750@mail.gmail.com> <7CCD07160348804497EF29E9EA5560D7024D9D71@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Kuntal that this is an issue we should handle or at least mention in the document. Not sure if we need to provide a solution in the IETF, since it seems a system-level issue, related to some deployments. What do others think? --Gerardo On 3/24/07, Chowdhury, Kuntal wrote: > Hi Julien, > > The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be collocated > with the Home Agent function. This collocation makes sense in many > deployment scenarios. > > So, the Home Agent/PDG/PDIF can initiate the correct Diameter > application based on IDr field. If the IDr is set to "mip6" or any other > string/fqdn indicating mip6, the appropriate Diameter application ID for > mip6 can be used. If not, regular Diameter base or Diameter EAP > application IDs should be used. > > -Kuntal > > > > -----Original Message----- > > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > > Sent: Saturday, March 24, 2007 7:47 AM > > To: Chowdhury, Kuntal > > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com; > > Hannes.Tschofenig@gmx.net; dime@ietf.org > > Subject: HA acting as a VPN > > > > Hi all, > > > > I changed the thread subject. > > > > A quick comment: > > > > The problem that I can see is that we have decided to use > > a Application-ID because we are doing AAA for Mobile IPv6. > > So, we shouldn't use the same Application to handle the case > > where IKEv2 is used for VPN. Diameter EAP should be used > > in this case. > > > > Concerning IDr to know the purpose for which IKEv2 is used, > > are you suggesting to define a specific FQDN that would say > > if it is for mip6 or not ? > > > > Regards, > > > > Julien > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 26 12:36:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVsB7-00084r-SG; Mon, 26 Mar 2007 12:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVsB7-00084m-0K for dime@ietf.org; Mon, 26 Mar 2007 12:36:17 -0400 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVsB5-0003sJ-Gl for dime@ietf.org; Mon, 26 Mar 2007 12:36:16 -0400 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 18:35:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: HA acting as a VPN Date: Mon, 26 Mar 2007 18:35:58 +0200 Message-ID: <59D7431DE2527D4CB0F1EFEDA5683ED301B534A0@SEHAN021MB.tcad.telia.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: HA acting as a VPN Thread-Index: AcdvrnvestkxI/2BQ6+ycGhegbTTdAAFRKEQ From: To: , X-OriginalArrivalTime: 26 Mar 2007 16:35:57.0779 (UTC) FILETIME=[D4CC7230:01C76FC4] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org I agree with Gerardo. It is worthwhile documenting this but I also think it could be better leave the solution outside IETF. Cheers, Jouni > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: 26. maaliskuuta 2007 16:53 > To: Chowdhury, Kuntal > Cc: dime@ietf.org > Subject: Re: [Dime] RE: HA acting as a VPN >=20 > I agree with Kuntal that this is an issue we should handle or=20 > at least mention in the document. Not sure if we need to=20 > provide a solution in the IETF, since it seems a system-level=20 > issue, related to some deployments. >=20 > What do others think? >=20 > --Gerardo >=20 > On 3/24/07, Chowdhury, Kuntal wrote: > > Hi Julien, > > > > The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be=20 > collocated=20 > > with the Home Agent function. This collocation makes sense in many=20 > > deployment scenarios. > > > > So, the Home Agent/PDG/PDIF can initiate the correct Diameter=20 > > application based on IDr field. If the IDr is set to "mip6" or any=20 > > other string/fqdn indicating mip6, the appropriate Diameter=20 > > application ID for > > mip6 can be used. If not, regular Diameter base or Diameter EAP=20 > > application IDs should be used. > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > > > Sent: Saturday, March 24, 2007 7:47 AM > > > To: Chowdhury, Kuntal > > > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com;=20 > > > Hannes.Tschofenig@gmx.net; dime@ietf.org > > > Subject: HA acting as a VPN > > > > > > Hi all, > > > > > > I changed the thread subject. > > > > > > A quick comment: > > > > > > The problem that I can see is that we have decided to use a=20 > > > Application-ID because we are doing AAA for Mobile IPv6. > > > So, we shouldn't use the same Application to handle the case =20 > > > where IKEv2 is used for VPN. Diameter EAP should be used in this=20 > > > case. > > > > > > Concerning IDr to know the purpose for which IKEv2 is used, are=20 > > > you suggesting to define a specific FQDN that would say if it is=20 > > > for mip6 or not ? > > > > > > Regards, > > > > > > Julien > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Mon Mar 26 13:16:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVsnf-0004Ec-Vu; Mon, 26 Mar 2007 13:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HVsnf-0004EX-KN for dime@ietf.org; Mon, 26 Mar 2007 13:16:07 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HVsne-0000vi-7G for dime@ietf.org; Mon, 26 Mar 2007 13:16:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id BE2CD90044 for ; Mon, 26 Mar 2007 12:16:02 -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 19881-02 for ; Mon, 26 Mar 2007 12:15:58 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Mon, 26 Mar 2007 12:15:58 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Mar 2007 13:15:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: HA acting as a VPN Date: Mon, 26 Mar 2007 13:15:57 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D7D@exchtewks2.starentnetworks.com> In-Reply-To: <59D7431DE2527D4CB0F1EFEDA5683ED301B534A0@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: HA acting as a VPN Thread-Index: AcdvrnvestkxI/2BQ6+ycGhegbTTdAAFRKEQAAGsEcA= From: "Chowdhury, Kuntal" To: , X-OriginalArrivalTime: 26 Mar 2007 17:15:58.0492 (UTC) FILETIME=[6BBC2DC0:01C76FCA] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Jouni, Gerardo, OK, in IETF what should be the trigger for using mip6 application ID in Diameter messages? -Kuntal > -----Original Message----- > From: jouni.korhonen@teliasonera.com > [mailto:jouni.korhonen@teliasonera.com] > Sent: Monday, March 26, 2007 11:36 AM > To: gerardo.giaretta@gmail.com; Chowdhury, Kuntal > Cc: dime@ietf.org > Subject: RE: [Dime] RE: HA acting as a VPN >=20 > I agree with Gerardo. It is worthwhile documenting this but I also > think it could be better leave the solution outside IETF. >=20 > Cheers, > Jouni >=20 > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: 26. maaliskuuta 2007 16:53 > > To: Chowdhury, Kuntal > > Cc: dime@ietf.org > > Subject: Re: [Dime] RE: HA acting as a VPN > > > > I agree with Kuntal that this is an issue we should handle or > > at least mention in the document. Not sure if we need to > > provide a solution in the IETF, since it seems a system-level > > issue, related to some deployments. > > > > What do others think? > > > > --Gerardo > > > > On 3/24/07, Chowdhury, Kuntal wrote: > > > Hi Julien, > > > > > > The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be > > collocated > > > with the Home Agent function. This collocation makes sense in many > > > deployment scenarios. > > > > > > So, the Home Agent/PDG/PDIF can initiate the correct Diameter > > > application based on IDr field. If the IDr is set to "mip6" or any > > > other string/fqdn indicating mip6, the appropriate Diameter > > > application ID for > > > mip6 can be used. If not, regular Diameter base or Diameter EAP > > > application IDs should be used. > > > > > > -Kuntal > > > > > > > > > > -----Original Message----- > > > > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > > > > Sent: Saturday, March 24, 2007 7:47 AM > > > > To: Chowdhury, Kuntal > > > > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com; > > > > Hannes.Tschofenig@gmx.net; dime@ietf.org > > > > Subject: HA acting as a VPN > > > > > > > > Hi all, > > > > > > > > I changed the thread subject. > > > > > > > > A quick comment: > > > > > > > > The problem that I can see is that we have decided to use a > > > > Application-ID because we are doing AAA for Mobile IPv6. > > > > So, we shouldn't use the same Application to handle the case > > > > where IKEv2 is used for VPN. Diameter EAP should be used in this > > > > case. > > > > > > > > Concerning IDr to know the purpose for which IKEv2 is used, are > > > > you suggesting to define a specific FQDN that would say if it is > > > > for mip6 or not ? > > > > > > > > Regards, > > > > > > > > Julien > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 27 04:30:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW74D-0005N0-53; Tue, 27 Mar 2007 04:30:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW74C-0005MX-EO for dime@ietf.org; Tue, 27 Mar 2007 04:30:08 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW74A-0002XH-Uf for dime@ietf.org; Tue, 27 Mar 2007 04:30:08 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1822664ugd for ; Tue, 27 Mar 2007 01:30:06 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qvG2bsyIHvgkG4geRi9YEg48CtZgSk3da21Eb/rhOMqdL8qzYDwRLg0fCyTrSo9lBt8zz1Fyoa/SgqEXY3icRoBv829FavtoiwGO9T/E1LysqDV1EYI/8YyHr5G6ARKKpUEvQmwkGuumlsPEMoKDwV7ys15dx7L8mDvWpVlvTsI= 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=HpfzLA/FSkhrmZhuIYnbUfzAAXNP1ewVmQy60wnHKacLfzqidhkM/F96Plk0evv7373PZCBIydkkoJgi7NDv6rQ+f5bId9kSjYeYgT50qT5iGa1TaUDfYwt6D2QBpgXYJltHZvY07QXk+yqL4o04mrdq8/UJHFqXQF6UZdG2yZ4= Received: by 10.66.252.4 with SMTP id z4mr576994ugh.1174984206016; Tue, 27 Mar 2007 01:30:06 -0700 (PDT) Received: by 10.66.238.9 with HTTP; Tue, 27 Mar 2007 01:30:05 -0700 (PDT) Message-ID: Date: Tue, 27 Mar 2007 10:30:05 +0200 From: "Gerardo Giaretta" To: "Chowdhury, Kuntal" Subject: Re: [Dime] RE: HA acting as a VPN In-Reply-To: <7CCD07160348804497EF29E9EA5560D7024D9D7D$0001@exchtewks2.starentnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <59D7431DE2527D4CB0F1EFEDA5683ED301B534A0@SEHAN021MB.tcad.telia.se> <7CCD07160348804497EF29E9EA5560D7024D9D7D$0001@exchtewks2.starentnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi Kuntal, as far as IETF is concerned, I think we should not worry about co-location of different logical entities. This is really something that other SDOs need to look at. Therefore, in IETF, the HA is a logical entity that starts the Mobile IPv6 Diameter Application when it receives an IKEv2 message from a MN. No need for anything else, since you can't make any assumption on co-location of other logical entities with the HA. I agree we should mention the issue in the document (I raised such an issue last year), but I don't think we should define a solution for that in IETF. --Gerardo On 3/26/07, Chowdhury, Kuntal wrote: > Jouni, Gerardo, > > OK, in IETF what should be the trigger for using mip6 application ID in > Diameter messages? > > -Kuntal > > > > -----Original Message----- > > From: jouni.korhonen@teliasonera.com > > [mailto:jouni.korhonen@teliasonera.com] > > Sent: Monday, March 26, 2007 11:36 AM > > To: gerardo.giaretta@gmail.com; Chowdhury, Kuntal > > Cc: dime@ietf.org > > Subject: RE: [Dime] RE: HA acting as a VPN > > > > I agree with Gerardo. It is worthwhile documenting this but I also > > think it could be better leave the solution outside IETF. > > > > Cheers, > > Jouni > > > > > -----Original Message----- > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > Sent: 26. maaliskuuta 2007 16:53 > > > To: Chowdhury, Kuntal > > > Cc: dime@ietf.org > > > Subject: Re: [Dime] RE: HA acting as a VPN > > > > > > I agree with Kuntal that this is an issue we should handle or > > > at least mention in the document. Not sure if we need to > > > provide a solution in the IETF, since it seems a system-level > > > issue, related to some deployments. > > > > > > What do others think? > > > > > > --Gerardo > > > > > > On 3/24/07, Chowdhury, Kuntal > wrote: > > > > Hi Julien, > > > > > > > > The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be > > > collocated > > > > with the Home Agent function. This collocation makes sense in many > > > > deployment scenarios. > > > > > > > > So, the Home Agent/PDG/PDIF can initiate the correct Diameter > > > > application based on IDr field. If the IDr is set to "mip6" or any > > > > other string/fqdn indicating mip6, the appropriate Diameter > > > > application ID for > > > > mip6 can be used. If not, regular Diameter base or Diameter EAP > > > > application IDs should be used. > > > > > > > > -Kuntal > > > > > > > > > > > > > -----Original Message----- > > > > > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > > > > > Sent: Saturday, March 24, 2007 7:47 AM > > > > > To: Chowdhury, Kuntal > > > > > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com; > > > > > Hannes.Tschofenig@gmx.net; dime@ietf.org > > > > > Subject: HA acting as a VPN > > > > > > > > > > Hi all, > > > > > > > > > > I changed the thread subject. > > > > > > > > > > A quick comment: > > > > > > > > > > The problem that I can see is that we have decided to use a > > > > > Application-ID because we are doing AAA for Mobile IPv6. > > > > > So, we shouldn't use the same Application to handle the case > > > > > where IKEv2 is used for VPN. Diameter EAP should be used in > this > > > > > case. > > > > > > > > > > Concerning IDr to know the purpose for which IKEv2 is used, > are > > > > > you suggesting to define a specific FQDN that would say if it > is > > > > > for mip6 or not ? > > > > > > > > > > Regards, > > > > > > > > > > Julien > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > _______________________________________________ > > > DiME mailing list > > > DiME@ietf.org > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Tue Mar 27 06:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW8X0-0003TO-5D; Tue, 27 Mar 2007 06:03:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HW8Wz-0003TJ-6Y for dime@ietf.org; Tue, 27 Mar 2007 06:03:57 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HW8Wv-0007pW-NI for dime@ietf.org; Tue, 27 Mar 2007 06:03:57 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2092C90008 for ; Tue, 27 Mar 2007 05:03:49 -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 03015-11 for ; Tue, 27 Mar 2007 05:03:44 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 27 Mar 2007 05:03:44 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Mar 2007 06:03:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Dime] RE: HA acting as a VPN Date: Tue, 27 Mar 2007 06:03:43 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D7024D9D81@exchtewks2.starentnetworks.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: HA acting as a VPN Thread-Index: AcdwSiOa/U7JH0yWSsW+xAw2vtJ8wAADJo+w From: "Chowdhury, Kuntal" To: "Gerardo Giaretta" X-OriginalArrivalTime: 27 Mar 2007 10:03:43.0798 (UTC) FILETIME=[33DDAD60:01C77057] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: dime@ietf.org X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Gerardo, Fair enough...in IETF we can simply assume that IKEv2 is the trigger for using mip6 application ID for the Home Agent. However we cannot make this a MUST requirement if we want to allow the SDOs to define their specs based on the collocation assumption. Regards, Kuntal =20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, March 27, 2007 3:30 AM > To: Chowdhury, Kuntal > Cc: jouni.korhonen@teliasonera.com; dime@ietf.org > Subject: Re: [Dime] RE: HA acting as a VPN >=20 > Hi Kuntal, >=20 > as far as IETF is concerned, I think we should not worry about > co-location of different logical entities. This is really something > that other SDOs need to look at. >=20 > Therefore, in IETF, the HA is a logical entity that starts the Mobile > IPv6 Diameter Application when it receives an IKEv2 message from a MN. > No need for anything else, since you can't make any assumption on > co-location of other logical entities with the HA. >=20 > I agree we should mention the issue in the document (I raised such an > issue last year), but I don't think we should define a solution for > that in IETF. >=20 > --Gerardo >=20 > On 3/26/07, Chowdhury, Kuntal wrote: > > Jouni, Gerardo, > > > > OK, in IETF what should be the trigger for using mip6 application ID in > > Diameter messages? > > > > -Kuntal > > > > > > > -----Original Message----- > > > From: jouni.korhonen@teliasonera.com > > > [mailto:jouni.korhonen@teliasonera.com] > > > Sent: Monday, March 26, 2007 11:36 AM > > > To: gerardo.giaretta@gmail.com; Chowdhury, Kuntal > > > Cc: dime@ietf.org > > > Subject: RE: [Dime] RE: HA acting as a VPN > > > > > > I agree with Gerardo. It is worthwhile documenting this but I also > > > think it could be better leave the solution outside IETF. > > > > > > Cheers, > > > Jouni > > > > > > > -----Original Message----- > > > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > > > Sent: 26. maaliskuuta 2007 16:53 > > > > To: Chowdhury, Kuntal > > > > Cc: dime@ietf.org > > > > Subject: Re: [Dime] RE: HA acting as a VPN > > > > > > > > I agree with Kuntal that this is an issue we should handle or > > > > at least mention in the document. Not sure if we need to > > > > provide a solution in the IETF, since it seems a system-level > > > > issue, related to some deployments. > > > > > > > > What do others think? > > > > > > > > --Gerardo > > > > > > > > On 3/24/07, Chowdhury, Kuntal > > wrote: > > > > > Hi Julien, > > > > > > > > > > The IPsec gateways in 3GPP and 3GPP2 (PDG and PDIF) may be > > > > collocated > > > > > with the Home Agent function. This collocation makes sense in many > > > > > deployment scenarios. > > > > > > > > > > So, the Home Agent/PDG/PDIF can initiate the correct Diameter > > > > > application based on IDr field. If the IDr is set to "mip6" or any > > > > > other string/fqdn indicating mip6, the appropriate Diameter > > > > > application ID for > > > > > mip6 can be used. If not, regular Diameter base or Diameter EAP > > > > > application IDs should be used. > > > > > > > > > > -Kuntal > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Julien Bournelle [mailto:julien.bournelle@gmail.com] > > > > > > Sent: Saturday, March 24, 2007 7:47 AM > > > > > > To: Chowdhury, Kuntal > > > > > > Cc: jouni.korhonen@teliasonera.com; avi@bridgewatersystems.com; > > > > > > Hannes.Tschofenig@gmx.net; dime@ietf.org > > > > > > Subject: HA acting as a VPN > > > > > > > > > > > > Hi all, > > > > > > > > > > > > I changed the thread subject. > > > > > > > > > > > > A quick comment: > > > > > > > > > > > > The problem that I can see is that we have decided to use a > > > > > > Application-ID because we are doing AAA for Mobile IPv6. > > > > > > So, we shouldn't use the same Application to handle the case > > > > > > where IKEv2 is used for VPN. Diameter EAP should be used in > > this > > > > > > case. > > > > > > > > > > > > Concerning IDr to know the purpose for which IKEv2 is used, > > are > > > > > > you suggesting to define a specific FQDN that would say if it > > is > > > > > > for mip6 or not ? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Julien > > > > > > > > > > _______________________________________________ > > > > > DiME mailing list > > > > > DiME@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > > > > _______________________________________________ > > > > DiME mailing list > > > > DiME@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > > "This email message and any attachments are confidential information of > Starent Networks, Corp. The information transmitted may not be used to > create or change any contractual obligations of Starent Networks, Corp. > Any review, retransmission, dissemination or other use of, or taking of > any action in reliance upon this e-mail and its attachments by persons or > entities other than the intended recipient is prohibited. If you are not > the intended recipient, please notify the sender immediately -- by > replying to this message or by sending an email to > postmaster@starentnetworks.com -- and destroy all copies of this message > and any attachments without reading or disclosing their contents. Thank > you." > > _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime From dime-bounces@ietf.org Sat Mar 31 08:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXcPB-0000BK-As; Sat, 31 Mar 2007 08:10:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXcPB-0000BF-2T for dime@ietf.org; Sat, 31 Mar 2007 08:10:01 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXcP9-000491-Ol for dime@ietf.org; Sat, 31 Mar 2007 08:10:01 -0400 Received: by ug-out-1314.google.com with SMTP id 72so1012041ugd for ; Sat, 31 Mar 2007 05:09:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=tjGHp3Nnktk4zhdHLko9kcwgpiVsXwBFa7IY6IoN7W8G1ZkcuUJTezO1gOTJZrp9eXoWRuM0oHIq9mzYWTFoJtJvcnpB/01jw8TOVzyL9xFyEcyY3eEnGA2VyVe4VshWLofWZzE7pYd3qENRa7V7DRaBY0oOr23/+fn9i+wkIFM= 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=h7tICBHyBWkkfceFC7wNnKyjDZNow4v3LuETJgM91jhFUEQMkz/1uXBpj7V+vr1SEH3ivIB8SoX/cqJwG/b1wkbbX81QtyuhfHureNScGLv1mhx9N1bN69ETe3Zt21FApg+3DsbTjKRl8asSOvg90V+Rv15PAa/cyU1fE0zKrus= Received: by 10.78.201.2 with SMTP id y2mr1193176huf.1175342997781; Sat, 31 Mar 2007 05:09:57 -0700 (PDT) Received: by 10.78.168.16 with HTTP; Sat, 31 Mar 2007 05:09:57 -0700 (PDT) Message-ID: <5e2406980703310509s3da8a81cl784bcbeed104d814@mail.gmail.com> Date: Sat, 31 Mar 2007 14:09:57 +0200 From: "Julien Bournelle" To: dime@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Hannes Tschofenig Subject: [Dime] HA-to-AAAH draft/support of RFC 4285 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dime-bounces@ietf.org Hi all, as discussed during the DiME WG meeting, we have to support the RFC4285 in our Diameter Application for mip6. Let me reexplain briefly the situation: MN ----------- HA/AAAclient ----------------AAA server Our application defines the protocol between the AAAclient located in the HA and the AAA server. Between, the MN and the HA, we use: A/ either IKEv2 with EAP to setup IPsec SAs (to protect mip6 signalling). B/ or RFC 4285 aka Mobile IPv6 Authentication Option (could be compared to what is used in mip4). In A/, EAP is used for authentication, our Diameter Application will carry EAP packets and will deliver specific mip6 AVPs. At the end of the AAA process, IPsec SAs are setup and the MN can send its mip6 Binding Update. In B/, the MN has a pre-shared key with the AAA server. It sends its mip6 Binding Update signed using this pre-shared key to the HA. Our Diameter Application is then used to perform Authentication by the AAA server (owner of the pre-shared key). So, to sum up, we have two different MN-HA interaction (IKEv2-EAP and RFC4285) and one Diameter Application between HA and AAA. To solve this, we have two options in our Application: Option 1: we define 2 different commands: one command to deal with EAP and one command to deal with RFC 4285. Option 2: we define one command and one generic Authentication AVP. I'd like to hear your opinion on this. My personal feeling is that I would prefer Option 1. The reason is that I think it's cleaner for the server to know from the command-code the associated authentication method. More especially when we have EAP type authentication. Regards, Julien _______________________________________________ DiME mailing list DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime