From owner-aaa-wg@merit.edu Thu Jun 3 02:10:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08004 for ; Thu, 3 Jun 2004 02:10:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 550D491292; Thu, 3 Jun 2004 02:10:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2060791293; Thu, 3 Jun 2004 02:10:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16B1B91292 for ; Thu, 3 Jun 2004 02:10:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 00A4859916; Thu, 3 Jun 2004 02:10:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id EBD4559911 for ; Thu, 3 Jun 2004 02:10:11 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i536A6o24953 for ; Thu, 3 Jun 2004 09:10:06 +0300 (EET DST) X-Scanned: Thu, 3 Jun 2004 09:09:27 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5369RH0026362 for ; Thu, 3 Jun 2004 09:09:27 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00G0G6b3; Thu, 03 Jun 2004 09:09:25 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5369PH03283 for ; Thu, 3 Jun 2004 09:09:25 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 3 Jun 2004 09:09:24 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Date: Thu, 3 Jun 2004 09:09:24 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> Thread-Topic: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Thread-Index: AcRJMVGegLzwvtIfTBiDzkSCtUr7Ng== From: To: X-OriginalArrivalTime: 03 Jun 2004 06:09:24.0758 (UTC) FILETIME=[51C92B60:01C44931] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I believe this version handles all currently open issues, and if the chairs agree, I'd suggest proceeding to IESG=20 review and IETF last call. Best regards, Pasi --------------------------------------- From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-eap-06.txt Date: Wed, 02 Jun 2004 09:50:36 -0400 A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Authentication, Authorization and = Accounting Working Group of the IETF. Title : Diameter Extensible Authentication Protocol (EAP)=20 Application Author(s) : P. Eronen, et al. Filename : draft-ietf-aaa-eap-06.txt Pages : 37 Date : 2004-6-1 =09 The Extensible Authentication Protocol (EAP) provides a standard mechanism for support of various authentication methods. This document defines the Command-Codes and AVPs necessary to carry EAP packets between a Network Access Server (NAS) and a back-end authentication server A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-06.txt From owner-aaa-wg@merit.edu Thu Jun 3 02:58:53 2004 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13925 for ; Thu, 3 Jun 2004 02:58:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AF4A91295; Thu, 3 Jun 2004 02:56:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 643AC9129F; Thu, 3 Jun 2004 02:56:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62E2391295 for ; Thu, 3 Jun 2004 02:56:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4BCD559939; Thu, 3 Jun 2004 02:56:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B2EBF5991F for ; Thu, 3 Jun 2004 02:56:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i536vlq13284; Wed, 2 Jun 2004 23:57:47 -0700 Date: Wed, 2 Jun 2004 23:57:47 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Some comments: "A Diameter client MUST NOT send a Diameter-EAP-Request encapsulating an EAP Request packet, and a Diameter server receiving such packet MUST respond with a failure Result-Code.." Two periods at the end of the sentence. This document does not define the ABNF for use with the ASR, ASA, RAR, RAA, STR, or STA commands. This is probably very similar to the ABNFs used with NASREQ, in which case a reference to [NASREQ] may suffice. I believe that this application shares many of the same RADIUS/Diameter translation considerations as NASREQ Section 9. It should probably explicitly state this, particularly as regards the RADIUS Dynamic Authorization considerations described in Sections 9.1.1 and 9.2.1 of NASREQ. From owner-aaa-wg@merit.edu Thu Jun 3 03:40:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16579 for ; Thu, 3 Jun 2004 03:40:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D39D91296; Thu, 3 Jun 2004 03:39:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 688EC91299; Thu, 3 Jun 2004 03:39:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B9CB91296 for ; Thu, 3 Jun 2004 03:39:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA0BC59934; Thu, 3 Jun 2004 03:39:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3789A59953 for ; Thu, 3 Jun 2004 03:39:54 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CC87A89883; Thu, 3 Jun 2004 10:39:36 +0300 (EEST) Message-ID: <40BED4CC.3090904@kolumbus.fi> Date: Thu, 03 Jun 2004 10:35:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt References: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > This document does not define the ABNF for use with the ASR, ASA, RAR, > RAA, STR, or STA commands. This is probably very similar to the ABNFs > used with NASREQ, in which case a reference to [NASREQ] may suffice. Yes. The document does not even mention these commands currently. Perhaps a new subsection somewhere under current Section 3. Also, accounting request ABNF needs to be defined, and it has one difference to the NASREQ ABNF, the Accounting-EAP-Auth-Method AVP. How about this: 3.3 Base and NASREQ Commands Where the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used for authorization in conjunction with EAP (see Section 2.3.3), the Auth-Application-Id AVP MUST be set to 1 (NASREQ), and the rules and command ABNF defined in [Diameter NASREQ] MUST be followed. Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR) and Abort-Session-Answer (ASA) are used in conjunction with EAP, the Auth-Application-Id AVP MUST be set to (EAP). Nevertheless, the same rules and command ABNF defined in [Diameter NASREQ] MUST be followed even in this case. 3.4. Accounting Commands The Accounting-Request (ACR) message [Base], is sent by the NAS, to report it's session information to a target server downstream. One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present. If the Vendor-Specific-Application-Id grouped AVP is present, it must have an Acct-Application-Id inside. [NOTE: This text is copied from NASREQ. But I don't understand how the NASREQ or EAP application can have a VSAID.] The AVPs listed in the Base MUST be assumed to be present as approriate. NASREQ and EAP specific accounting AVPs, SHOULD be present as described in [Diameter NASREQ] and the rest of this specification. Message Format ::= < Diameter Header: 271, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Accounting-Session-Id ] [ Acct-Multi-Session-Id ] [ Origin-State-Id ] [ Destination-Host ] [ Event-Timestamp ] [ Acct-Delay-Time ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port ] [ NAS-Port-Id ] [ NAS-Port-Type ] * [ Class ] [ Service-Type ] [ Termination-Cause ] [ Accounting-Input-Octets ] [ Accounting-Input-Packets ] [ Accounting-Output-Octets ] [ Accounting-Output-Packets ] [ Acct-Authentic ] [ Accounting-Auth-Method ] [ Acct-Link-Count ] [ Acct-Session-Time ] [ Acct-Tunnel-Connection ] [ Acct-Tunnel-Packets-Lost ] [ Callback-Id ] [ Callback-Number ] [ Called-Station-Id ] [ Calling-Station-Id ] * [ Connection-Info ] [ Originating-Line-Info ] [ Authorization-Lifetime ] [ Session-Timeout ] [ Idle-Timeout ] [ Port-Limit ] [ Accounting-Realtime-Required ] [ Acct-Interim-Interval ] * [ Filter-Id ] * [ NAS-Filter-Rule ] [ Framed-AppleTalk-Link ] [ Framed-AppleTalk-Network ] [ Framed-AppleTalk-Zone ] [ Framed-Compression ] [ Framed-Interface-Id ] [ Framed-IP-Address ] [ Framed-IP-Netmask ] * [ Framed-IPv6-Prefix ] [ Framed-IPv6-Pool ] * [ Framed-IPv6-Route ] [ Framed-IPX-Network ] [ Framed-MTU ] [ Framed-Pool ] [ Framed-Protocol ] * [ Framed-Route ] [ Framed-Routing ] * [ Login-IP-Host ] * [ Login-IPv6-Host ] [ Login-LAT-Group ] [ Login-LAT-Node ] [ Login-LAT-Port ] [ Login-LAT-Service ] [ Login-Service ] [ Login-TCP-Port ] * [ Accounting-EAP-Auth-Method ] * [ Tunneling ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] The Accounting-Answer (ACA) message [Base], is used to acknowledge an Accounting-Request command. The Accounting-Answer command contains the same Session-Id as the Request. If the Accounting- Request was protected by end-to-end security, then the corresponding ACA message MUST be protected by end-to-end security. Only the target Diameter Server, or home Diameter Server, SHOULD respond with the Accounting-Answer command. One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs MUST be present, as was in the request. The AVPs listed in the Base MUST be assumed to be present as approriate. NASREQ and EAP specific accounting AVPs, SHOULD be present as described in [Diameter NASREQ] and the rest of this specification. Message Format ::= < Diameter Header: 271, PXY > < Session-Id > { Result-Code } { Origin-Host } { Origin-Realm } { Accounting-Record-Type } { Accounting-Record-Number } [ Acct-Application-Id ] [ Vendor-Specific-Application-Id ] [ User-Name ] [ Accounting-Sub-Session-Id ] [ Accounting-Session-Id ] [ Acct-Multi-Session-Id ] [ Event-Timestamp ] [ Error-Reporting-Host ] [ Origin-State-Id ] [ NAS-Identifier ] [ NAS-IP-Address ] [ NAS-IPv6-Address ] [ NAS-Port ] [ NAS-Port-Id ] [ NAS-Port-Type ] [ Service-Type ] [ Termination-Cause ] [ Accounting-Realtime-Required ] [ Acct-Interim-Interval ] * [ Class ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] > I believe that this application shares many of the same RADIUS/Diameter > translation considerations as NASREQ Section 9. It should probably > explicitly state this, particularly as regards the RADIUS > Dynamic Authorization considerations described in Sections 9.1.1 and > 9.2.1 of NASREQ. Perhaps this is sufficient: Section 9 of [NASREQ] describes basic guidelines that translation agents may follow when translating between RADIUS and Diameter protocols. This section gives additional guidelines for the Diameter EAP application. => Section 9 of [NASREQ] describes basic guidelines for translation agents that translate between RADIUS and Diameter protocols. These guidelines SHOULD be followed for EAP application as well, with some additional guidelines given in this section. --Jari From owner-aaa-wg@merit.edu Thu Jun 3 10:25:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15439 for ; Thu, 3 Jun 2004 10:25:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0311591238; Thu, 3 Jun 2004 10:25:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCC569129E; Thu, 3 Jun 2004 10:25:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8824191238 for ; Thu, 3 Jun 2004 10:25:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71D4159A80; Thu, 3 Jun 2004 10:25:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from floyd.utc.fr (floyd.utc.fr [195.83.155.17]) by segue.merit.edu (Postfix) with ESMTP id D504E59AD5 for ; Thu, 3 Jun 2004 10:25:29 -0400 (EDT) Received: from gamma.utc.fr (gamma.utc.fr [195.83.155.32]) by floyd.utc.fr (Postfix) with ESMTP id CEA343C9B1 for ; Thu, 3 Jun 2004 16:25:28 +0200 (CEST) Received: from gamma.utc.fr (localhost.localdomain [127.0.0.1]) by gamma-interne.utc.fr (Postfix) with ESMTP id A133C3BE2C for ; Thu, 3 Jun 2004 16:25:28 +0200 (CEST) Received: from vega.utc.fr (arcturus.utc.fr [195.83.155.19]) by gamma.utc.fr (Postfix) with ESMTP id 537BD3BE29 for ; Thu, 3 Jun 2004 16:25:28 +0200 (CEST) Received: from tremplin-utc.net (pcyh-hp.gi.utc [172.17.5.119]) by vega.utc.fr (Postfix) with ESMTP id 1DA6028EAD for ; Thu, 3 Jun 2004 16:25:28 +0200 (CEST) Message-ID: <40BF3479.3020507@tremplin-utc.net> Date: Thu, 03 Jun 2004 16:23:53 +0200 From: Yoann Hinard User-Agent: Mozilla Thunderbird 0.5 (X11/20040229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [AAA -WG] Diameter and multicast accounting Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checked-By: gamma.utc.fr X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on gamma.utc.fr X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hello, As written in the RFC3588, diameter base protocol is, since its first versions , intented to work with new generation technologies (IP mobility, Roaming,...). I would like to know if multicast authentication and accounting is not mentionned because it is too obvious that diameter framework will support it or because something else is needed to make it work. I would enjoy every comment which could help me to know how to do multicast accounting on diameter framework. Yoann Hinard Master Thesis Student University of Technology Compiègne France From owner-aaa-wg@merit.edu Thu Jun 3 10:47:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17146 for ; Thu, 3 Jun 2004 10:47:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3F6F9129E; Thu, 3 Jun 2004 10:47:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF446912A0; Thu, 3 Jun 2004 10:47:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9EAE9129E for ; Thu, 3 Jun 2004 10:47:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B060459ACD; Thu, 3 Jun 2004 10:47:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 356E859AC6 for ; Thu, 3 Jun 2004 10:47:38 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i53ElYs08814; Thu, 3 Jun 2004 07:47:34 -0700 Date: Thu, 3 Jun 2004 07:47:34 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <40BED4CC.3090904@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> <40BED4CC.3090904@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), > Session-Termination-Request (STR), Session-Termination-Answer (STA), > Abort-Session-Request (ASR) and Abort-Session-Answer (ASA) > are used in conjunction with EAP, the Auth-Application-Id > AVP MUST be set to (EAP). Nevertheless, > the same rules and command ABNF defined in [Diameter NASREQ] > MUST be followed even in this case. Presumably the EAP application will add a mandatory EAP payload AVP to the ABNF, no? > 3.4. Accounting Commands This looks ok. > Additional guidelines for use of EAP. I think this is sufficient. From owner-aaa-wg@merit.edu Thu Jun 3 11:00:38 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17927 for ; Thu, 3 Jun 2004 11:00:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82A95912A1; Thu, 3 Jun 2004 11:00:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 075A8912A2; Thu, 3 Jun 2004 11:00:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82989912A1 for ; Thu, 3 Jun 2004 11:00:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CCD7599B3; Thu, 3 Jun 2004 11:00:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 74CD059AB6 for ; Thu, 3 Jun 2004 11:00:09 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CBF238988A; Thu, 3 Jun 2004 18:00:02 +0300 (EEST) Message-ID: <40BF3C06.3060105@kolumbus.fi> Date: Thu, 03 Jun 2004 17:56:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt References: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> <40BED4CC.3090904@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >> Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), >> Session-Termination-Request (STR), Session-Termination-Answer (STA), >> Abort-Session-Request (ASR) and Abort-Session-Answer (ASA) >> are used in conjunction with EAP, the Auth-Application-Id >> AVP MUST be set to (EAP). Nevertheless, >> the same rules and command ABNF defined in [Diameter NASREQ] >> MUST be followed even in this case. > > Presumably the EAP application will add a mandatory EAP payload AVP to the > ABNF, no? I don't know, but lets see: - STR, STA: I think we just kill the session, and no EAP needs to be run. Hence no EAP-Payload AVP either. - ASR, ASA: As above. - RAR, RAA: This is trickier. The purpose of the reauthentication may be re-authentication. If so, in theory we could carry an EAP Identity Request (or some other first server generated message) in the RAR, and its response in the RAA. But I think Diameter base intended the actual auth/authz process to start in the subsequent application specific command. In the case of EAP, this would be DER/DEA. --Jari From owner-aaa-wg@merit.edu Thu Jun 3 11:05:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18390 for ; Thu, 3 Jun 2004 11:05:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0A96912A2; Thu, 3 Jun 2004 11:05:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65E71912A3; Thu, 3 Jun 2004 11:05:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AF48912A2 for ; Thu, 3 Jun 2004 11:05:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 071CD59A8D; Thu, 3 Jun 2004 11:05:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 8B5EF59AC0 for ; Thu, 3 Jun 2004 11:05:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i53F7UL10000 for ; Thu, 3 Jun 2004 08:07:30 -0700 Date: Thu, 3 Jun 2004 08:07:29 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Missing ABNFs in Diameter MIP-18 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Looking over the Diameter MIP document, it appears to have the same problem as EAP-06, in that it does not define the ABNF for use with the ASR, ASA, RAR, RAA, STR, or STA commands. However, in this case I don't think that a reference to NASREQ suffices. Since we don't have a RADIUS MIP application defined, I don't think that this document needs a RADIUS/Diameter translation section, though. From owner-aaa-wg@merit.edu Thu Jun 3 11:10:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18890 for ; Thu, 3 Jun 2004 11:10:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BED85912A3; Thu, 3 Jun 2004 11:10:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C24A912A5; Thu, 3 Jun 2004 11:10:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96C78912A3 for ; Thu, 3 Jun 2004 11:10:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 814CC59AD0; Thu, 3 Jun 2004 11:10:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 02ABA59AC6 for ; Thu, 3 Jun 2004 11:10:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i53FC0R10227; Thu, 3 Jun 2004 08:12:00 -0700 Date: Thu, 3 Jun 2004 08:12:00 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <40BF3C06.3060105@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122427@esebe023.ntc.nokia.com> <40BED4CC.3090904@kolumbus.fi> <40BF3C06.3060105@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > - RAR, RAA: This is trickier. The purpose of the > reauthentication may be re-authentication. If so, > in theory we could carry an EAP Identity Request > (or some other first server generated message) in > the RAR, and its response in the RAA. But I think > Diameter base intended the actual auth/authz process > to start in the subsequent application specific > command. In the case of EAP, this would be DER/DEA. Yes, that's what we decided. So I guess that the RAR/RAA won't contain any EAP AVPs and a reference to NASREQ will suffice. Thanks. From owner-aaa-wg@merit.edu Thu Jun 3 16:47:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14552 for ; Thu, 3 Jun 2004 16:47:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50D66912A8; Thu, 3 Jun 2004 16:47:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E332912A9; Thu, 3 Jun 2004 16:47:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC024912A8 for ; Thu, 3 Jun 2004 16:47:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFC1459BFF; Thu, 3 Jun 2004 16:47:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by segue.merit.edu (Postfix) with ESMTP id 4EC0D59BEA for ; Thu, 3 Jun 2004 16:47:43 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 03 Jun 2004 22:56:41 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i53KlV1P002992 for ; Thu, 3 Jun 2004 22:47:32 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Jun 2004 22:47:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C449AB.FD436025" Subject: RE: [AAA-WG]: DCCA Draft 05: CC-Request-Type Date: Thu, 3 Jun 2004 22:47:31 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: CC-Request-Type Thread-Index: AcRDIsqffMKDk64CSwCwppWqtQ9FMQGiEeyw From: "Mark Grayson (mgrayson)" To: X-OriginalArrivalTime: 03 Jun 2004 20:47:31.0365 (UTC) FILETIME=[FD736550:01C449AB] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C449AB.FD436025 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just trying to see where DCCA specifies how/when to populate the CC-Request-Type AVP in the CCA. I assume that it is meant to be identical to the value included in the CCR, but there doesn't seem to be any text which says this. I can see in section 8.3 that we have a MUST for its inclusion in CCR, but nothing about CCA.=20 =20 Have I missed something? =20 Cheers, Mark ------_=_NextPart_001_01C449AB.FD436025 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Just=20 trying to see where DCCA specifies how/when to populate the = CC-Request-Type=20 AVP in the CCA. I assume that it is meant to be identical to the = value=20 included in the CCR, but there doesn't seem to be any text which says = this. I=20 can see in section 8.3 that we have a MUST for its inclusion in CCR, but = nothing=20 about CCA.
 
Have I=20 missed something?
 
Cheers,
Mark
------_=_NextPart_001_01C449AB.FD436025-- From owner-aaa-wg@merit.edu Fri Jun 4 09:16:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07119 for ; Fri, 4 Jun 2004 09:16:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B4DE91201; Fri, 4 Jun 2004 09:15:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F1D091247; Fri, 4 Jun 2004 09:15:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2D9691201 for ; Fri, 4 Jun 2004 09:15:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57B1B59B87; Fri, 4 Jun 2004 09:15:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 3DD7359C1D for ; Fri, 4 Jun 2004 09:15:37 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i54DFRe02203; Fri, 4 Jun 2004 09:15:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jun 2004 09:15:28 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6BD8@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: aaa-wg@merit.edu Cc: "'Harri.Hakala@ericsson.com'" , "'Leena.Mattila@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "'marco.stura@nokia.com'" , "'John.Loughney@nokia.com'" Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Fri, 4 Jun 2004 09:15:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A35.F8B8788D" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44A35.F8B8788D Content-Type: text/plain Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44A35.F8B8788D Content-Type: text/html Content-Transfer-Encoding: quoted-printable DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support = of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and = client MAY optionally support
   a tariff change mechanism. The Diameter = credit-control server may
   include a Tariff-Time-Change AVP in the = answer message.
"

On the other hand and under the same section, it = mandates the DCC client which does not support this functionality to = terminate the DCC session if it receives a CCA with Tariff-Time-Change = AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff = change mechanism, and it
   receives a CCA message carrying the = Tariff-Time-Change AVP, it MUST
   terminate the credit control session, = giving a reason of
   DIAMETER_BAD_ANSWER in the = Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server = supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user = which home Diameter CC server supports Tariff-Time-Change mechanism = while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44A35.F8B8788D-- From owner-aaa-wg@merit.edu Fri Jun 4 09:48:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08856 for ; Fri, 4 Jun 2004 09:48:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 40F3C91247; Fri, 4 Jun 2004 09:47:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E81B912B8; Fri, 4 Jun 2004 09:47:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CC4691247 for ; Fri, 4 Jun 2004 09:47:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4F76359C71; Fri, 4 Jun 2004 09:47:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross.ericsson.se (albatross.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id 87A2059C5D for ; Fri, 4 Jun 2004 09:47:52 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i54DlpWR001003 for ; Fri, 4 Jun 2004 15:47:51 +0200 (MEST) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Jun 2004 15:47:51 +0200 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 4 Jun 2004 15:47:51 +0200 Message-ID: <4E4C7D1B13A5C840B0BF2A9B80FEC18209773314@esealnt913.al.sw.ericsson.se> From: "Peter Zackrisson (KA/EAB)" To: "'Ahmad Muhanna'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Fri, 4 Jun 2004 15:47:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A3A.848EAE4E" X-OriginalArrivalTime: 04 Jun 2004 13:47:51.0286 (UTC) FILETIME=[875E0160:01C44A3A] Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44A3A.848EAE4E Content-Type: text/plain; charset="iso-8859-1" I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44A3A.848EAE4E Content-Type: text/html; charset="iso-8859-1" DCCA Draft 05: Tariff-Time-Change
I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44A3A.848EAE4E-- From owner-aaa-wg@merit.edu Fri Jun 4 09:59:43 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10071 for ; Fri, 4 Jun 2004 09:59:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58FC4912B8; Fri, 4 Jun 2004 09:59:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 265F6912B9; Fri, 4 Jun 2004 09:59:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9C1D912B8 for ; Fri, 4 Jun 2004 09:59:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6E9059D22; Fri, 4 Jun 2004 09:59:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 406B859C5D for ; Fri, 4 Jun 2004 09:59:27 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i54DxMe11836; Fri, 4 Jun 2004 09:59:23 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Jun 2004 09:59:23 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6BDA@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Peter Zackrisson (KA/EAB)'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Fri, 4 Jun 2004 09:59:11 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A3C.1CBC2728" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44A3C.1CBC2728 Content-Type: text/plain Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44A3C.1CBC2728 Content-Type: text/html Message
Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44A3C.1CBC2728-- From owner-aaa-wg@merit.edu Mon Jun 7 10:44:49 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21238 for ; Mon, 7 Jun 2004 10:44:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EBCF91260; Mon, 7 Jun 2004 10:44:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A3B591261; Mon, 7 Jun 2004 10:44:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A0D591260 for ; Mon, 7 Jun 2004 10:44:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22E00595DB; Mon, 7 Jun 2004 10:44:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smail.alcatel.fr (smail.alcatel.fr [62.23.212.165]) by segue.merit.edu (Postfix) with ESMTP id 23388595C0 for ; Mon, 7 Jun 2004 10:44:34 -0400 (EDT) Received: from bemail03.netfr.alcatel.fr (bemail03.netfr.alcatel.fr [155.132.251.37]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id i57EiVF3005935 for ; Mon, 7 Jun 2004 16:44:31 +0200 Received: from [138.203.209.48] ([138.203.209.48]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004060716442921:3989 ; Mon, 7 Jun 2004 16:44:29 +0200 Message-ID: <40C47F4B.5030001@alcatel.be> Date: Mon, 07 Jun 2004 16:44:27 +0200 From: johan.rh.hermans@alcatel.be Organization: Alcatel Belgium User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter & Resource Management X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/07/2004 16:44:29, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 06/07/2004 16:44:31, Serialize complete at 06/07/2004 16:44:31 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I know of the old draft by Pat Calhoun , but that was 3 years ago. Does anyone know of more work in this area ? And what about the Diameter SNMP-MIB's ? I'm not necessarily interested in the possiblity of retrieving the list of sessions and to query the state of an exiting session (yes, I know the drawbacks when there are hundreds of thousands of sessions in a server). And I also know that you might so the same thing with SNMP. I'm more interested in a application that can query a server, to retrieve the list of realms, peers, supported applications, various statistics, etc ... and yes, also sessions. This application might recursively query the peers that are discovered (traceroute style, using Destination-Realm and Destination-Host), and can be be used to map out the entire network. But it would use a Diameter application instead of SNMP. The purpose would be to map the entire network, and to collect various statistics on the various hosts (number of packets in and out, list of connections, etc ...) Note : this has absolutely nothing to do with my employer, I was just doodling a bit on the public transport on the way home last night :-) I've already got the basic layout of the command-codes. -- Jo Hermans - ready to be flamed From owner-aaa-wg@merit.edu Mon Jun 7 11:00:32 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22062 for ; Mon, 7 Jun 2004 11:00:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 20E6691261; Mon, 7 Jun 2004 11:00:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A49D991263; Mon, 7 Jun 2004 11:00:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E98591261 for ; Mon, 7 Jun 2004 11:00:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB92959144; Mon, 7 Jun 2004 11:00:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 77F4359437 for ; Mon, 7 Jun 2004 11:00:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i57F0DB21224; Mon, 7 Jun 2004 08:00:13 -0700 Date: Mon, 7 Jun 2004 08:00:13 -0700 (PDT) From: Bernard Aboba To: johan.rh.hermans@alcatel.be Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter & Resource Management In-Reply-To: <40C47F4B.5030001@alcatel.be> Message-ID: References: <40C47F4B.5030001@alcatel.be> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > but that was 3 years ago. Does anyone know of more work in this area ? > And what about the Diameter SNMP-MIB's ? Work on the Diameter SNMP MIBs stopped quite a while back. Are you interested in volunteering to take that work up again? From owner-aaa-wg@merit.edu Tue Jun 8 08:51:53 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23708 for ; Tue, 8 Jun 2004 08:51:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C61F591234; Tue, 8 Jun 2004 08:51:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93D0C91280; Tue, 8 Jun 2004 08:51:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3690D91234 for ; Tue, 8 Jun 2004 08:51:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E38B59779; Tue, 8 Jun 2004 08:51:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id A4EE75973F for ; Tue, 8 Jun 2004 08:51:37 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i58CpRU21053; Tue, 8 Jun 2004 08:51:27 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jun 2004 08:51:27 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6BFC@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Peter Zackrisson (KA/EAB)'" , aaa-wg@merit.edu Cc: "'Harri.Hakala@ericsson.com'" , "'Leena.Mattila@ericsson.com'" , "'juha-pekka.koskinen@nokia.com'" , "'marco.stura@nokia.com'" , "'John.Loughney@nokia.com'" , "Ahmad Muhanna" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Tue, 8 Jun 2004 08:51:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D57.49EA51B7" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44D57.49EA51B7 Content-Type: text/plain So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44D57.49EA51B7 Content-Type: text/html Message
So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44D57.49EA51B7-- From owner-aaa-wg@merit.edu Tue Jun 8 09:25:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25571 for ; Tue, 8 Jun 2004 09:25:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 619EB9122F; Tue, 8 Jun 2004 09:25:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3347791285; Tue, 8 Jun 2004 09:25:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 771CD9122F for ; Tue, 8 Jun 2004 09:25:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61640597D1; Tue, 8 Jun 2004 09:25:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by segue.merit.edu (Postfix) with ESMTP id EFBB059808 for ; Tue, 8 Jun 2004 09:25:13 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 08 Jun 2004 15:35:47 +0200 X-BrightmailFiltered: true Received: from xbe-ams-312.cisco.com (xbe-ams-312.cisco.com [144.254.228.202]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i58DP91P026069; Tue, 8 Jun 2004 15:25:09 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by xbe-ams-312.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Jun 2004 15:25:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6521.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D5C.046AD795" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Tue, 8 Jun 2004 15:25:07 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thread-Index: AcRNV+e6GQjGR+XLQTSYlmbkANxHSgAA++MQ From: "Mark Grayson (mgrayson)" To: "Ahmad Muhanna" , "Peter Zackrisson (KA/EAB)" , Cc: , , , , X-OriginalArrivalTime: 08 Jun 2004 13:25:08.0922 (UTC) FILETIME=[04FCC1A0:01C44D5C] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44D5C.046AD795 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client. =20 Cheers, Mark _____ =20 From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Ahmad Muhanna Sent: 08 June 2004 08:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'; Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter.=20 Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards,=20 Ahmad=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change =09 =09 Thanks Peter, =20 Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. =20 Thanks again. Regards,=20 Ahmad=20 -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20 Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change =09 =09 I think the DCC specification is correct regarding the tariff change mechanism. =20 If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). =20 / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change =09 =09 Hi all,=20 According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.=20 "=20 The Diameter credit-control server and client MAY optionally support=20 a tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message.=20 "=20 On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads:=20 "=20 If a client does not support the tariff change mechanism, and it=20 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST=20 terminate the credit control session, giving a reason of=20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.=20 "=20 The problem I see is the following:=20 There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.=20 This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here?=20 Your thoughts please.=20 Thanks,=20 Ahmad=20 ------_=_NextPart_001_01C44D5C.046AD795 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
well at least there seems to be some = inconsistency with=20 optional MSCC which then has support explicitly indicated by the=20 client.
 
Cheers,
Mark

From: owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu] On Behalf Of Ahmad=20 Muhanna
Sent: 08 June 2004 08:51
To: 'Peter = Zackrisson=20 (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com';=20 'Leena.Mattila@ericsson.com'; 'juha-pekka.koskinen@nokia.com';=20 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'; Ahmad=20 Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

So far=20 the only comment received is from Peter.
Does=20 this mean that every one agrees that this is a problem that needs to be=20 fixed.
If so,=20 what do you think the solution should be?

Regards, =
Ahmad

-----Original Message-----
From: = Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 = AM
To:=20 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is=20 it fair to say that your argument is based on the assumption that = all DCC=20 Servers are always aware of all DCC clients capabilities = with=20 respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: = Peter=20 Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] =
Sent:=20 Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: = DCCA=20 Draft 05: Tariff-Time-Change

I=20 think the DCC specification is correct regarding the tariff change = mechanism.
 
If=20 a DCC client does not support the tariff=20 change mechanism the DCC server must use a charging model = towards=20 that client that is not based on time,
which means that Tariff-Time-Change = is not to=20 be sent.
This means that it is up to the DCC = server to be=20 able to control if Tariff-Time-Change should be sent or=20 not.
If=20 you have a charging model saying that the price for e.g. volume will = be=20 different between 8 and 18 o'clock the clients will have to=20 support
tariff change = mechanism.
It=20 is a very bad idea if some clients are allowed to break the = charging=20 model (instead the charging model should be=20 changed).
 
/=20 Peter
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad=20 Muhanna
Sent: den 4 juni 2004 15:15
To:=20 aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena = Mattila=20 (TU/LMF); 'juha-pekka.koskinen@nokia.com'; = 'marco.stura@nokia.com';=20 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft = 05:=20 Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, = support of=20 Tariff-Time-Change is optional by the DCC client and = Server.

"
   The = Diameter=20 credit-control server and client MAY optionally support =
   a tariff change mechanism. The Diameter = credit-control=20 server may
   include a=20 Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it = mandates=20 the DCC client which does not support this functionality to = terminate the=20 DCC session if it receives a CCA with Tariff-Time-Change AVP=20 included.

Under section 5.1, it reads:
"
   If a client does = not support=20 the tariff change mechanism, and it
  =20 receives a CCA message carrying the Tariff-Time-Change AVP, it = MUST=20
   terminate the credit = control session,=20 giving a reason of
  =20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following: =
There is a very good possibility that a DCC server = supports=20 Tariff-Time-Change and DCC Client does not.
This=20 may cause a denial of service for an end-user which home Diameter = CC=20 server supports Tariff-Time-Change mechanism while it is at an = access=20 where DCC client does not.

Am I making sense here?
Your=20 thoughts please.


Thanks,
Ahmad=20

------_=_NextPart_001_01C44D5C.046AD795-- From owner-aaa-wg@merit.edu Tue Jun 8 09:36:52 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26095 for ; Tue, 8 Jun 2004 09:36:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 901DE91285; Tue, 8 Jun 2004 09:36:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F44391286; Tue, 8 Jun 2004 09:36:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72D0791285 for ; Tue, 8 Jun 2004 09:36:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E1A6597D9; Tue, 8 Jun 2004 09:36:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 312565977B for ; Tue, 8 Jun 2004 09:36:35 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58DaWH23568; Tue, 8 Jun 2004 16:36:32 +0300 (EET DST) X-Scanned: Tue, 8 Jun 2004 16:34:54 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i58DYsXa020332; Tue, 8 Jun 2004 16:34:54 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0038R5wY; Tue, 08 Jun 2004 16:34:53 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i58DYlH26253; Tue, 8 Jun 2004 16:34:47 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Jun 2004 16:34:47 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D5D.5D573303" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Tue, 8 Jun 2004 16:34:46 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B058F@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thread-Index: AcRNV6trsNApRQGyTAOxyRFDnzkurQAAxGyQ From: To: , Cc: , , , , X-OriginalArrivalTime: 08 Jun 2004 13:34:47.0989 (UTC) FILETIME=[5E235E50:01C44D5D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44D5D.5D573303 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I think the Peter answer indicated that this is not a problem. =20 Indeed, who decide the billing model is the server in the home network = and not the client in the visited network, this was already discussed in the mailing list a while = ago. If the server sent a tariff-time-change in the answer is because it = requires this model, perhaps=20 it has also contractual implications with the user if the model is = broken, and therefore it is correct for=20 the client to reject the answer if it doesn't support the = tariff-time-change mechanism. =20 It is up to the server to eventually track that the origin-host X = rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, = typically an agreement between DCC-Client and server exist and the server can control whether to send = the tariff-time-change or not. =20 Marco =20 -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); = Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter.=20 Does this mean that every one agrees that this is a problem that needs = to be fixed. If so, what do you think the solution should be? Regards,=20 Ahmad=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, =20 Is it fair to say that your argument is based on the assumption that all = DCC Servers are always aware of all DCC clients capabilities with = respect to Tariff-Time-Change mechanism support. =20 Thanks again. Regards,=20 Ahmad=20 -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20 Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change = mechanism. =20 If a DCC client does not support the tariff change mechanism the DCC = server must use a charging model towards that client that is not based = on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if = Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will = be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging = model (instead the charging model should be changed). =20 / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); = 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; = 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all,=20 According to the DCC draft under section 5.1, support of = Tariff-Time-Change is optional by the DCC client and Server.=20 "=20 The Diameter credit-control server and client MAY optionally support=20 a tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message.=20 "=20 On the other hand and under the same section, it mandates the DCC client = which does not support this functionality to terminate the DCC session = if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads:=20 "=20 If a client does not support the tariff change mechanism, and it=20 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST=20 terminate the credit control session, giving a reason of=20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.=20 "=20 The problem I see is the following:=20 There is a very good possibility that a DCC server supports = Tariff-Time-Change and DCC Client does not.=20 This may cause a denial of service for an end-user which home Diameter = CC server supports Tariff-Time-Change mechanism while it is at an access = where DCC client does not. Am I making sense here?=20 Your thoughts please.=20 Thanks,=20 Ahmad=20 ------_=_NextPart_001_01C44D5D.5D573303 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I=20 think the Peter answer indicated that this is not a = problem.
 
Indeed, who decide the billing model is the server in the home = network=20 and not the client in the
visited network, this was already discussed in the mailing = list a=20 while ago.
If the=20 server sent a tariff-time-change in the answer is because it requires = this=20 model, perhaps
it has also contractual implications with the user if the = model is=20 broken, and therefore it is correct for =
the=20 client to reject the answer if it doesn't=20 support the tariff-time-change mechanism.
 
It is=20 up to the server to eventually track that the origin-host = X rejected=20 an answer with Tariff-Time-Change AVP
and at=20 the next attempt change the billing model if possible. However, = typically an=20 agreement between
DCC-Client and server exist and the server can control whether = to send=20 the tariff-time-change or not.
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna=20 [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004=20 15:51
To: 'Peter Zackrisson (KA/EAB)';=20 aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com';=20 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); = Stura=20 Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad=20 Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

So=20 far the only comment received is from Peter.
Does=20 this mean that every one agrees that this is a problem that needs to = be=20 fixed.
If=20 so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: = Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59=20 AM
To: 'Peter Zackrisson (KA/EAB)';=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

Thanks Peter,
 
Is=20 it fair to say that your argument is based on the assumption = that all=20 DCC Servers are always aware of all DCC clients = capabilities with=20 respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: = Peter=20 Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20
Sent: Friday, June 04, 2004 8:48 AM
To: = Muhanna,=20 Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is = correct=20 regarding the tariff change=20 mechanism.
 
If a DCC client does not support the = tariff change mechanism the DCC = server=20 must use a charging model towards that client that is not based on = time,
which means = that Tariff-Time-Change is not=20 to be sent.
This means that it is up to the DCC = server to be=20 able to control if Tariff-Time-Change should be sent or=20 not.
If you have a charging model saying = that the=20 price for e.g. volume will be different between 8 and 18 o'clock = the=20 clients will have to support
tariff change = mechanism.
It is a very bad idea if some = clients are=20 allowed to break the charging model (instead = the charging=20 model should be changed).
 
/ Peter
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad=20 Muhanna
Sent: den 4 juni 2004 15:15
To:=20 aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena = Mattila=20 (TU/LMF); 'juha-pekka.koskinen@nokia.com'; = 'marco.stura@nokia.com';=20 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA = Draft 05:=20 Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, = support of=20 Tariff-Time-Change is optional by the DCC client and = Server.

"
   The = Diameter=20 credit-control server and client MAY optionally support =
   a tariff change mechanism. The Diameter=20 credit-control server may
   = include a=20 Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, = it=20 mandates the DCC client which does not support this = functionality to=20 terminate the DCC session if it receives a CCA with = Tariff-Time-Change=20 AVP included.

Under section 5.1, it reads:
"
   If a client = does not=20 support the tariff change mechanism, and it
   receives a CCA message carrying the=20 Tariff-Time-Change AVP, it MUST
  =20 terminate the credit control session, giving a reason of=20
   DIAMETER_BAD_ANSWER in = the=20 Termination-Cause AVP.
"

The problem I see is the following: =
There is a very good possibility that a DCC server = supports=20 Tariff-Time-Change and DCC Client does not.
This=20 may cause a denial of service for an end-user which home = Diameter CC=20 server supports Tariff-Time-Change mechanism while it is at an = access=20 where DCC client does not.

Am I making sense here?
Your=20 thoughts please.


Thanks,
Ahmad = =

------_=_NextPart_001_01C44D5D.5D573303-- From owner-aaa-wg@merit.edu Tue Jun 8 10:11:13 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28379 for ; Tue, 8 Jun 2004 10:11:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95C6B91294; Tue, 8 Jun 2004 10:08:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 279C891295; Tue, 8 Jun 2004 10:08:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCC4191294 for ; Tue, 8 Jun 2004 10:08:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B25E2596E8; Tue, 8 Jun 2004 10:08:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 0BADB59789 for ; Tue, 8 Jun 2004 10:08:31 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i58E8MU18311; Tue, 8 Jun 2004 10:08:23 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jun 2004 10:08:19 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6BFD@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'marco.stura@nokia.com'" , peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Tue, 8 Jun 2004 10:08:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44D62.0A3CC119" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44D62.0A3CC119 Content-Type: text/plain Hi, please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think the Peter answer indicated that this is not a problem. [A.M.] Apparently and based on my comment to Peter, I disagree. Indeed, who decide the billing model is the server in the home network and not the client in the visited network, this was already discussed in the mailing list a while ago. If the server sent a tariff-time-change in the answer is because it requires this model, perhaps it has also contractual implications with the user if the model is broken, and therefore it is correct for the client to reject the answer if it doesn't support the tariff-time-change mechanism. It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, typically an agreement between DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. [A.M.] I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server" I may also add another straight forward one, 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client. Is there any other options that the group may think applicable to this issue? Ahmad Marco -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44D62.0A3CC119 Content-Type: text/html Message
Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps
it has also contractual implications with the user if the model is broken, and therefore it is correct for
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change.
The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"
2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one,
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44D62.0A3CC119-- From owner-aaa-wg@merit.edu Tue Jun 8 22:40:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20746 for ; Tue, 8 Jun 2004 22:40:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A4AC91240; Tue, 8 Jun 2004 22:40:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 398C99128F; Tue, 8 Jun 2004 22:40:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3060D91240 for ; Tue, 8 Jun 2004 22:40:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16CB25987C; Tue, 8 Jun 2004 22:40:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 7610C59878 for ; Tue, 8 Jun 2004 22:40:01 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i592du423803; Tue, 8 Jun 2004 22:39:56 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Jun 2004 22:39:56 -0400 Message-ID: <7E49849DDCBEAA489C65292E8B8AE7E82139BD@zrc2hxm2.corp.nortel.com> From: "Satheesh Maddireddi" To: "Ahmad Muhanna" , "'marco.stura@nokia.com'" , peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Tue, 8 Jun 2004 22:39:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44DCB.074A4C73" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44DCB.074A4C73 Content-Type: text/plain Hi, I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be because of the GSU unit types OR the tariff change AVP will have to retry at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants. Regards, Satheesh -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think the Peter answer indicated that this is not a problem. [A.M.] Apparently and based on my comment to Peter, I disagree. Indeed, who decide the billing model is the server in the home network and not the client in the visited network, this was already discussed in the mailing list a while ago. If the server sent a tariff-time-change in the answer is because it requires this model, perhaps it has also contractual implications with the user if the model is broken, and therefore it is correct for the client to reject the answer if it doesn't support the tariff-time-change mechanism. It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, typically an agreement between DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. [A.M.] I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server" I may also add another straight forward one, 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client. Is there any other options that the group may think applicable to this issue? Ahmad Marco -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44DCB.074A4C73 Content-Type: text/html Message
Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants.
 
Regards,
Satheesh

 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Tuesday, June 08, 2004 9:08 AM
To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps
it has also contractual implications with the user if the model is broken, and therefore it is correct for
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change.
The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"
2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one,
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44DCB.074A4C73-- From owner-aaa-wg@merit.edu Wed Jun 9 06:27:56 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07244 for ; Wed, 9 Jun 2004 06:27:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E27591298; Wed, 9 Jun 2004 06:27:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2564F91299; Wed, 9 Jun 2004 06:27:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE4CB91298 for ; Wed, 9 Jun 2004 06:27:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C726759812; Wed, 9 Jun 2004 06:27:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id BBDE859879 for ; Wed, 9 Jun 2004 06:27:36 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59ARUH00297; Wed, 9 Jun 2004 13:27:30 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 13:25:53 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i59APr24014091; Wed, 9 Jun 2004 13:25:53 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00fTnPJO; Wed, 09 Jun 2004 13:25:51 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59APoH26768; Wed, 9 Jun 2004 13:25:50 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 13:25:46 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E0C.1F83DC22" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Wed, 9 Jun 2004 13:25:44 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C880F@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thread-Index: AcRNy1ag/8Q3UqcIRYWSHnAP31+lqwAKS//A From: To: , , Cc: , , , , , X-OriginalArrivalTime: 09 Jun 2004 10:25:46.0514 (UTC) FILETIME=[20815F20:01C44E0C] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44E0C.1F83DC22 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I think what really happen is that the user signs a contract with a = service provider, often referred as subscription.=20 The contract typically states the pricing structure for the services, = including tariff time changes, when and where=20 certain conditions are applicable etc. Therefore, whether tariff time = changes are applicable when roaming to a=20 given visited network, should be known as well since this may have legal = implications (i.e. you cannot sell to a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm = to 6 am if not sure that tariff change is supported. Presumably you cannot sell that the = effective cost of the service has dependencies on whether tariff change is supported in the visited network either. So, = you have to know it beforehand.). Introducing additional protocol functionalities such as new termination cause etc. = won't help in that respect, since in most cases the server won't accept to change the billing model agreed = beforehand with the user, the service will most=20 likely be denied in any case. =20 We have a paragraph in section 4.1 that is supposed to cover this = interoperability issues, basically the option 2 listed by Ahmad. =20 Clip It is reasonable to expect that there will exist a service level=20 agreement between providers of the credit control client and the=20 credit control server covering the charging, services offered,=20 roaming agreements, agreed rating input, etc.=20 =20 "covering the charging" basically refers to the charging model, = therefore includes such things as the tariff changes and charging type (e.g. volume, time etc.) too. We thought that it was = better choice to group all this interoperability stuff in=20 one section rather than repeating the same text for all the optional = features along the document, there is nothing left to=20 individual interpretation or assumptions as Ahmad appears to believe. =20 That said, the draft passed couple of WG last calls, the AD review and = is now in the IESG review. So, IESG officially frowns=20 upon changes except in extreme cases (i.e. major bugs). What you are = pointing out, as discussed above, I don't believe=20 is a bug at all and that is reasonable to expect SLA is mentioned in = section 4.1. =20 Mark Grayson wrote =20 >well at least there seems to be some inconsistency with optional MSCC = which then has support explicitly indicated by the client. =20 The MSCC is a bit different case. Who decide at the origin to multiplex = services in the same credit control session is actually the client, while the tariff-change is server driven. The reason of = indicating MSCC support in the initial CCR, is to indicate to the server "I want to multiplex services that may be subject to = different cost in the same session". The server may reject the request because it doesn't support the feature (Failed AVP included in = the response), in such a case the client still have the option to open a credit control session for each of the requested = services. As discussed above this won't be effective in case of tariff-changes, all would happen is that the server would reject the = request if the client indicates "tariff change not supported" since you cannot change the beforehand agreed charging model with the = user. =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Satheesh Maddireddi Sent: 09 June, 2004 05:40 To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); = peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); = aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, =20 I agree with Ahmad we should have a specific reason for the failing the = MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be = because of the GSU unit types OR the tariff change AVP will have to = retry at most 2 times to understand the meaning of failure reason. (Need a new = failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for = the client to trigger reauth as the server wants. =20 Regards, Satheesh=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards,=20 Ahmad=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, =20 I think the Peter answer indicated that this is not a problem.=20 =20 [A.M.] Apparently and based on my comment to Peter, I disagree.=20 =20 Indeed, who decide the billing model is the server in the home network = and not the client in the visited network, this was already discussed in the mailing list a while = ago. If the server sent a tariff-time-change in the answer is because it = requires this model, perhaps=20 it has also contractual implications with the user if the model is = broken, and therefore it is correct for=20 the client to reject the answer if it doesn't support the = tariff-time-change mechanism. =20 It is up to the server to eventually track that the origin-host X = rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, = typically an agreement between DCC-Client and server exist and the server can control whether to send = the tariff-time-change or not.=20 =20 [A.M.]=20 I think we are drafting a standard that needs not to leave anything for = individual interpretation or assumptions. Also, to avoid any IOT = problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC = clients support for Tariff-Time-Change.=20 The only problem I see here is how the server would know that the client = does not support Tariff-Time-Change while the cause value in the = Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between = DCC-Client and DCC Server" =20 I may also add another straight forward one,=20 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC = server and DCC Client. =20 Is there any other options that the group may think applicable to this = issue? =20 Ahmad =20 Marco =20 -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); = Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter.=20 Does this mean that every one agrees that this is a problem that needs = to be fixed. If so, what do you think the solution should be? Regards,=20 Ahmad=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, =20 Is it fair to say that your argument is based on the assumption that all = DCC Servers are always aware of all DCC clients capabilities with = respect to Tariff-Time-Change mechanism support. =20 Thanks again. Regards,=20 Ahmad=20 -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20 Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change = mechanism. =20 If a DCC client does not support the tariff change mechanism the DCC = server must use a charging model towards that client that is not based = on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if = Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will = be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging = model (instead the charging model should be changed). =20 / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); = 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; = 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all,=20 According to the DCC draft under section 5.1, support of = Tariff-Time-Change is optional by the DCC client and Server.=20 "=20 The Diameter credit-control server and client MAY optionally support=20 a tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message.=20 "=20 On the other hand and under the same section, it mandates the DCC client = which does not support this functionality to terminate the DCC session = if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads:=20 "=20 If a client does not support the tariff change mechanism, and it=20 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST=20 terminate the credit control session, giving a reason of=20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.=20 "=20 The problem I see is the following:=20 There is a very good possibility that a DCC server supports = Tariff-Time-Change and DCC Client does not.=20 This may cause a denial of service for an end-user which home Diameter = CC server supports Tariff-Time-Change mechanism while it is at an access = where DCC client does not. Am I making sense here?=20 Your thoughts please.=20 Thanks,=20 Ahmad=20 ------_=_NextPart_001_01C44E0C.1F83DC22 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I=20 think what really happen is that the user signs a=20 contract with a service provider, often referred as subscription.=20
The=20 contract typically states the pricing structure for the = services,=20 including tariff time changes, when and where
certain conditions are  applicable etc. Therefore, whether = tariff time=20 changes are applicable when roaming to a
given=20 visited network, should be known as well since this may = have legal=20 implications (i.e. you cannot sell to
a user=20 that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 = am if not=20 sure that
tariff=20 change is supported. Presumably you cannot sell that the effective cost = of the=20 service has dependencies
on=20 whether tariff change is supported in the visited network either. So, = you have=20 to know it beforehand.). Introducing
additional protocol functionalities such as new termination = cause etc.=20 won't help in that respect, since in most
cases=20 the server won't accept to change the billing model agreed beforehand = with the=20 user, the service will most
likely=20 be denied in any case.
 
We=20 have a paragraph in section 4.1 that is supposed to cover this = interoperability=20 issues, basically the option 2
listed=20 by Ahmad.
 
Clip

   It is reasonable = to expect=20 that there will exist a service level
   agreement between = providers of the credit control client and the
   credit = control=20 server covering the charging, services offered,
   roaming = agreements, agreed rating input, etc.
   
"covering the charging" basically refers to the charging model, = therefore=20 includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought=20 that it was better choice to group all this interoperability = stuff in=20
one=20 section rather than repeating the same text for all the optional=20 features along the document, there is nothing left to =
individual interpretation or assumptions as=20 Ahmad appears to believe.
 
That=20 said, the draft passed couple of WG last calls, the AD = review and is=20 now in the IESG review. So, IESG officially frowns
upon=20 changes except in extreme cases (i.e. major bugs). What = you are=20 pointing out, as discussed above, I don't believe =
is a=20 bug at all and that is reasonable to expect SLA is mentioned in section=20 4.1.
 
Mark=20 Grayson wrote
 
>well at least there seems to be some inconsistency with = optional MSCC=20 which then has support explicitly indicated by the=20 client.
 
The MSCC is a bit different case. Who decide = at the=20 origin to multiplex services in the same credit control session is=20 actually
the client, while the tariff-change is server = driven.=20 The reason of indicating MSCC support in the initial CCR, is to indicate = to
the server "I want to multiplex services that = may be=20 subject to different cost in the same session". The server may reject=20 the
request because it doesn't support the = feature (Failed=20 AVP included in the response), in such a case the client still have=20 the
option to open a credit control session for = each of the=20 requested services. As discussed above this won't be effective in=20 case
of tariff-changes, all would happen is that = the server=20 would reject the request if the client indicates "tariff change not=20 supported"
since you cannot change the beforehand agreed = charging=20 model with the user.
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh=20 Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad = Muhanna;=20 Stura Marco (Nokia-NET/Helsinki); = peter.zackrisson@ericsson.com
Cc:=20 Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen = Juha-Pekka=20 (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki);=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

Hi,
 
I=20 agree with Ahmad we should have a specific reason for the failing the = MSCC in=20 case if the client doesn't support the Tariff-Time-Change=20 AVP
as=20 the the server will not be able to interpret the=20 failure as it may be because of  the GSU unit = types OR the=20 tariff change AVP will have to retry
at=20 most 2 times to understand the meaning of = failure reason.=20 (Need a new failure cause). Regarding mandating the Tariff-Time-Change = AVP
server always has an option to include a mandatory AVP = Validity-Time=20 for the client to trigger reauth as the server = wants.
 
Regards,
Satheesh=20

 -----Original = Message-----
From:=20 Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Tuesday, June 08, = 2004 9:08=20 AM
To: 'marco.stura@nokia.com';=20 peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; = Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc:=20 Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com;=20 juha-pekka.koskinen@nokia.com; john.loughney@nokia.com;=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

Hi,
 
I think the Peter answer indicated = that this is=20 not a problem. 
 
[A.M.]
Apparently and=20 based on my comment to Peter, I=20 disagree. 
 
Indeed, who decide the billing model is the server in the = home=20 network and not the client in the
visited network, this was already discussed in the = mailing=20 list a while ago.
If the server sent a tariff-time-change in the answer is = because it=20 requires this model, perhaps =
it has also contractual implications with the user = if the=20 model is broken, and therefore it is correct for=20
the client to reject the = answer if it doesn't=20 support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the=20 origin-host X rejected an answer with Tariff-Time-Change=20 AVP
and at the next attempt change the billing model if=20 possible. However, typically an = agreement=20 between
DCC-Client and server exist and the = server can=20 control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting = a standard=20 that needs not to leave anything for individual interpretation or=20 assumptions. Also, to avoid any IOT problem, we need to make = this=20 clear in the standard.
I see you just proposed = a couple of=20 options:
1. Some sort of dynamic=20 configuration based on DCC Server tracking DCC clients = support for=20 Tariff-Time-Change.
The only problem I see = here is how=20 the server would know that the client does not support=20 Tariff-Time-Change while the cause value in the Temination-Cause = AVP is=20 set to a generic one=20 = "DIAMETER_BAD_ANSWER"
2. Static configuration = at the DCC=20 Server based on "agreement between DCC-Client and DCC=20 Server"
 
I may also add another = straight=20 forward one,
3. Mandate the = support for the=20 Tariff-Time-Change mechanism on the DCC server and DCC=20 Client.
 
Is there any other = options that the=20 group may think applicable to this = issue?
 
Ahmad
=
 
Marco
 
-----Original Message-----
From: ext Ahmad = Muhanna=20 [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, = 2004=20 15:51
To: 'Peter Zackrisson (KA/EAB)';=20 aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com';=20 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka = (Nokia-NET/Tampere);=20 Stura Marco (Nokia-NET/Helsinki); Loughney John = (Nokia-NRC/Helsinki);=20 Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

So far the only comment received is = from Peter.=20
Does this mean that every one agrees = that this=20 is a problem that needs to be fixed.
If so, what do you think the solution = should=20 be?

Regards,=20
Ahmad

-----Original = Message-----
From: Muhanna,=20 Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 = 8:59=20 AM
To: 'Peter Zackrisson (KA/EAB)';=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft = 05:=20 Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based = on the=20 assumption that all DCC Servers are always aware = of all DCC=20 clients capabilities with respect to Tariff-Time-Change = mechanism=20 support.
 
Thanks again.

Regards,=20
Ahmad

-----Original = Message-----
From: Peter=20 Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20
Sent: Friday, June 04, 2004 8:48 AM
To: = Muhanna, Ahmad [RICH2:2Q30:EXCH];=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft = 05:=20 Tariff-Time-Change

I think the DCC specification is = correct=20 regarding the tariff change = mechanism.
 
If a DCC client does not support = the tariff change mechanism = the DCC=20 server must use a charging model towards that client that is = not=20 based on time,
which means = that Tariff-Time-Change is=20 not to be sent.
This means that it is up to the = DCC server=20 to be able to control if Tariff-Time-Change should be sent = or=20 not.
If you have a charging model = saying that=20 the price for e.g. volume will be different between 8 and 18 = o'clock=20 the clients will have to support
tariff change=20 mechanism.
It is a very bad idea if = some clients=20 are allowed to break the charging model (instead the charging model = should be=20 changed).
 
/ Peter
-----Original = Message-----
From:=20 owner-aaa-wg@merit.edu = [mailto:owner-aaa-wg@merit.edu]On Behalf=20 Of Ahmad Muhanna
Sent: den 4 juni 2004=20 15:15
To: aaa-wg@merit.edu
Cc: Harri = Hakala=20 (JO/LMF); Leena Mattila (TU/LMF); = 'juha-pekka.koskinen@nokia.com';=20 'marco.stura@nokia.com';=20 'John.Loughney@nokia.com'
Subject: [AAA-WG]: = DCCA Draft=20 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section = 5.1,=20 support of Tariff-Time-Change is optional by the DCC = client and=20 Server.

"
   = The=20 Diameter credit-control server and client MAY optionally = support=20
   a tariff change = mechanism.=20 The Diameter credit-control server may
   include a Tariff-Time-Change AVP in = the answer=20 message.
"

On the other hand and under the same = section, it=20 mandates the DCC client which does not support this = functionality=20 to terminate the DCC session if it receives a CCA with=20 Tariff-Time-Change AVP included.

Under section 5.1, it reads: =
"
   If a = client does not=20 support the tariff change mechanism, and it =
   receives a CCA message carrying the=20 Tariff-Time-Change AVP, it MUST
   terminate the credit control = session, giving a=20 reason of
   = DIAMETER_BAD_ANSWER=20 in the Termination-Cause AVP.
"=20

The problem I see is the = following:=20
There is a very good possibility that a = DCC=20 server supports Tariff-Time-Change and DCC Client does = not.=20
This may cause a denial of service for = an=20 end-user which home Diameter CC server supports = Tariff-Time-Change=20 mechanism while it is at an access where DCC client does=20 not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad=20 =

------_=_NextPart_001_01C44E0C.1F83DC22-- From owner-aaa-wg@merit.edu Wed Jun 9 08:10:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10991 for ; Wed, 9 Jun 2004 08:10:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A0B09129A; Wed, 9 Jun 2004 08:10:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B2BA9129B; Wed, 9 Jun 2004 08:10:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D49169129A for ; Wed, 9 Jun 2004 08:10:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6DA159852; Wed, 9 Jun 2004 08:10:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id D30C659801 for ; Wed, 9 Jun 2004 08:10:17 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i59CA7I19830; Wed, 9 Jun 2004 08:10:07 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 08:10:08 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6C0D@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'marco.stura@nokia.com'" , "Satheesh Maddireddi" , mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu, peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Wed, 9 Jun 2004 08:10:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E1A.B0FF6B15" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44E1A.B0FF6B15 Content-Type: text/plain Hi, Please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, June 09, 2004 5:26 AM To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think what really happen is that the user signs a contract with a service provider, often referred as subscription. The contract typically states the pricing structure for the services, including tariff time changes, when and where certain conditions are applicable etc. Therefore, whether tariff time changes are applicable when roaming to a given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most cases the server won't accept to change the billing model agreed beforehand with the user, the service will most likely be denied in any case. [A.M.] I agree. Please see comments below. We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2 listed by Ahmad. Clip It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. [A.M.] I think this probably enough to cover the static configuration portion of it. "covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in one section rather than repeating the same text for all the optional features along the document, there is nothing left to individual interpretation or assumptions as Ahmad appears to believe. That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. [A.M.] Agreed. I believe the cause value should be changed to a specific one and not so generic. I do not think it is too late to propose a new cause value as "tariff change not supported". It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. Mark Grayson wrote >well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client. The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the option to open a credit control session for each of the requested services. As discussed above this won't be effective in case of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported" since you cannot change the beforehand agreed charging model with the user. [A.M.] please see comments above. Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi Sent: 09 June, 2004 05:40 To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be because of the GSU unit types OR the tariff change AVP will have to retry at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants. Regards, Satheesh -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think the Peter answer indicated that this is not a problem. [A.M.] Apparently and based on my comment to Peter, I disagree. Indeed, who decide the billing model is the server in the home network and not the client in the visited network, this was already discussed in the mailing list a while ago. If the server sent a tariff-time-change in the answer is because it requires this model, perhaps it has also contractual implications with the user if the model is broken, and therefore it is correct for the client to reject the answer if it doesn't support the tariff-time-change mechanism. It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, typically an agreement between DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. [A.M.] I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server" I may also add another straight forward one, 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client. Is there any other options that the group may think applicable to this issue? Ahmad Marco -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44E1A.B0FF6B15 Content-Type: text/html Message
Hi,
Please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think what really happen is that the user signs a contract with a service provider, often referred as subscription.
The contract typically states the pricing structure for the services, including tariff time changes, when and where
certain conditions are  applicable etc. Therefore, whether tariff time changes are applicable when roaming to a
given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to
a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that
tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies
on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing
additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most
cases the server won't accept to change the billing model agreed beforehand with the user, the service will most
likely be denied in any case.
 
[A.M.]
I agree.
Please see comments below.
 
We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is reasonable to expect that there will exist a service level
   agreement between providers of the credit control client and the
   credit control server covering the charging, services offered,
   roaming agreements, agreed rating input, etc.
     
[A.M.]
I think this probably enough to cover the static configuration portion of it.
 
"covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in
one section rather than repeating the same text for all the optional features along the document, there is nothing left to
individual interpretation or assumptions as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns
upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe
is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be changed to a specific one and not so generic.
I do not think it is too late to propose a new cause value as "tariff change not supported".
It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client.
 
The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually
the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to
the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the
request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the
option to open a credit control session for each of the requested services. As discussed above this won't be effective in case
of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported"
since you cannot change the beforehand agreed charging model with the user. 
 
[A.M.]
please see comments above. 
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants.
 
Regards,
Satheesh

 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Tuesday, June 08, 2004 9:08 AM
To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps
it has also contractual implications with the user if the model is broken, and therefore it is correct for
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change.
The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"
2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one,
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44E1A.B0FF6B15-- From owner-aaa-wg@merit.edu Wed Jun 9 08:44:16 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12366 for ; Wed, 9 Jun 2004 08:44:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3E8B9129B; Wed, 9 Jun 2004 08:43:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B30849129C; Wed, 9 Jun 2004 08:43:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 227FE9129B for ; Wed, 9 Jun 2004 08:43:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0594B598B6; Wed, 9 Jun 2004 08:43:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id BEADD598AA for ; Wed, 9 Jun 2004 08:43:51 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59ChhJ06570; Wed, 9 Jun 2004 15:43:43 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 15:42:43 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i59CghuB030697; Wed, 9 Jun 2004 15:42:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00WHbwRa; Wed, 09 Jun 2004 15:42:42 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59CggH25488; Wed, 9 Jun 2004 15:42:42 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 15:42:40 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 15:42:40 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E1F.401754C6" Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Wed, 9 Jun 2004 15:42:39 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0592@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thread-Index: AcROGyKuNx5zlBLHQqa4WpIzGy3NtwAASSUA From: To: , , Cc: , , , , , X-OriginalArrivalTime: 09 Jun 2004 12:42:40.0971 (UTC) FILETIME=[40B409B0:01C44E1F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44E1F.401754C6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ahmad, =20 it seems you didn't get my point. What is indicated in the draft is = that SLA is expected to cover bla bla bla...., and this should be enough other options are not needed. =20 Finally, the only changes allowed at this point are major bug fixing and = your proposal doesn't fall within this category. So, new termination causes will not be added in this DCC version unless explicitely = requested by IESG. =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Ahmad Muhanna Sent: 09 June, 2004 15:10 To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; = mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); = aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, Please see comments inline. Regards,=20 Ahmad=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Wednesday, June 09, 2004 5:26 AM To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad = [RICH2:2Q30:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; = aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, =20 I think what really happen is that the user signs a contract with a = service provider, often referred as subscription.=20 The contract typically states the pricing structure for the services, = including tariff time changes, when and where=20 certain conditions are applicable etc. Therefore, whether tariff time = changes are applicable when roaming to a=20 given visited network, should be known as well since this may have legal = implications (i.e. you cannot sell to a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm = to 6 am if not sure that tariff change is supported. Presumably you cannot sell that the = effective cost of the service has dependencies on whether tariff change is supported in the visited network either. So, = you have to know it beforehand.). Introducing additional protocol functionalities such as new termination cause etc. = won't help in that respect, since in most cases the server won't accept to change the billing model agreed = beforehand with the user, the service will most=20 likely be denied in any case. =20 [A.M.] I agree. Please see comments below. =20 We have a paragraph in section 4.1 that is supposed to cover this = interoperability issues, basically the option 2 listed by Ahmad. =20 Clip It is reasonable to expect that there will exist a service level=20 agreement between providers of the credit control client and the=20 credit control server covering the charging, services offered,=20 roaming agreements, agreed rating input, etc.=20 =20 [A.M.] I think this probably enough to cover the static configuration portion = of it. =20 "covering the charging" basically refers to the charging model, = therefore includes such things as the tariff changes and charging type (e.g. volume, time etc.) too. We thought that it was = better choice to group all this interoperability stuff in=20 one section rather than repeating the same text for all the optional = features along the document, there is nothing left to=20 individual interpretation or assumptions as Ahmad appears to believe. =20 That said, the draft passed couple of WG last calls, the AD review and = is now in the IESG review. So, IESG officially frowns=20 upon changes except in extreme cases (i.e. major bugs). What you are = pointing out, as discussed above, I don't believe=20 is a bug at all and that is reasonable to expect SLA is mentioned in = section 4.1.=20 =20 [A.M.] Agreed. I believe the cause value should be changed to a specific one and not so = generic.=20 I do not think it is too late to propose a new cause value as "tariff = change not supported".=20 It is more descriptive and much more helpful for collecting proper OM at = both ends; the server and client.=20 =20 Mark Grayson wrote =20 >well at least there seems to be some inconsistency with optional MSCC = which then has support explicitly indicated by the client. =20 The MSCC is a bit different case. Who decide at the origin to multiplex = services in the same credit control session is actually the client, while the tariff-change is server driven. The reason of = indicating MSCC support in the initial CCR, is to indicate to the server "I want to multiplex services that may be subject to = different cost in the same session". The server may reject the request because it doesn't support the feature (Failed AVP included in = the response), in such a case the client still have the option to open a credit control session for each of the requested = services. As discussed above this won't be effective in case of tariff-changes, all would happen is that the server would reject the = request if the client indicates "tariff change not supported" since you cannot change the beforehand agreed charging model with the = user.=20 =20 [A.M.] please see comments above.=20 =20 Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = ext Satheesh Maddireddi Sent: 09 June, 2004 05:40 To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); = peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); = aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, =20 I agree with Ahmad we should have a specific reason for the failing the = MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be = because of the GSU unit types OR the tariff change AVP will have to = retry at most 2 times to understand the meaning of failure reason. (Need a new = failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for = the client to trigger reauth as the server wants. =20 Regards, Satheesh=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards,=20 Ahmad=20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; = juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, =20 I think the Peter answer indicated that this is not a problem.=20 =20 [A.M.] Apparently and based on my comment to Peter, I disagree.=20 =20 Indeed, who decide the billing model is the server in the home network = and not the client in the visited network, this was already discussed in the mailing list a while = ago. If the server sent a tariff-time-change in the answer is because it = requires this model, perhaps=20 it has also contractual implications with the user if the model is = broken, and therefore it is correct for=20 the client to reject the answer if it doesn't support the = tariff-time-change mechanism. =20 It is up to the server to eventually track that the origin-host X = rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, = typically an agreement between DCC-Client and server exist and the server can control whether to send = the tariff-time-change or not.=20 =20 [A.M.]=20 I think we are drafting a standard that needs not to leave anything for = individual interpretation or assumptions. Also, to avoid any IOT = problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC = clients support for Tariff-Time-Change.=20 The only problem I see here is how the server would know that the client = does not support Tariff-Time-Change while the cause value in the = Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between = DCC-Client and DCC Server" =20 I may also add another straight forward one,=20 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC = server and DCC Client. =20 Is there any other options that the group may think applicable to this = issue? =20 Ahmad =20 Marco =20 -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen = Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); = Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter.=20 Does this mean that every one agrees that this is a problem that needs = to be fixed. If so, what do you think the solution should be? Regards,=20 Ahmad=20 -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20 Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, =20 Is it fair to say that your argument is based on the assumption that all = DCC Servers are always aware of all DCC clients capabilities with = respect to Tariff-Time-Change mechanism support. =20 Thanks again. Regards,=20 Ahmad=20 -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]=20 Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change = mechanism. =20 If a DCC client does not support the tariff change mechanism the DCC = server must use a charging model towards that client that is not based = on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if = Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will = be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging = model (instead the charging model should be changed). =20 / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of = Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); = 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; = 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all,=20 According to the DCC draft under section 5.1, support of = Tariff-Time-Change is optional by the DCC client and Server.=20 "=20 The Diameter credit-control server and client MAY optionally support=20 a tariff change mechanism. The Diameter credit-control server may=20 include a Tariff-Time-Change AVP in the answer message.=20 "=20 On the other hand and under the same section, it mandates the DCC client = which does not support this functionality to terminate the DCC session = if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads:=20 "=20 If a client does not support the tariff change mechanism, and it=20 receives a CCA message carrying the Tariff-Time-Change AVP, it MUST=20 terminate the credit control session, giving a reason of=20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.=20 "=20 The problem I see is the following:=20 There is a very good possibility that a DCC server supports = Tariff-Time-Change and DCC Client does not.=20 This may cause a denial of service for an end-user which home Diameter = CC server supports Tariff-Time-Change mechanism while it is at an access = where DCC client does not. Am I making sense here?=20 Your thoughts please.=20 Thanks,=20 Ahmad=20 ------_=_NextPart_001_01C44E1F.401754C6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Ahmad,
 
it=20 seems you didn't get my point.  = What is=20 indicated in the draft is that SLA is expected to cover=20 bla bla bla...., and this should be enough
other=20 options are not needed.
 
Finally, the only changes allowed at this point are major bug = fixing and=20 your proposal doesn't fall within this category. So, new=20 termination
causes=20 will not be added in this DCC version unless explicitely requested by=20 IESG.
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Ahmad=20 Muhanna
Sent: 09 June, 2004 15:10
To: Stura Marco=20 (Nokia-NET/Helsinki); Satheesh Maddireddi; = mgrayson@cisco.com
Cc:=20 Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen = Juha-Pekka=20 (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); = aaa-wg@merit.edu;=20 peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA = Draft 05:=20 Tariff-Time-Change

Hi,
Please see comments inline.

Regards,
Ahmad

-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh=20 [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH];=20 mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com;=20 Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com;=20 john.loughney@nokia.com; aaa-wg@merit.edu;=20 peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA = Draft=20 05: Tariff-Time-Change

Hi,
 
I=20 think what really happen is that the user signs=20 a contract with a service provider, often referred as subscription.=20
The contract typically states the pricing=20 structure for the services, including tariff time changes, when and = where=20
certain conditions are  applicable etc. Therefore, = whether tariff=20 time changes are applicable when roaming to a
given visited network, should be known as = well since this=20 may have legal implications (i.e. you cannot sell=20 to
a=20 user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from = 6pm to 6=20 am if not sure that
tariff change is supported. Presumably you cannot sell that = the=20 effective cost of the service has dependencies
on=20 whether tariff change is supported in the visited network either. = So, you=20 have to know it beforehand.). Introducing
additional protocol functionalities such as new termination = cause=20 etc. won't help in that respect, since in most
cases the server won't accept to change the billing model = agreed=20 beforehand with the user, the service will most
likely be denied in any = case.
 
[A.M.]
I agree.
Please see comments = below.
 
We=20 have a paragraph in section 4.1 that is supposed to cover this=20 interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is = reasonable to=20 expect that there will exist a service level
   = agreement=20 between providers of the credit control client and the =
  =20 credit control server covering the charging, services offered,=20
   roaming agreements, agreed rating input, etc. =
     
[A.M.]
I think this probably = enough to cover=20 the static configuration portion of=20 it.
 
"covering the charging" basically refers to the charging = model,=20 therefore includes such things as the tariff changes = and
charging type (e.g. volume, time etc.) too. We thought=20 that it was better choice to group all this = interoperability stuff in=20
one section rather than repeating the same text for all=20 the optional features along the document, = there is=20 nothing left to
individual interpretation or assumptions=20 as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, = the AD=20 review and is now in the IESG review. So, IESG officially = frowns=20
upon changes except in extreme cases (i.e. = major bugs).=20 What you are pointing out, as discussed above, I don't believe=20
is a bug at all and that is = reasonable to expect=20 SLA is mentioned in section 4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be = changed to a=20 specific one and not so generic. =
I do not think it is too = late to=20 propose a new cause value as "tariff change not supported".=20
It is more descriptive and = much more=20 helpful for collecting proper OM at both ends; the server and=20 client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with = optional MSCC=20 which then has support explicitly indicated by the=20 client.
 
The MSCC is a bit = different case. Who=20 decide at the origin to multiplex services in the same credit = control=20 session is actually
the client, while the = tariff-change is=20 server driven. The reason of indicating MSCC support in the initial = CCR, is=20 to indicate to
the server "I want to = multiplex=20 services that may be subject to different cost in the same session". = The=20 server may reject the
request because it doesn't = support the=20 feature (Failed AVP included in the response), in such a case the = client=20 still have the
option to open a credit = control=20 session for each of the requested services. As discussed above this = won't be=20 effective in case
of tariff-changes, all = would happen is=20 that the server would reject the request if the client indicates = "tariff=20 change not supported"
since you cannot = change the=20 beforehand agreed charging model with the user. 
&nbs= p;
[A.M.]
please=20 see comments = above. 
 
Regards
Marco
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh=20 Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad = Muhanna; Stura Marco (Nokia-NET/Helsinki);=20 peter.zackrisson@ericsson.com
Cc: = Harri.Hakala@ericsson.com;=20 Leena.Mattila@ericsson.com; Koskinen Juha-Pekka = (Nokia-NET/Tampere);=20 Loughney John (Nokia-NRC/Helsinki); = aaa-wg@merit.edu
Subject:=20 RE: [AAA-WG]: DCCA Draft 05: = Tariff-Time-Change

Hi,
 
I agree with Ahmad we should have a specific reason for = the failing=20 the MSCC in case if the client doesn't support the = Tariff-Time-Change=20 AVP
as the the server will not be able to interpret = the=20 failure as it may be because of  the GSU unit = types OR=20 the tariff change AVP will have to retry
at most 2 times to understand the = meaning of=20 failure reason. (Need a new failure = cause). Regarding=20 mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP=20 Validity-Time for the client to trigger reauth as the server=20 wants.
 
Regards,
Satheesh=20

 -----Original=20 Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]=20
Sent: Tuesday, June 08, 2004 9:08 AM
To:=20 'marco.stura@nokia.com'; = peter.zackrisson@ericsson.com
Cc:=20 Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com;=20 juha-pekka.koskinen@nokia.com; john.loughney@nokia.com;=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent:=20 Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: = Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com;=20 juha-pekka.koskinen@nokia.com; john.loughney@nokia.com;=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft = 05:=20 Tariff-Time-Change

Hi,
 
I think the Peter answer = indicated that=20 this is not a problem. 
 
[A.M.]
Apparently=20 and based on my comment to Peter, I=20 disagree. 
 
Indeed, who decide the billing model is the server in = the home=20 network and not the client in the
visited network, this was already discussed in = the mailing=20 list a while ago.
If the server sent a tariff-time-change in the answer = is=20 because it requires this model,=20 perhaps
it has also contractual implications with the = user if the=20 model is broken, and therefore it is correct for
the client to reject the=20 answer if it doesn't = support the=20 tariff-time-change mechanism.
 
It is up to the server to eventually track that = the=20 origin-host X rejected an answer with Tariff-Time-Change=20 AVP
and at the next attempt change the billing model if=20 possible. However, typically an = agreement=20 between
DCC-Client and server exist and = the server=20 can control whether to send the tariff-time-change or = not. 
 
[A.M.] 
I think we are = drafting a=20 standard that needs not to leave anything for individual=20 interpretation or assumptions. Also, to avoid any IOT = problem, we=20 need to make this clear in the = standard.
I see you just = proposed a couple=20 of options:
1. Some sort of = dynamic=20 configuration based on DCC Server tracking DCC clients = support=20 for Tariff-Time-Change.
The only problem I = see here is=20 how the server would know that the client does not support=20 Tariff-Time-Change while the cause value in the = Temination-Cause AVP=20 is set to a generic one=20 = "DIAMETER_BAD_ANSWER"
2. Static = configuration at the=20 DCC Server based on "agreement between DCC-Client and DCC=20 Server"
 
I may also add = another straight=20 forward one,
3. Mandate the = support for=20 the Tariff-Time-Change mechanism on the DCC server and = DCC=20 Client.
 
Is there any other = options that=20 the group may think applicable to this=20 issue?
 
Ahmad
=
 
Marco
 
-----Original Message-----
From: ext = Ahmad Muhanna=20 [mailto:amuhanna@nortelnetworks.com]
Sent: 08 = June, 2004=20 15:51
To: 'Peter Zackrisson (KA/EAB)';=20 aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com';=20 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka=20 (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); = Loughney John=20 (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Tariff-Time-Change

So far the only comment received = is from=20 Peter.
Does this mean that every one = agrees that=20 this is a problem that needs to be = fixed.
If so, what do you think the = solution=20 should be?

Regards,=20
Ahmad=20

-----Original=20 Message-----
From: Muhanna, Ahmad = [RICH2:2Q30:EXCH]=20
Sent: Friday, June 04, 2004 8:59 = AM
To:=20 'Peter Zackrisson (KA/EAB)'; = aaa-wg@merit.edu
Subject:=20 RE: [AAA-WG]: DCCA Draft 05:=20 Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based = on the=20 assumption that all DCC Servers are always aware = of all=20 DCC clients capabilities with respect to = Tariff-Time-Change=20 mechanism support.
 
Thanks again.

Regards,=20
Ahmad=20

-----Original=20 Message-----
From: Peter Zackrisson (KA/EAB)=20 [mailto:peter.zackrisson@ericsson.com]
Sent: = Friday,=20 June 04, 2004 8:48 AM
To: Muhanna, Ahmad=20 [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: = RE:=20 [AAA-WG]: DCCA Draft 05: = Tariff-Time-Change

I think the DCC specification = is=20 correct regarding the tariff=20 change mechanism.
 
If a DCC client does not = support the=20 tariff change = mechanism=20 the DCC server must use a charging model towards that = client=20 that is not based on time,
which means=20 that Tariff-Time-Change is not to be=20 sent.
This means that it is up to = the DCC=20 server to be able to control if Tariff-Time-Change = should be=20 sent or not.
If you have a charging model = saying=20 that the price for e.g. volume will be different between = 8 and=20 18 o'clock the clients will have to = support
tariff change=20 mechanism.
It is a very bad idea if = some=20 clients are allowed to break the charging model=20 (instead the charging model = should be=20 changed).
 
/ Peter
-----Original = Message-----
From:=20 owner-aaa-wg@merit.edu = [mailto:owner-aaa-wg@merit.edu]On=20 Behalf Of Ahmad Muhanna
Sent: den 4 juni = 2004=20 15:15
To: aaa-wg@merit.edu
Cc: = Harri=20 Hakala (JO/LMF); Leena Mattila (TU/LMF);=20 'juha-pekka.koskinen@nokia.com'; = 'marco.stura@nokia.com';=20 'John.Loughney@nokia.com'
Subject: [AAA-WG]: = DCCA=20 Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under = section 5.1,=20 support of Tariff-Time-Change is optional by the DCC = client=20 and Server.

"
   The=20 Diameter credit-control server and client MAY = optionally=20 support
   a = tariff change=20 mechanism. The Diameter credit-control server may=20
   include a=20 Tariff-Time-Change AVP in the answer message. =
"

On the other hand and under the same = section,=20 it mandates the DCC client which does not support this = functionality to terminate the DCC session if it = receives a=20 CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads: =
"
   If a = client does=20 not support the tariff change mechanism, and it=20
   receives a CCA = message=20 carrying the Tariff-Time-Change AVP, it MUST =
   terminate the credit control = session,=20 giving a reason of
  =20 DIAMETER_BAD_ANSWER in the Termination-Cause AVP.=20
"

The problem I see is the = following:=20
There is a very good possibility = that a DCC=20 server supports Tariff-Time-Change and DCC Client does = not.
This may cause a denial = of=20 service for an end-user which home Diameter CC server = supports=20 Tariff-Time-Change mechanism while it is at an access = where=20 DCC client does not.

Am I making sense here? =
Your thoughts please.


Thanks,
Ahmad=20 =

------_=_NextPart_001_01C44E1F.401754C6-- From owner-aaa-wg@merit.edu Wed Jun 9 08:58:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12872 for ; Wed, 9 Jun 2004 08:58:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7ABD29129C; Wed, 9 Jun 2004 08:58:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 39DD99129D; Wed, 9 Jun 2004 08:58:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C3289129C for ; Wed, 9 Jun 2004 08:58:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 507FB598A4; Wed, 9 Jun 2004 08:58:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 463B5598A0 for ; Wed, 9 Jun 2004 08:58:11 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i59Cw6I25995; Wed, 9 Jun 2004 08:58:06 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 9 Jun 2004 08:58:07 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6C15@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'marco.stura@nokia.com'" , "Satheesh Maddireddi" , mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu, peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Date: Wed, 9 Jun 2004 08:58:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44E20.F28B72BD" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C44E20.F28B72BD Content-Type: text/plain Hi Marco, comments inline.. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, June 09, 2004 7:43 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi Ahmad, it seems you didn't get my point. What is indicated in the draft is that SLA is expected to cover bla bla bla...., and this should be enough other options are not needed. Finally, the only changes allowed at this point are major bug fixing and your proposal doesn't fall within this category. So, new termination causes will not be added in this DCC version unless explicitely requested by IESG. [A.M.] I still believe a new cause value is a much better choice and needed. But, if it is too late at this point, let us hope that IESG request that otherwise, we can forget about it. Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Ahmad Muhanna Sent: 09 June, 2004 15:10 To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, Please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Wednesday, June 09, 2004 5:26 AM To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think what really happen is that the user signs a contract with a service provider, often referred as subscription. The contract typically states the pricing structure for the services, including tariff time changes, when and where certain conditions are applicable etc. Therefore, whether tariff time changes are applicable when roaming to a given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most cases the server won't accept to change the billing model agreed beforehand with the user, the service will most likely be denied in any case. [A.M.] I agree. Please see comments below. We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2 listed by Ahmad. Clip It is reasonable to expect that there will exist a service level agreement between providers of the credit control client and the credit control server covering the charging, services offered, roaming agreements, agreed rating input, etc. [A.M.] I think this probably enough to cover the static configuration portion of it. "covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in one section rather than repeating the same text for all the optional features along the document, there is nothing left to individual interpretation or assumptions as Ahmad appears to believe. That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. [A.M.] Agreed. I believe the cause value should be changed to a specific one and not so generic. I do not think it is too late to propose a new cause value as "tariff change not supported". It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. Mark Grayson wrote >well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client. The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the option to open a credit control session for each of the requested services. As discussed above this won't be effective in case of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported" since you cannot change the beforehand agreed charging model with the user. [A.M.] please see comments above. Regards Marco -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi Sent: 09 June, 2004 05:40 To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP as the the server will not be able to interpret the failure as it may be because of the GSU unit types OR the tariff change AVP will have to retry at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants. Regards, Satheesh -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Tuesday, June 08, 2004 9:08 AM To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, please see comments inline. Regards, Ahmad -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, June 08, 2004 8:35 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi, I think the Peter answer indicated that this is not a problem. [A.M.] Apparently and based on my comment to Peter, I disagree. Indeed, who decide the billing model is the server in the home network and not the client in the visited network, this was already discussed in the mailing list a while ago. If the server sent a tariff-time-change in the answer is because it requires this model, perhaps it has also contractual implications with the user if the model is broken, and therefore it is correct for the client to reject the answer if it doesn't support the tariff-time-change mechanism. It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP and at the next attempt change the billing model if possible. However, typically an agreement between DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. [A.M.] I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard. I see you just proposed a couple of options: 1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER" 2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server" I may also add another straight forward one, 3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client. Is there any other options that the group may think applicable to this issue? Ahmad Marco -----Original Message----- From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com] Sent: 08 June, 2004 15:51 To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change So far the only comment received is from Peter. Does this mean that every one agrees that this is a problem that needs to be fixed. If so, what do you think the solution should be? Regards, Ahmad -----Original Message----- From: Muhanna, Ahmad [RICH2:2Q30:EXCH] Sent: Friday, June 04, 2004 8:59 AM To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Thanks Peter, Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support. Thanks again. Regards, Ahmad -----Original Message----- From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] Sent: Friday, June 04, 2004 8:48 AM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change I think the DCC specification is correct regarding the tariff change mechanism. If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time, which means that Tariff-Time-Change is not to be sent. This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not. If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support tariff change mechanism. It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed). / Peter -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna Sent: den 4 juni 2004 15:15 To: aaa-wg@merit.edu Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com' Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change Hi all, According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server. " The Diameter credit-control server and client MAY optionally support a tariff change mechanism. The Diameter credit-control server may include a Tariff-Time-Change AVP in the answer message. " On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included. Under section 5.1, it reads: " If a client does not support the tariff change mechanism, and it receives a CCA message carrying the Tariff-Time-Change AVP, it MUST terminate the credit control session, giving a reason of DIAMETER_BAD_ANSWER in the Termination-Cause AVP. " The problem I see is the following: There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not. This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not. Am I making sense here? Your thoughts please. Thanks, Ahmad ------_=_NextPart_001_01C44E20.F28B72BD Content-Type: text/html Message
Hi Marco,
comments inline..

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, June 09, 2004 7:43 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Maddireddi, Satheesh [RICH2:2Q40:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi Ahmad,
 
it seems you didn't get my point.  What is indicated in the draft is that SLA is expected to cover bla bla bla...., and this should be enough
other options are not needed.
 
Finally, the only changes allowed at this point are major bug fixing and your proposal doesn't fall within this category. So, new termination
causes will not be added in this DCC version unless explicitely requested by IESG. 
 
[A.M.]
I still believe a new cause value is a much better choice and needed.
But, if it is too late at this point, let us hope that IESG request that otherwise, we can forget about it.
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Ahmad Muhanna
Sent: 09 June, 2004 15:10
To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
Please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; mgrayson@cisco.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu; peter.zackrisson@ericsson.com
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think what really happen is that the user signs a contract with a service provider, often referred as subscription.
The contract typically states the pricing structure for the services, including tariff time changes, when and where
certain conditions are  applicable etc. Therefore, whether tariff time changes are applicable when roaming to a
given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to
a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that
tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies
on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing
additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most
cases the server won't accept to change the billing model agreed beforehand with the user, the service will most
likely be denied in any case.
 
[A.M.]
I agree.
Please see comments below.
 
We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is reasonable to expect that there will exist a service level
   agreement between providers of the credit control client and the
   credit control server covering the charging, services offered,
   roaming agreements, agreed rating input, etc.
     
[A.M.]
I think this probably enough to cover the static configuration portion of it.
 
"covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in
one section rather than repeating the same text for all the optional features along the document, there is nothing left to
individual interpretation or assumptions as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns
upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe
is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be changed to a specific one and not so generic.
I do not think it is too late to propose a new cause value as "tariff change not supported".
It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client.
 
The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually
the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to
the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the
request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the
option to open a credit control session for each of the requested services. As discussed above this won't be effective in case
of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported"
since you cannot change the beforehand agreed charging model with the user. 
 
[A.M.]
please see comments above. 
 
Regards
Marco
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of ext Satheesh Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants.
 
Regards,
Satheesh

 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Tuesday, June 08, 2004 9:08 AM
To: 'marco.stura@nokia.com'; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
please see comments inline.

Regards,
Ahmad

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; peter.zackrisson@ericsson.com
Cc: Harri.Hakala@ericsson.com; Leena.Mattila@ericsson.com; juha-pekka.koskinen@nokia.com; john.loughney@nokia.com; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps
it has also contractual implications with the user if the model is broken, and therefore it is correct for
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change.
The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"
2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one,
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 
-----Original Message-----
From: ext Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Cc: 'Harri.Hakala@ericsson.com'; 'Leena.Mattila@ericsson.com'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

So far the only comment received is from Peter.
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards,
Ahmad

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH]
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC Servers are always aware of all DCC clients capabilities with respect to Tariff-Time-Change mechanism support.
 
Thanks again.

Regards,
Ahmad

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com]
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

I think the DCC specification is correct regarding the tariff change mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging model (instead the charging model should be changed).
 
/ Peter
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); 'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com'; 'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

Hi all,

According to the DCC draft under section 5.1, support of Tariff-Time-Change is optional by the DCC client and Server.

"
   The Diameter credit-control server and client MAY optionally support
   a tariff change mechanism. The Diameter credit-control server may
   include a Tariff-Time-Change AVP in the answer message.
"

On the other hand and under the same section, it mandates the DCC client which does not support this functionality to terminate the DCC session if it receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads:
"
   If a client does not support the tariff change mechanism, and it
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST
   terminate the credit control session, giving a reason of
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP.
"

The problem I see is the following:
There is a very good possibility that a DCC server supports Tariff-Time-Change and DCC Client does not.
This may cause a denial of service for an end-user which home Diameter CC server supports Tariff-Time-Change mechanism while it is at an access where DCC client does not.

Am I making sense here?
Your thoughts please.


Thanks,
Ahmad

------_=_NextPart_001_01C44E20.F28B72BD-- From owner-aaa-wg@merit.edu Wed Jun 9 09:51:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15606 for ; Wed, 9 Jun 2004 09:51:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28F6391201; Wed, 9 Jun 2004 09:50:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E07D491247; Wed, 9 Jun 2004 09:50:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B210791201 for ; Wed, 9 Jun 2004 09:50:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A13ED59300; Wed, 9 Jun 2004 09:50:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id E1BB3598A4 for ; Wed, 9 Jun 2004 09:50:54 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59Doqx19862; Wed, 9 Jun 2004 16:50:52 +0300 (EET DST) X-Scanned: Wed, 9 Jun 2004 16:50:04 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i59Do4QY002640; Wed, 9 Jun 2004 16:50:04 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00Hb4xIX; Wed, 09 Jun 2004 16:50:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i59DnwH07344; Wed, 9 Jun 2004 16:49:58 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 16:49:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 9 Jun 2004 16:49:56 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: RE: [AAA-WG] Diameter and multicast accounting Date: Wed, 9 Jun 2004 16:49:56 +0300 Message-ID: Thread-Topic: [AAA-WG]: [AAA -WG] Diameter and multicast accounting Thread-Index: AcRJeZ9EKwKtOMnCTPeeSusG1o7UVAErttSA From: To: , X-OriginalArrivalTime: 09 Jun 2004 13:49:56.0918 (UTC) FILETIME=[A650AD60:01C44E28] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Yoann, There was some discussion about this at the Minneapolis IETF meeting = last autumn. http://www.ietf.org/proceedings/03nov/slides/aaa-2/index.html You may want to look into this work, this has not be actively discussed = on=20 the AAA WG. John > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Yoann Hinard > Sent: 03 June, 2004 17:24 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [AAA -WG] Diameter and multicast accounting >=20 >=20 > Hello, >=20 > As written in the RFC3588, diameter base protocol is, since its first=20 > versions , intented to work with new generation technologies (IP=20 > mobility, Roaming,...). I would like to know if multicast=20 > authentication=20 > and accounting is not mentionned because it is too obvious=20 > that diameter=20 > framework will support it or because something else is needed=20 > to make it=20 > work. >=20 > I would enjoy every comment which could help me to know how to do=20 > multicast accounting on diameter framework. >=20 > Yoann Hinard > Master Thesis Student > University of Technology > Compi=E8gne > France >=20 >=20 From owner-aaa-wg@merit.edu Mon Jun 14 07:51:19 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23321 for ; Mon, 14 Jun 2004 07:51:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 009299128A; Mon, 14 Jun 2004 07:51:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C21289128C; Mon, 14 Jun 2004 07:51:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6B3A29128A for ; Mon, 14 Jun 2004 07:51:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 536195977C; Mon, 14 Jun 2004 07:51:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 919A75986D for ; Mon, 14 Jun 2004 07:51:04 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5EBp0224084; Mon, 14 Jun 2004 14:51:00 +0300 (EET DST) X-Scanned: Mon, 14 Jun 2004 14:50:26 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5EBoQ75025826; Mon, 14 Jun 2004 14:50:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 004vDI0m; Mon, 14 Jun 2004 14:50:25 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5EBoOH16009; Mon, 14 Jun 2004 14:50:25 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 14:50:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Date: Mon, 14 Jun 2004 14:50:18 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Thread-Index: AcRJPgEVridbmR8sQt+/B7ODNVNIZwIxpKzw From: To: , Cc: X-OriginalArrivalTime: 14 Jun 2004 11:50:18.0829 (UTC) FILETIME=[C3E7F7D0:01C45205] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Would it simplify things if the messages copied straight=20 from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA)=20 would use Auth-Application-Id 1 (NASREQ) instead? (This way e.g. a translation agent would not need to keep track of whether a PPP session was originally authenticated=20 with CHAP or EAP... but then again, I have not considered this case thoroughly.) I'm also wondering whether copying the ABNF for ACR/ACA is necessary... (presumably, some later document that e.g.=20 defines a new WLAN-specific AVP/attribute would not copy=20 the whole ABNF of all messages; just saying in which messages=20 the AVP can be included would be enough.) Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, June 03, 2004 10:36 AM > To: Bernard Aboba > Cc: Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt >=20 >=20 > Bernard Aboba wrote: >=20 > > This document does not define the ABNF for use with the=20 > ASR, ASA, RAR, > > RAA, STR, or STA commands. This is probably very similar=20 > to the ABNFs > > used with NASREQ, in which case a reference to [NASREQ] may suffice. >=20 > Yes. The document does not even mention these commands > currently. Perhaps a new subsection somewhere under > current Section 3. Also, accounting request ABNF needs > to be defined, and it has one difference to the NASREQ > ABNF, the Accounting-EAP-Auth-Method AVP. >=20 > How about this: >=20 > 3.3 Base and NASREQ Commands >=20 > Where the NASREQ AA-Request (AAR) or AA-Answer (AAA) > commands are used for authorization in conjunction with > EAP (see Section 2.3.3), the Auth-Application-Id AVP > MUST be set to 1 (NASREQ), and the rules and command > ABNF defined in [Diameter NASREQ] MUST be followed. >=20 > Where the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), > Session-Termination-Request (STR),=20 > Session-Termination-Answer (STA), > Abort-Session-Request (ASR) and Abort-Session-Answer (ASA) > are used in conjunction with EAP, the Auth-Application-Id > AVP MUST be set to (EAP). Nevertheless, > the same rules and command ABNF defined in [Diameter NASREQ] > MUST be followed even in this case. >=20 > 3.4. Accounting Commands >=20 > The Accounting-Request (ACR) message [Base], is sent by the NAS, to > report it's session information to a target server downstream. >=20 > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present. If the Vendor-Specific-Application-Id grouped AVP > is present, it must have an Acct-Application-Id inside. > [NOTE: This text is copied from NASREQ. But I don't understand > how the NASREQ or EAP application can have a VSAID.] >=20 > The AVPs listed in the Base MUST be assumed to be present as > approriate. NASREQ and EAP specific accounting AVPs,=20 > SHOULD be present > as described in [Diameter NASREQ] and the rest of this=20 > specification. >=20 > Message Format >=20 > ::=3D < Diameter Header: 271, REQ, PXY > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Accounting-Record-Type } > { Accounting-Record-Number } > [ Acct-Application-Id ] > [ Vendor-Specific-Application-Id ] > [ User-Name ] > [ Accounting-Sub-Session-Id ] > [ Accounting-Session-Id ] > [ Acct-Multi-Session-Id ] > [ Origin-State-Id ] > [ Destination-Host ] > [ Event-Timestamp ] > [ Acct-Delay-Time ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [ NAS-Port ] > [ NAS-Port-Id ] > [ NAS-Port-Type ] > * [ Class ] > [ Service-Type ] > [ Termination-Cause ] > [ Accounting-Input-Octets ] > [ Accounting-Input-Packets ] > [ Accounting-Output-Octets ] > [ Accounting-Output-Packets ] > [ Acct-Authentic ] > [ Accounting-Auth-Method ] > [ Acct-Link-Count ] > [ Acct-Session-Time ] > [ Acct-Tunnel-Connection ] > [ Acct-Tunnel-Packets-Lost ] > [ Callback-Id ] > [ Callback-Number ] > [ Called-Station-Id ] > [ Calling-Station-Id ] > * [ Connection-Info ] > [ Originating-Line-Info ] > [ Authorization-Lifetime ] > [ Session-Timeout ] > [ Idle-Timeout ] > [ Port-Limit ] > [ Accounting-Realtime-Required ] > [ Acct-Interim-Interval ] > * [ Filter-Id ] > * [ NAS-Filter-Rule ] > [ Framed-AppleTalk-Link ] > [ Framed-AppleTalk-Network ] > [ Framed-AppleTalk-Zone ] > [ Framed-Compression ] > [ Framed-Interface-Id ] > [ Framed-IP-Address ] > [ Framed-IP-Netmask ] > * [ Framed-IPv6-Prefix ] > [ Framed-IPv6-Pool ] > * [ Framed-IPv6-Route ] > [ Framed-IPX-Network ] > [ Framed-MTU ] > [ Framed-Pool ] > [ Framed-Protocol ] > * [ Framed-Route ] > [ Framed-Routing ] > * [ Login-IP-Host ] > * [ Login-IPv6-Host ] > [ Login-LAT-Group ] > [ Login-LAT-Node ] > [ Login-LAT-Port ] > [ Login-LAT-Service ] > [ Login-Service ] > [ Login-TCP-Port ] > * [ Accounting-EAP-Auth-Method ] > * [ Tunneling ] > * [ Proxy-Info ] > * [ Route-Record ] > * [ AVP ] >=20 > The Accounting-Answer (ACA) message [Base], is used to=20 > acknowledge an > Accounting-Request command. The Accounting-Answer=20 > command contains > the same Session-Id as the Request. If the Accounting-=20 > Request was > protected by end-to-end security, then the corresponding=20 > ACA message > MUST be protected by end-to-end security. >=20 > Only the target Diameter Server, or home Diameter Server, SHOULD > respond with the Accounting-Answer command. >=20 > One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs > MUST be present, as was in the request. >=20 > The AVPs listed in the Base MUST be assumed to be present as > approriate. NASREQ and EAP specific accounting AVPs,=20 > SHOULD be present > as described in [Diameter NASREQ] and the rest of this=20 > specification. >=20 > Message Format >=20 > ::=3D < Diameter Header: 271, PXY > > < Session-Id > > { Result-Code } > { Origin-Host } > { Origin-Realm } > { Accounting-Record-Type } > { Accounting-Record-Number } > [ Acct-Application-Id ] > [ Vendor-Specific-Application-Id ] > [ User-Name ] > [ Accounting-Sub-Session-Id ] > [ Accounting-Session-Id ] > [ Acct-Multi-Session-Id ] > [ Event-Timestamp ] > [ Error-Reporting-Host ] > [ Origin-State-Id ] > [ NAS-Identifier ] > [ NAS-IP-Address ] > [ NAS-IPv6-Address ] > [ NAS-Port ] > [ NAS-Port-Id ] > [ NAS-Port-Type ] > [ Service-Type ] > [ Termination-Cause ] > [ Accounting-Realtime-Required ] > [ Acct-Interim-Interval ] > * [ Class ] > * [ Proxy-Info ] > * [ Route-Record ] > * [ AVP ] >=20 > > I believe that this application shares many of the same=20 > RADIUS/Diameter > > translation considerations as NASREQ Section 9. It should probably > > explicitly state this, particularly as regards the RADIUS > > Dynamic Authorization considerations described in Sections 9.1.1 and > > 9.2.1 of NASREQ. >=20 > Perhaps this is sufficient: >=20 > Section 9 of [NASREQ] describes basic guidelines that translation > agents may follow when translating between RADIUS and Diameter > protocols. This section gives additional guidelines for=20 > the Diameter > EAP application. >=20 > =3D> >=20 > Section 9 of [NASREQ] describes basic guidelines for translation > agents that translate between RADIUS and Diameter protocols. > These guidelines SHOULD be followed for EAP application as well, > with some additional guidelines given in this section. >=20 > --Jari >=20 From owner-aaa-wg@merit.edu Mon Jun 14 07:56:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23442 for ; Mon, 14 Jun 2004 07:56:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 476E49128D; Mon, 14 Jun 2004 07:56:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14BAF9128E; Mon, 14 Jun 2004 07:56:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCBAE9128D for ; Mon, 14 Jun 2004 07:56:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9D405998D; Mon, 14 Jun 2004 07:56:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.202]) by segue.merit.edu (Postfix) with ESMTP id 0157E59911 for ; Mon, 14 Jun 2004 07:56:33 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 14 Jun 2004 13:52:03 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Jun 2004 13:52:03 +0200 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org, aaa-wg@merit.edu, sip@ietf.org Subject: [AAA-WG]: new version of draft-sterman-aaa-sip Date: Mon, 14 Jun 2004 13:52:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, a new version of the HTTP Digest RADIUS draft is available: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-02.txt Changes from -01 o Replaced Sub-attributes with flat attributes [don't ask] o aligned naming with draft-ietf-aaa-diameter-sip-app-02 o Added how a server must treat unknown attributes. o Added a section 'Migration path to DIAMETER' [input/corrections from AAA WG welcome] o Added an optional attribute for support of the digest scheme described in informational [RFC3310]. o Added a mode of operation where the RADIUS server chooses the nonce. This was required for AKA [RFC3310], but can be useful for ordinary Digest authentication when the qop directive is not used. This required the addition of several attributes. Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt From owner-aaa-wg@merit.edu Mon Jun 14 10:41:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06474 for ; Mon, 14 Jun 2004 10:41:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F6619128C; Mon, 14 Jun 2004 10:41:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 12E899128F; Mon, 14 Jun 2004 10:41:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 196F89128C for ; Mon, 14 Jun 2004 10:41:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0143D598CF; Mon, 14 Jun 2004 10:41:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 38DD1598FD for ; Mon, 14 Jun 2004 10:41:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5EEgBe25991; Mon, 14 Jun 2004 07:42:11 -0700 Date: Mon, 14 Jun 2004 07:42:11 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk My understanding of RFC 3588 is that if you only add *optional* AVPs, then the Application-ID does not change. So if the NASREQ ABNF is valid for a command, then you can (and should) use an Application-Id of NASREQ. Note that an EAP AVP cannot be optional, so commands using EAP payloads need the Diameter EAP Application ID. However, commands that do not use EAP payloads do not need (and in my opinion should not use) the EAP Application-ID. I think this approach makes sense because it follows the "Principle of Least Astonishment" -- if the usage is indistinguishable from NASREQ, why should the application-ID change? On Mon, 14 Jun 2004 Pasi.Eronen@nokia.com wrote: > Hi, > > Would it simplify things if the messages copied straight > from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) > would use Auth-Application-Id 1 (NASREQ) instead? > > (This way e.g. a translation agent would not need to keep > track of whether a PPP session was originally authenticated > with CHAP or EAP... but then again, I have not considered > this case thoroughly.) > > I'm also wondering whether copying the ABNF for ACR/ACA > is necessary... (presumably, some later document that e.g. > defines a new WLAN-specific AVP/attribute would not copy > the whole ABNF of all messages; just saying in which messages > the AVP can be included would be enough.) > > Best regards, > Pasi From owner-aaa-wg@merit.edu Mon Jun 14 11:06:02 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08228 for ; Mon, 14 Jun 2004 11:06:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B287891294; Mon, 14 Jun 2004 11:05:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8603A91295; Mon, 14 Jun 2004 11:05:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3047291294 for ; Mon, 14 Jun 2004 11:05:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17FE25962B; Mon, 14 Jun 2004 11:05:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5BB195964B for ; Mon, 14 Jun 2004 11:05:19 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5EF5F620974; Mon, 14 Jun 2004 18:05:15 +0300 (EET DST) X-Scanned: Mon, 14 Jun 2004 18:03:41 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5EF3fFo025081; Mon, 14 Jun 2004 18:03:41 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00BkzkI5; Mon, 14 Jun 2004 18:03:39 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5EF3cH08641; Mon, 14 Jun 2004 18:03:38 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 18:03:38 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Jun 2004 18:03:37 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Date: Mon, 14 Jun 2004 18:03:37 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt Thread-Index: AcRSHc1ulluWbt04Sjavct1J6VQwBgAAdHrA From: To: Cc: , X-OriginalArrivalTime: 14 Jun 2004 15:03:37.0496 (UTC) FILETIME=[C5401980:01C45220] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Seems logical enough. Would the following text be sufficient? When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used for authorization in conjunction with EAP (see Section 2.3.3), the Auth-Application-Id AVP MUST be set to 1 (NASREQ), and the rules and command ABNF defined in [NASREQ] MUST be followed. Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the Diameter EAP application, they follow the rules in [NASREQ] and use Auth-Application-Id 1. Best regards, Pasi > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, June 14, 2004 5:42 PM > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt >=20 >=20 > My understanding of RFC 3588 is that if you only add=20 > *optional* AVPs, then > the Application-ID does not change. So if the NASREQ ABNF is=20 > valid for a command, then you can (and should) use an=20 > Application-Id of NASREQ. >=20 > Note that an EAP AVP cannot be optional, so commands using EAP > payloads need the Diameter EAP Application ID. However,=20 > commands that do not use EAP payloads do not need (and in my=20 > opinion should not use) the EAP Application-ID. >=20 > I think this approach makes sense because it follows the "Principle of > Least Astonishment" -- if the usage is indistinguishable from > NASREQ, why should the application-ID change? >=20 > On Mon, 14 Jun 2004 Pasi.Eronen@nokia.com wrote: >=20 > > Hi, > > > > Would it simplify things if the messages copied straight > > from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) > > would use Auth-Application-Id 1 (NASREQ) instead? > > > > (This way e.g. a translation agent would not need to keep > > track of whether a PPP session was originally authenticated > > with CHAP or EAP... but then again, I have not considered > > this case thoroughly.) > > > > I'm also wondering whether copying the ABNF for ACR/ACA > > is necessary... (presumably, some later document that e.g. > > defines a new WLAN-specific AVP/attribute would not copy > > the whole ABNF of all messages; just saying in which messages > > the AVP can be included would be enough.) > > > > Best regards, > > Pasi >=20 From owner-aaa-wg@merit.edu Mon Jun 14 11:14:44 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08591 for ; Mon, 14 Jun 2004 11:14:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3D4A91296; Mon, 14 Jun 2004 11:14:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF22B91298; Mon, 14 Jun 2004 11:14:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB89D91296 for ; Mon, 14 Jun 2004 11:14:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93399599E1; Mon, 14 Jun 2004 11:14:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id F2437599D7 for ; Mon, 14 Jun 2004 11:14:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5EFFEl28112 for ; Mon, 14 Jun 2004 08:15:14 -0700 Date: Mon, 14 Jun 2004 08:15:14 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Diameter MIP use of Application-IDs In-Reply-To: <16582.14139.370595.477571@gargle.gargle.HOWL> Message-ID: References: <16575.17425.928288.146156@gargle.gargle.HOWL> <16575.36057.591288.876173@gargle.gargle.HOWL> <40BFFD93.4020306@piuha.net> <16582.14139.370595.477571@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The only point that is not explicitly mentioned in draft-18 but that > is explicit in Jari's text is the MUST requirement for setting the > Application-ID to 4 even in the base commands. However, I think this > should be well understood by a reader who is also familiar with the > base protocol. RFC 3588 says that changing the Application-ID is a last resort: " Should a new Diameter usage scenario find itself unable to fit within an existing application without requiring major changes to the specification, it may be desirable to create a new Diameter application. Major changes to an application include: - Adding new AVPs to the command, which have the "M" bit set. - Requiring a command that has a different number of round trips to satisfy a request (e.g., application foo has a command that requires one round trip, but new application bar has a command that requires two round trips to complete). - Adding support for an authentication method requiring definition of new AVPs for use with the application. Since a new EAP authentication method can be supported within Diameter without requiring new AVPs, addition of EAP methods does not require the creation of a new authentication application. Creation of a new application should be viewed as a last resort. An implementation MAY add arbitrary non-mandatory AVPs to any command defined in an application, including vendor-specific AVPs without needing to define a new application. Please refer to Section 11.1.1 for details." The AMR/AMA and HAR/HAA commands meet this criteria. However, it wouldn't appear to me that the criteria is met for Accounting commands, or for other commands that don't require new mandatory AVPs. We've had this same point come up in Diameter EAP, and even in 3GPP discussions, so it does seem to me that we need to be clear on how Application-IDs are used in all commands. Leaving this "implicit" can lead to confusion. From owner-aaa-wg@merit.edu Mon Jun 14 11:17:42 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08709 for ; Mon, 14 Jun 2004 11:17:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 757CE9129A; Mon, 14 Jun 2004 11:15:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B0689129D; Mon, 14 Jun 2004 11:15:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3517A9129A for ; Mon, 14 Jun 2004 11:15:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 228B7596CF; Mon, 14 Jun 2004 11:15:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id ADD3E59151 for ; Mon, 14 Jun 2004 11:15:45 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 646C38988C; Mon, 14 Jun 2004 18:15:28 +0300 (EEST) Message-ID: <40CDC012.5030808@kolumbus.fi> Date: Mon, 14 Jun 2004 18:11:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt References: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > I think this approach makes sense because it follows the "Principle of > Least Astonishment" -- if the usage is indistinguishable from > NASREQ, why should the application-ID change? If the application ID is NASREQ, there might be another type of astonishment: a session is opened via EAP application and then suddenly deleted via NASREQ. Hmm... But I haven't read Pasi's e-mail yet, will do so later today... --Jari From owner-aaa-wg@merit.edu Mon Jun 14 11:19:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08780 for ; Mon, 14 Jun 2004 11:19:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE0F491355; Mon, 14 Jun 2004 11:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F10191358; Mon, 14 Jun 2004 11:18:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FB9891355 for ; Mon, 14 Jun 2004 11:18:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D61A59562; Mon, 14 Jun 2004 11:18:19 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B3692594C8 for ; Mon, 14 Jun 2004 11:18:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5EFIxA28327; Mon, 14 Jun 2004 08:18:59 -0700 Date: Mon, 14 Jun 2004 08:18:59 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@Nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I think this makes sense. You might make the first paragraph more clear by saying "are used for AUTHORIZATION_ONLY messages in conjunction with EAP (see Section 2.3.3),". On Mon, 14 Jun 2004 Pasi.Eronen@Nokia.com wrote: > > Hi, > > Seems logical enough. Would the following text be sufficient? > > When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands > are used for authorization in conjunction with EAP (see > Section 2.3.3), the Auth-Application-Id AVP MUST be set to 1 > (NASREQ), and the rules and command ABNF defined in [NASREQ] > MUST be followed. > > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer > (RAA), Session-Termination-Request (STR), > Session-Termination-Answer (STA), Abort-Session-Request (ASR), > Abort-Session-Answer (ASA), Accounting-Request (ACR), and > Accounting-Answer (ACA) commands are used together with the > Diameter EAP application, they follow the rules in [NASREQ] > and use Auth-Application-Id 1. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, June 14, 2004 5:42 PM > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt > > > > > > My understanding of RFC 3588 is that if you only add > > *optional* AVPs, then > > the Application-ID does not change. So if the NASREQ ABNF is > > valid for a command, then you can (and should) use an > > Application-Id of NASREQ. > > > > Note that an EAP AVP cannot be optional, so commands using EAP > > payloads need the Diameter EAP Application ID. However, > > commands that do not use EAP payloads do not need (and in my > > opinion should not use) the EAP Application-ID. > > > > I think this approach makes sense because it follows the "Principle of > > Least Astonishment" -- if the usage is indistinguishable from > > NASREQ, why should the application-ID change? > > > > On Mon, 14 Jun 2004 Pasi.Eronen@nokia.com wrote: > > > > > Hi, > > > > > > Would it simplify things if the messages copied straight > > > from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) > > > would use Auth-Application-Id 1 (NASREQ) instead? > > > > > > (This way e.g. a translation agent would not need to keep > > > track of whether a PPP session was originally authenticated > > > with CHAP or EAP... but then again, I have not considered > > > this case thoroughly.) > > > > > > I'm also wondering whether copying the ABNF for ACR/ACA > > > is necessary... (presumably, some later document that e.g. > > > defines a new WLAN-specific AVP/attribute would not copy > > > the whole ABNF of all messages; just saying in which messages > > > the AVP can be included would be enough.) > > > > > > Best regards, > > > Pasi > > > From owner-aaa-wg@merit.edu Mon Jun 14 11:28:04 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09896 for ; Mon, 14 Jun 2004 11:28:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3BC3391290; Mon, 14 Jun 2004 11:27:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F105B91291; Mon, 14 Jun 2004 11:27:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 098B891290 for ; Mon, 14 Jun 2004 11:27:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAA7759151; Mon, 14 Jun 2004 11:27:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 629E7595C8 for ; Mon, 14 Jun 2004 11:27:49 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5EFSUH28831; Mon, 14 Jun 2004 08:28:30 -0700 Date: Mon, 14 Jun 2004 08:28:30 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <40CDC012.5030808@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> <40CDC012.5030808@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If the application ID is NASREQ, there might be another type > of astonishment: a session is opened via EAP application and > then suddenly deleted via NASREQ. Hmm... The goal of the language in RFC 3588 was to avoid creating unnecessary interoperability problems. A given Diameter agent might be only be able to handle certain Application-IDs. For example, a Diameter/RADIUS gateway may be built to handle unsolicited deletion or change of authorization using the NASREQ Application-ID, according to the guidance in [NASREQ]. The EAP application uses the same unsolicited change of authorization/deletion commands with the same ABNF as NASREQ. Changing the Application-Id would break interoperation with the RADIUS/Diameter gateway with no benefits -- the gateway can only handle an Application-Id of NASREQ for unsolicited operations. So it seems to me that if an unsolicited operation conforms to the ABNF in [NASREQ] then it should use an Application-Id of NASREQ -- since a Diameter/RADIUS gateway is defined for those commands for that Application-ID -- and for no other Application-ID. From owner-aaa-wg@merit.edu Mon Jun 14 15:26:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23192 for ; Mon, 14 Jun 2004 15:26:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C4CB9129C; Mon, 14 Jun 2004 15:26:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3748491295; Mon, 14 Jun 2004 15:26:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2627391299 for ; Mon, 14 Jun 2004 15:26:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 119E8599B3; Mon, 14 Jun 2004 15:26:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 490FE599FE for ; Mon, 14 Jun 2004 15:26:42 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 881958989A; Mon, 14 Jun 2004 22:26:40 +0300 (EEST) Message-ID: <40CDFAEB.1090901@kolumbus.fi> Date: Mon, 14 Jun 2004 22:22:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@Nokia.com Cc: aboba@internaut.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt References: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This text is fine, thanks. --Jari Pasi.Eronen@Nokia.com wrote: > Hi, > > Seems logical enough. Would the following text be sufficient? > > When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands > are used for authorization in conjunction with EAP (see > Section 2.3.3), the Auth-Application-Id AVP MUST be set to 1 > (NASREQ), and the rules and command ABNF defined in [NASREQ] > MUST be followed. > > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer > (RAA), Session-Termination-Request (STR), > Session-Termination-Answer (STA), Abort-Session-Request (ASR), > Abort-Session-Answer (ASA), Accounting-Request (ACR), and > Accounting-Answer (ACA) commands are used together with the > Diameter EAP application, they follow the rules in [NASREQ] > and use Auth-Application-Id 1. > > Best regards, > Pasi > > >>-----Original Message----- >>From: ext Bernard Aboba [mailto:aboba@internaut.com] >>Sent: Monday, June 14, 2004 5:42 PM >>To: Eronen Pasi (Nokia-NRC/Helsinki) >>Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu >>Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt >> >> >>My understanding of RFC 3588 is that if you only add >>*optional* AVPs, then >>the Application-ID does not change. So if the NASREQ ABNF is >>valid for a command, then you can (and should) use an >>Application-Id of NASREQ. >> >>Note that an EAP AVP cannot be optional, so commands using EAP >>payloads need the Diameter EAP Application ID. However, >>commands that do not use EAP payloads do not need (and in my >>opinion should not use) the EAP Application-ID. >> >>I think this approach makes sense because it follows the "Principle of >>Least Astonishment" -- if the usage is indistinguishable from >>NASREQ, why should the application-ID change? >> >>On Mon, 14 Jun 2004 Pasi.Eronen@nokia.com wrote: >> >> >>>Hi, >>> >>>Would it simplify things if the messages copied straight >>>from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) >>>would use Auth-Application-Id 1 (NASREQ) instead? >>> >>>(This way e.g. a translation agent would not need to keep >>>track of whether a PPP session was originally authenticated >>>with CHAP or EAP... but then again, I have not considered >>>this case thoroughly.) >>> >>>I'm also wondering whether copying the ABNF for ACR/ACA >>>is necessary... (presumably, some later document that e.g. >>>defines a new WLAN-specific AVP/attribute would not copy >>>the whole ABNF of all messages; just saying in which messages >>>the AVP can be included would be enough.) >>> >>>Best regards, >>>Pasi >> > > From owner-aaa-wg@merit.edu Mon Jun 14 15:27:28 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23322 for ; Mon, 14 Jun 2004 15:27:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4584491299; Mon, 14 Jun 2004 15:26:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F33869129B; Mon, 14 Jun 2004 15:26:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E575791295 for ; Mon, 14 Jun 2004 15:26:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CDA7959A1E; Mon, 14 Jun 2004 15:26:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 47549599B3 for ; Mon, 14 Jun 2004 15:26:42 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5C5988988C; Mon, 14 Jun 2004 22:26:40 +0300 (EEST) Message-ID: <40CDFAE6.6020306@kolumbus.fi> Date: Mon, 14 Jun 2004 22:22:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt References: <052E0C61B69C3741AFA5FE88ACC775A6122431@esebe023.ntc.nokia.com> <40CDC012.5030808@kolumbus.fi> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>If the application ID is NASREQ, there might be another type >>of astonishment: a session is opened via EAP application and >>then suddenly deleted via NASREQ. Hmm... > > > The goal of the language in RFC 3588 was to avoid creating unnecessary > interoperability problems. A given Diameter agent might be only be able > to handle certain Application-IDs. For example, a Diameter/RADIUS gateway > may be built to handle unsolicited deletion or change of authorization using > the NASREQ Application-ID, according to the guidance in [NASREQ]. The EAP > application uses the same unsolicited change of > authorization/deletion commands with the same ABNF as NASREQ. Changing > the Application-Id would break interoperation with the RADIUS/Diameter > gateway with no benefits -- the gateway can only handle an Application-Id > of NASREQ for unsolicited operations. > > So it seems to me that if an unsolicited operation conforms to the ABNF in > [NASREQ] then it should use an Application-Id of NASREQ -- since a > Diameter/RADIUS gateway is defined for those commands for that > Application-ID -- and for no other Application-ID. Ok. --Jari From owner-aaa-wg@merit.edu Mon Jun 14 17:31:33 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04379 for ; Mon, 14 Jun 2004 17:31:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C2BE912AA; Mon, 14 Jun 2004 17:29:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1B8091322; Mon, 14 Jun 2004 17:29:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C299D912AA for ; Mon, 14 Jun 2004 17:29:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B072959B23; Mon, 14 Jun 2004 17:29:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id DA5E859B27 for ; Mon, 14 Jun 2004 17:29:43 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ELTgN16499 for ; Tue, 15 Jun 2004 00:29:42 +0300 (EET DST) X-Scanned: Tue, 15 Jun 2004 00:28:31 +0300 Nokia Message Protector V1.3.30 2004040916 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5ELSVe8005664 for ; Tue, 15 Jun 2004 00:28:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00WOMi3Y; Tue, 15 Jun 2004 00:28:30 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ELSUH16519 for ; Tue, 15 Jun 2004 00:28:30 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Jun 2004 00:28:29 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: draft-ietf-aaa-eap-07 Date: Tue, 15 Jun 2004 00:28:28 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3B1F@esebe023.ntc.nokia.com> Thread-Topic: draft-ietf-aaa-eap-07 Thread-Index: AcRSVojs5UcVA4M9QsGpUoOn1B7Bjg== From: To: X-OriginalArrivalTime: 14 Jun 2004 21:28:29.0854 (UTC) FILETIME=[895E4BE0:01C45256] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I have just submitted version -07 of the Diameter EAP application draft. It should be available from the I-D repository soon; in the meanwhile, a temporary copy and a HTML diff from -06 are available from: http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Best regards, Pasi From owner-aaa-wg@merit.edu Mon Jun 14 19:14:36 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11596 for ; Mon, 14 Jun 2004 19:14:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BBB5C91392; Mon, 14 Jun 2004 19:11:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0270D91395; Mon, 14 Jun 2004 19:11:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AFA791392 for ; Mon, 14 Jun 2004 19:11:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 540D259B23; Mon, 14 Jun 2004 19:11:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id 5A1B559B15 for ; Mon, 14 Jun 2004 19:11:10 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i5ENB1pD027512; Tue, 15 Jun 2004 08:11:01 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i5ENB1Tn026781; Tue, 15 Jun 2004 08:11:01 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id JAA26779 ; Tue, 15 Jun 2004 08:11:01 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id IAA25153; Tue, 15 Jun 2004 08:11:00 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id IAA03383; Tue, 15 Jun 2004 08:11:00 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i5ENAxCR017143; Tue, 15 Jun 2004 08:10:59 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HZB00IY2N28FE@tsbpo1.po.toshiba.co.jp>; Tue, 15 Jun 2004 08:10:58 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Ba0ae-0007bI-00; Mon, 14 Jun 2004 16:10:08 -0700 Date: Mon, 14 Jun 2004 16:10:08 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-reply-to: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> To: Pasi.Eronen@Nokia.com Cc: aboba@internaut.com, jari.arkko@kolumbus.fi, aaa-wg@merit.edu Message-id: <20040614231008.GJ10664@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Maybe this was discussed in the past but why can't we use application id for the base protocol (=0) for RAR, RAA, STR, STA, ASR, ASA, ACR and ACA commands instead of NASREQ's application id? All those commands that are re-defined in the NASREQ draft have no new required AVPs specific to NASREQ. So it does not make sense to me to use NASREQ application id for those messages. Yoshihiro Ohba On Mon, Jun 14, 2004 at 06:03:37PM +0300, Pasi.Eronen@Nokia.com wrote: > > Hi, > > Seems logical enough. Would the following text be sufficient? > > When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands > are used for authorization in conjunction with EAP (see > Section 2.3.3), the Auth-Application-Id AVP MUST be set to 1 > (NASREQ), and the rules and command ABNF defined in [NASREQ] > MUST be followed. > > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer > (RAA), Session-Termination-Request (STR), > Session-Termination-Answer (STA), Abort-Session-Request (ASR), > Abort-Session-Answer (ASA), Accounting-Request (ACR), and > Accounting-Answer (ACA) commands are used together with the > Diameter EAP application, they follow the rules in [NASREQ] > and use Auth-Application-Id 1. > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, June 14, 2004 5:42 PM > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt > > > > > > My understanding of RFC 3588 is that if you only add > > *optional* AVPs, then > > the Application-ID does not change. So if the NASREQ ABNF is > > valid for a command, then you can (and should) use an > > Application-Id of NASREQ. > > > > Note that an EAP AVP cannot be optional, so commands using EAP > > payloads need the Diameter EAP Application ID. However, > > commands that do not use EAP payloads do not need (and in my > > opinion should not use) the EAP Application-ID. > > > > I think this approach makes sense because it follows the "Principle of > > Least Astonishment" -- if the usage is indistinguishable from > > NASREQ, why should the application-ID change? > > > > On Mon, 14 Jun 2004 Pasi.Eronen@nokia.com wrote: > > > > > Hi, > > > > > > Would it simplify things if the messages copied straight > > > from NASREQ (RAR/RAA, STR/STA, ASR/ASA and also ACR/ACA) > > > would use Auth-Application-Id 1 (NASREQ) instead? > > > > > > (This way e.g. a translation agent would not need to keep > > > track of whether a PPP session was originally authenticated > > > with CHAP or EAP... but then again, I have not considered > > > this case thoroughly.) > > > > > > I'm also wondering whether copying the ABNF for ACR/ACA > > > is necessary... (presumably, some later document that e.g. > > > defines a new WLAN-specific AVP/attribute would not copy > > > the whole ABNF of all messages; just saying in which messages > > > the AVP can be included would be enough.) > > > > > > Best regards, > > > Pasi > > From owner-aaa-wg@merit.edu Mon Jun 14 20:53:25 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17213 for ; Mon, 14 Jun 2004 20:53:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0FD591203; Mon, 14 Jun 2004 20:53:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83FD691205; Mon, 14 Jun 2004 20:53:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9054591203 for ; Mon, 14 Jun 2004 20:53:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77FFB59AC8; Mon, 14 Jun 2004 20:53:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id E3C3C59B9E for ; Mon, 14 Jun 2004 20:53:11 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5F0rdE30220; Mon, 14 Jun 2004 17:53:39 -0700 Date: Mon, 14 Jun 2004 17:53:39 -0700 (PDT) From: Bernard Aboba To: Yoshihiro Ohba Cc: Pasi.Eronen@Nokia.com, david@mitton.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-Reply-To: <20040614231008.GJ10664@steelhead> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> <20040614231008.GJ10664@steelhead> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Good point, Yoshi. With respect to RAR/RAA, STR/STA, ASR/ASA and ACR/ACA you are correct that NASREQ defines no new mandatory AVPs, and neither does EAP. So according to the RFC 3588 Appliation ID guidelines it would indeed seem correct to just use the Base Application-ID. As I understand it, MIPv4 does not use RAR/RAA, and does not define any new mandatory AVPs in STR/STA, ASR/ASA or ACR/ACA. So it would seem that MIPv4 should also use the Base Application-ID for those commands. On Mon, 14 Jun 2004, Yoshihiro Ohba wrote: > Maybe this was discussed in the past but why can't we use application > id for the base protocol (=0) for RAR, RAA, STR, STA, ASR, ASA, ACR > and ACA commands instead of NASREQ's application id? All those > commands that are re-defined in the NASREQ draft have no new required > AVPs specific to NASREQ. So it does not make sense to me to use > NASREQ application id for those messages. > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Jun 15 08:24:27 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13577 for ; Tue, 15 Jun 2004 08:24:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDC7291210; Tue, 15 Jun 2004 08:24:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D7DD9121A; Tue, 15 Jun 2004 08:24:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4696091210 for ; Tue, 15 Jun 2004 08:24:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 540DD59BA2; Tue, 15 Jun 2004 08:24:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id 94F0C59B73 for ; Tue, 15 Jun 2004 08:24:10 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i5FCO7pD021707; Tue, 15 Jun 2004 21:24:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i5FCO7cf000520; Tue, 15 Jun 2004 21:24:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id XAA00519 ; Tue, 15 Jun 2004 21:24:07 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id VAA04503; Tue, 15 Jun 2004 21:24:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id VAA11610; Tue, 15 Jun 2004 21:24:05 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i5FCO5CR028292; Tue, 15 Jun 2004 21:24:05 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HZC00E5ONS2K9@tsbpo1.po.toshiba.co.jp>; Tue, 15 Jun 2004 21:24:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BaCyS-0000Dg-00; Tue, 15 Jun 2004 05:23:32 -0700 Date: Tue, 15 Jun 2004 05:23:32 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Fwd: I-D ACTION:draft-ietf-aaa-eap-06.txt In-reply-to: To: Bernard Aboba Cc: Yoshihiro Ohba , Pasi.Eronen@Nokia.com, david@mitton.com, aaa-wg@merit.edu Message-id: <20040615122332.GE30440@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A60227C105@esebe023.ntc.nokia.com> <20040614231008.GJ10664@steelhead> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jun 14, 2004 at 05:53:39PM -0700, Bernard Aboba wrote: > Good point, Yoshi. > > With respect to RAR/RAA, STR/STA, ASR/ASA and ACR/ACA you are correct that > NASREQ defines no new mandatory AVPs, and neither does EAP. So according to the RFC 3588 > Appliation ID guidelines it would indeed seem correct to just use the Base > Application-ID. As I understand it, MIPv4 does not use RAR/RAA, and does > not define any new mandatory AVPs in STR/STA, ASR/ASA or ACR/ACA. So it > would seem that MIPv4 should also use the Base Application-ID for those > commands. Looks good. BTW, I have a correction to my previous comment: For ACR/ACA, application id for Diameter Base Accounting (=3) should be used, while application id for Diameter Common Messages (=0) should be used for RAR/RAA, STR/STA and ASR/ASA. Yoshihiro Ohba > > > On Mon, 14 Jun 2004, Yoshihiro Ohba wrote: > > > Maybe this was discussed in the past but why can't we use application > > id for the base protocol (=0) for RAR, RAA, STR, STA, ASR, ASA, ACR > > and ACA commands instead of NASREQ's application id? All those > > commands that are re-defined in the NASREQ draft have no new required > > AVPs specific to NASREQ. So it does not make sense to me to use > > NASREQ application id for those messages. > > > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Jun 15 16:50:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15604 for ; Tue, 15 Jun 2004 16:50:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7DCF912BB; Tue, 15 Jun 2004 16:49:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8530B912BD; Tue, 15 Jun 2004 16:49:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42A9A912BB for ; Tue, 15 Jun 2004 16:49:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23B0059A7E; Tue, 15 Jun 2004 16:49:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id 1F714599D7 for ; Tue, 15 Jun 2004 16:49:44 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i5FKngpD028200; Wed, 16 Jun 2004 05:49:42 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i5FKngm8015626; Wed, 16 Jun 2004 05:49:42 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA15624 ; Wed, 16 Jun 2004 05:49:42 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA07275; Wed, 16 Jun 2004 05:49:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA04666; Wed, 16 Jun 2004 05:49:41 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i5FKnfCR000854; Wed, 16 Jun 2004 05:49:41 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HZD00I8SB6QLF@tsbpo1.po.toshiba.co.jp>; Wed, 16 Jun 2004 05:49:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BaKrc-0002zy-00; Tue, 15 Jun 2004 13:49:00 -0700 Date: Tue, 15 Jun 2004 13:48:57 -0700 From: Yoshihiro Ohba Subject: [AAA-WG]: vendor-specific-application-id in RFC3588 To: aaa-wg@merit.edu Message-id: <20040615204857.GL30440@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i Sender: owner-aaa-wg@merit.edu Precedence: bulk Section 3 of RFC 3588 says: " Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section 11.3 for the possible values that the application-id may use. The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. " What application-id value should be put to this field for a command of a vendor-specific application for which a Vendor-Specific-Application-Id AVP is expected to appear in the command payload instead of Auth-Application-Id or Acct-Application-Id? As far as I remember, the purpose of including Application-ID in Diameter command header is to enable command dictionary lookup based solely on a command header without need to look into the payload contents. But I don't think this works for vendor-specific applications because vendor id is not carried in command header while the combination of vendor id and application id is needed to uniquely identify a vendor-specific application. Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Jun 16 09:06:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24004 for ; Wed, 16 Jun 2004 09:06:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B4EC91221; Wed, 16 Jun 2004 09:06:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AFEC91225; Wed, 16 Jun 2004 09:06:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C66CA91221 for ; Wed, 16 Jun 2004 09:06:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADBBC59CC7; Wed, 16 Jun 2004 09:06:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by segue.merit.edu (Postfix) with ESMTP id B81AC59CC3 for ; Wed, 16 Jun 2004 09:06:24 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i5GD6NpD021882; Wed, 16 Jun 2004 22:06:23 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i5GD6MKL004575; Wed, 16 Jun 2004 22:06:22 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id YAA04574 ; Wed, 16 Jun 2004 22:06:22 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id WAA24159; Wed, 16 Jun 2004 22:06:22 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id WAA16454; Wed, 16 Jun 2004 22:06:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i5GD6LCR008480; Wed, 16 Jun 2004 22:06:21 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HZE00DPFKEJ0P@tsbpo1.po.toshiba.co.jp>; Wed, 16 Jun 2004 22:06:20 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Baa70-0001KI-00; Wed, 16 Jun 2004 06:05:54 -0700 Date: Wed, 16 Jun 2004 06:05:54 -0700 From: Yoshihiro Ohba Subject: [AAA-WG]: vendor-specific-application-id in RFC3588 (another question) To: aaa-wg@merit.edu Message-id: <20040616130554.GB967@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i Sender: owner-aaa-wg@merit.edu Precedence: bulk Someone indicated to me that according to Section 11.3 of RFC 3588, a vendor-specific applicaiton id is a globally unique id (not unique within a vendor id.) So my previous comment seems to be incorrect. My question now is why simply not use Auth-Application-Id AVP or Acct-Application-Id AVP for vendor-specific application id instead of using Vendor-Specific-Application-Id AVP (which carries Auth-Application-Id or Acct-Application-Id AVP) if vendor-id is not used for identifying an vendor-specific application id? Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu Jun 17 02:55:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05045 for ; Thu, 17 Jun 2004 02:55:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24EEA912D8; Thu, 17 Jun 2004 02:54:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2315912D9; Thu, 17 Jun 2004 02:54:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE7E7912D8 for ; Thu, 17 Jun 2004 02:54:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B259659F8C; Thu, 17 Jun 2004 02:54:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 448FF59F92 for ; Thu, 17 Jun 2004 02:54:56 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EFBE189890 for ; Thu, 17 Jun 2004 09:54:39 +0300 (EEST) Message-ID: <40D13F31.30909@kolumbus.fi> Date: Thu, 17 Jun 2004 09:50:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: E2E-Sequence AVP details in RFC3588 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have gotten questions about the use of the E2E-Sequence AVP in Diameter base RFC. It appears that the E2E-Sequence AVP is a relic from the time that we still believed in CMS-based E2E security in Diameter? I wish I remembered what the discussions on this AVP were, but I don't... Anyway, the questions are: (a) Is the use of the AVP still appropriate in some context? (b) If the type of the AVP is really grouped as the text says, then what AVPs carry the nonce and the counter? (c) If the type should really not have been grouped, is the type then octet string (with subformat)? (d) Should we create an errata entry for this AVP, maybe to suggest that it should not have appeared in the RFC at all? --Jari From owner-aaa-wg@merit.edu Sat Jun 19 14:35:50 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02488 for ; Sat, 19 Jun 2004 14:35:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7FC4591261; Sat, 19 Jun 2004 14:35:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5171791288; Sat, 19 Jun 2004 14:35:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 22FA991261 for ; Sat, 19 Jun 2004 14:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E249859CB3; Sat, 19 Jun 2004 14:35:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 141B459CA5 for ; Sat, 19 Jun 2004 14:35:31 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5JIZOJ18529; Sat, 19 Jun 2004 21:35:24 +0300 (EET DST) X-Scanned: Sat, 19 Jun 2004 21:35:22 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5JIZMWg013943; Sat, 19 Jun 2004 21:35:22 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00RA3NYX; Sat, 19 Jun 2004 21:35:21 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5JIZKH22392; Sat, 19 Jun 2004 21:35:20 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Jun 2004 21:35:20 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Jun 2004 21:35:19 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: FW: New versions of guidelines for Internet-Drafts Date: Sat, 19 Jun 2004 21:35:19 +0300 Message-ID: Thread-Topic: New versions of guidelines for Internet-Drafts Thread-Index: AcRUwPhCghAqYJZGRpGOYTiJKKkd7wA2pmMw From: X-OriginalArrivalTime: 19 Jun 2004 18:35:19.0327 (UTC) FILETIME=[2C3272F0:01C4562C] To: undisclosed-recipients: ; Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, For all drafts submitted, it is a good idea tomake sure your drafts meet the following guidelines. thanks, John > -----Original Message----- > From: ietf-announce-bounces@ietf.org > [mailto:ietf-announce-bounces@ietf.org]On Behalf Of ext Harald > Alvestrand > Sent: 18 June, 2004 01:29 > To: IETF Announcement list > Subject: New versions of guidelines for Internet-Drafts=20 >=20 >=20 > The IESG has emitted new versions of the following guideline=20 > documents: >=20 > "Guidelines to authors of Internet-Drafts" > http://www.ietf.org/ietf/1id-guidelines.txt >=20 > which has been updated to reflect the new IPR policy RFCs (3667 and = 3668): > Note that in this process, we discovered a bug in one of the RFCs; the = document=20 > ontains a temporary fix, but the details of a permanent fix are still = being=20 > worked out on the IPR WG list. >=20 > "Checklist for Internet-Drafts submitted for RFC publication" > http://www.ietf.org/ID-Checklist.html >=20 > This has had a more thorough review/revision, and should be re-read by = all=20 > participants. Note in particular the new language about IANA = considerations. >=20 > (This was actually posted a month ago, but has not been announced to = this list=20 > et, so I am including it in this announcement.) >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce >=20 From owner-aaa-wg@merit.edu Tue Jun 22 04:20:14 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16788 for ; Tue, 22 Jun 2004 04:20:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E8562912C6; Tue, 22 Jun 2004 04:20:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBAA4912C7; Tue, 22 Jun 2004 04:20:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B427C912C6 for ; Tue, 22 Jun 2004 04:20:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A611599C6; Tue, 22 Jun 2004 04:20:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 88B8959938 for ; Tue, 22 Jun 2004 04:20:00 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5M8Jx218870 for ; Tue, 22 Jun 2004 11:19:59 +0300 (EET DST) X-Scanned: Tue, 22 Jun 2004 11:19:05 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5M8J5PC004067 for ; Tue, 22 Jun 2004 11:19:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00dooNLj; Tue, 22 Jun 2004 11:19:04 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5M8J4H08591 for ; Tue, 22 Jun 2004 11:19:04 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Jun 2004 11:18:56 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 22 Jun 2004 11:18:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Application IDs for EAP Date: Tue, 22 Jun 2004 11:18:54 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3B20@esebe023.ntc.nokia.com> Thread-Topic: Application IDs for EAP Thread-Index: AcRYMY6xmJqX3qtORFaIdNF+enZTlQ== From: To: X-OriginalArrivalTime: 22 Jun 2004 08:18:54.0559 (UTC) FILETIME=[8ECBF6F0:01C45831] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Here's proposed text about the application identifiers: When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used = for AUTHORIZE_ONLY messages in conjunction with EAP (see Section 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and the commands follow the rules and ABNF defined in [NASREQ]. Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the Diameter EAP application, they follow the rules in [NASREQ] and [BASE]. The accounting commands use Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). If this is OK, I can submit -08 tomorrow... Best regards, Pasi From owner-aaa-wg@merit.edu Tue Jun 22 11:12:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15241 for ; Tue, 22 Jun 2004 11:12:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0E32912F9; Tue, 22 Jun 2004 11:11:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 704BE91307; Tue, 22 Jun 2004 11:11:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E9DF912F9 for ; Tue, 22 Jun 2004 11:11:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E81B59B86; Tue, 22 Jun 2004 11:11:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 74AEB59B99 for ; Tue, 22 Jun 2004 11:11:37 -0400 (EDT) Received: (cpmta 893 invoked from network); 22 Jun 2004 08:11:36 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 22 Jun 2004 08:11:36 -0700 X-Sent: 22 Jun 2004 15:11:36 GMT Message-Id: <5.2.1.1.2.20040622110841.03bab680@mail.comcast.net> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 22 Jun 2004 11:10:59 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Changes to Diameter NASreq draft 15 & 16 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Edits to draft 15/16 Diameter-Nasreq 6/22/2004 Document Editor: David Mitton Changes in Draft 15 - Update document dates & version - Update David Spence info - Fix Acct-Session-ID in ABNFs - Remove table entry for Termination-Action - Add reference to Base Termination-Cause - Re-add missing code points for NAS-Port-Type - correct header levels for LAT services - Tunnel-Client-Auth-ID, Tunnel-Server-Auth-ID defined as UTF8Strings (Was Unsigned32 in table, OctetString in description) - Tunnel-Private-Group-ID OctetString - Pg 60, Sect 9.1, Session-Timout - Remove phrase "I guess the safest bet is to" ---------- Issues: Issue 431 - Identities in RADIUS Translation, Pasi Eronen 1&2) State attribute should contain Diameter/// 3) State content building should be consistent 4) Fix section 9.3 for Origin-Host to identify NAS source, not gateway 5) Corrected. Though it may introduce an ambiguity in routing. 6) Origin-Realm from NAS FQDN and admin table Changed text in sect 9 wrt to session retention Improve mapping of target identities RADIUS/Diameter - A Session-Id AVP must be created by the agent - Use "/" character to separate Origin-Host and Session-ID in State - Origin-Host AVP should contain best verified info on NAS identity (not the gateway) Issue 451 - Interim vs. STOP Record, Avi Lior a) Compromise - add text to allow Stop/Start as service specific b) Editorial correction Accepted Issue 452 - Accounting Session-Id in ACA Command, Avi Lior Accepted: Corrected AVP name Issue 453 - Problem with Accounting Session-Id and Session-Id, Avi Lior Accepted: Acct-Session-Id cannot be put in Diam Session-Id Acct-Session-Id is an accepted Diameter AVP. A RADIUS/Diameter gateway will have to assign & track Diameter Session-Ids. Issue 454 - Diameter NASREQ conflict with Base, Bernard Aboba Close: Text already changed in draft 14 Issue 457 - Editorial NIT in NASREQ-14, Johan Hermans Accepted: Updated Service-Type list Issue 462 - Typo in NASREQ-14, Ignacio Goyret Accepted: Tunnel-Client-Auth-Id type bug Issue ?? - Section 6.10 restricts use of IP service AVPs to a specific list of Framed-Protocol values, which has changed. Accepted: the list has been removed. Similar list removed from IPX and ARAP sections ======= Changes in Draft 16 Input from List, AD, prior IESG, Process changes - Update document dates & version - Changed Abstract to conform to process of RFC3667 - Added text to Abstract and Overview that RADIUS interactions apply to all Diameter applications. - added reference to UTF-8 reference - clarified sect 9.1 sentence wrt decryption and forwarding of User-Password - Update EAP and CC draft version references - Change IPR and copyright statments to current format per RFC3667 From owner-aaa-wg@merit.edu Tue Jun 22 11:19:51 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15682 for ; Tue, 22 Jun 2004 11:19:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C1FE4912D6; Tue, 22 Jun 2004 11:19:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93420912D3; Tue, 22 Jun 2004 11:19:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6192A912D6 for ; Tue, 22 Jun 2004 11:19:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A13B599D5; Tue, 22 Jun 2004 11:19:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id CF05459937 for ; Tue, 22 Jun 2004 11:19:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5MFJSQ07567; Tue, 22 Jun 2004 08:19:28 -0700 Date: Tue, 22 Jun 2004 08:19:28 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Application IDs for EAP In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3B20@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B20@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Take out "Similiarly, " since different Application-IDs are used. Otherwise it's ok. From owner-aaa-wg@merit.edu Tue Jun 22 11:25:11 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16090 for ; Tue, 22 Jun 2004 11:25:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C197912D3; Tue, 22 Jun 2004 11:24:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17407912D8; Tue, 22 Jun 2004 11:24:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E57F4912D3 for ; Tue, 22 Jun 2004 11:24:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA269599D5; Tue, 22 Jun 2004 11:24:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 055AF59A42 for ; Tue, 22 Jun 2004 11:24:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5MFOuk07856; Tue, 22 Jun 2004 08:24:56 -0700 Date: Tue, 22 Jun 2004 08:24:56 -0700 (PDT) From: Bernard Aboba To: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Changes to Diameter NASreq draft 15 & 16 In-Reply-To: <5.2.1.1.2.20040622110841.03bab680@mail.comcast.net> Message-ID: References: <5.2.1.1.2.20040622110841.03bab680@mail.comcast.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Thanks for posting this. Can you also make the Application-ID changes and submit a -17? On Tue, 22 Jun 2004, David Mitton wrote: > Edits to draft 15/16 Diameter-Nasreq > 6/22/2004 > Document Editor: David Mitton > > > Changes in Draft 15 > - Update document dates & version > - Update David Spence info > - Fix Acct-Session-ID in ABNFs > - Remove table entry for Termination-Action > - Add reference to Base Termination-Cause > - Re-add missing code points for NAS-Port-Type > - correct header levels for LAT services > > - Tunnel-Client-Auth-ID, Tunnel-Server-Auth-ID defined as UTF8Strings > (Was Unsigned32 in table, OctetString in description) > - Tunnel-Private-Group-ID OctetString > - Pg 60, Sect 9.1, Session-Timout - Remove phrase "I guess the safest > bet is to" > > ---------- > Issues: > > Issue 431 - Identities in RADIUS Translation, Pasi Eronen > > 1&2) State attribute should contain > Diameter/// > > 3) State content building should be consistent > 4) Fix section 9.3 for Origin-Host to identify NAS source, not gateway > 5) Corrected. Though it may introduce an ambiguity in routing. > 6) Origin-Realm from NAS FQDN and admin table > > Changed text in sect 9 wrt to session retention > Improve mapping of target identities RADIUS/Diameter > > - A Session-Id AVP must be created by the agent > - Use "/" character to separate Origin-Host and Session-ID in State > > - Origin-Host AVP should contain best verified info on NAS identity > (not the gateway) > > Issue 451 - Interim vs. STOP Record, Avi Lior > a) Compromise - add text to allow Stop/Start as service specific > b) Editorial correction Accepted > > > Issue 452 - Accounting Session-Id in ACA Command, Avi Lior > Accepted: Corrected AVP name > > Issue 453 - Problem with Accounting Session-Id and Session-Id, Avi Lior > Accepted: Acct-Session-Id cannot be put in Diam Session-Id > Acct-Session-Id is an accepted Diameter AVP. > A RADIUS/Diameter gateway will have to assign & track > Diameter Session-Ids. > > Issue 454 - Diameter NASREQ conflict with Base, Bernard Aboba > Close: Text already changed in draft 14 > > Issue 457 - Editorial NIT in NASREQ-14, Johan Hermans > Accepted: Updated Service-Type list > > Issue 462 - Typo in NASREQ-14, Ignacio Goyret > Accepted: Tunnel-Client-Auth-Id type bug > > Issue ?? - Section 6.10 restricts use of IP service AVPs to a specific > list of Framed-Protocol values, which has changed. > Accepted: the list has been removed. > Similar list removed from IPX and ARAP sections > > ======= > Changes in Draft 16 > > Input from List, AD, prior IESG, Process changes > > - Update document dates & version > - Changed Abstract to conform to process of RFC3667 > - Added text to Abstract and Overview that RADIUS interactions apply > to all Diameter applications. > - added reference to UTF-8 reference > - clarified sect 9.1 sentence wrt decryption and forwarding of > User-Password > - Update EAP and CC draft version references > - Change IPR and copyright statments to current format > per RFC3667 > > From owner-aaa-wg@merit.edu Tue Jun 22 11:33:20 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17502 for ; Tue, 22 Jun 2004 11:33:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2510991307; Tue, 22 Jun 2004 11:30:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E16A89130C; Tue, 22 Jun 2004 11:30:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B3BC991307 for ; Tue, 22 Jun 2004 11:30:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7DBB59741; Tue, 22 Jun 2004 11:30:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 1B55659937 for ; Tue, 22 Jun 2004 11:30:06 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5MFTwK17213; Tue, 22 Jun 2004 11:29:58 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 11:29:59 -0400 Message-ID: From: "Christopher Richards" To: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Tue, 22 Jun 2004 11:29:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4586D.C1E869B0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4586D.C1E869B0 Content-Type: text/plain Hello All, So am I correct in reading this thread: the application-id in any message is not the application to which the message is destined in the peer, but instead the application-id that the message was defined in the appropriate RFC or spec? E.g. If the DCCA server application sends an ASR to the DCCA client, then the application-id in the ASR is not DCCA but the base Diameter application-id (0)? If that is the case, what is the reasoning behind this? Chris Richards. -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: June 22, 2004 4:19 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Application IDs for EAP Hi, Here's proposed text about the application identifiers: When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used for AUTHORIZE_ONLY messages in conjunction with EAP (see Section 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and the commands follow the rules and ABNF defined in [NASREQ]. Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), Session-Termination-Request (STR), Session-Termination-Answer (STA), Abort-Session-Request (ASR), Abort-Session-Answer (ASA), Accounting-Request (ACR), and Accounting-Answer (ACA) commands are used together with the Diameter EAP application, they follow the rules in [NASREQ] and [BASE]. The accounting commands use Application Identifier value of 3 (Diameter Base Accounting); the others use 0 (Diameter Common Messages). If this is OK, I can submit -08 tomorrow... Best regards, Pasi ------_=_NextPart_001_01C4586D.C1E869B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Hello All,

So am I correct in reading this thread: the = application-id in any message is not the application to which the = message is destined in the peer, but instead the application-id that = the message was defined in the appropriate RFC or spec?

E.g. If the DCCA server application sends an ASR to = the DCCA client, then the application-id in the ASR is not DCCA but the = base Diameter application-id (0)?

If that is the case, what is the reasoning behind = this?

Chris Richards.

-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] =
Sent: June 22, 2004 4:19 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Application IDs for EAP



Hi,

Here's proposed text about the application = identifiers:

   When the NASREQ AA-Request (AAR) or = AA-Answer (AAA) commands are used
   for AUTHORIZE_ONLY messages in = conjunction with EAP (see Section
   2.3.3), an Application Identifier value = of 1 (NASREQ) is used, and
   the commands follow the rules and ABNF = defined in [NASREQ].

   Similarly, when the Re-Auth-Request = (RAR), Re-Auth-Answer (RAA),
   Session-Termination-Request (STR), = Session-Termination-Answer (STA),
   Abort-Session-Request (ASR), = Abort-Session-Answer (ASA),
   Accounting-Request (ACR), and = Accounting-Answer (ACA) commands are
   used together with the Diameter EAP = application, they follow the
   rules in [NASREQ] and [BASE].  The = accounting commands use
   Application Identifier value of 3 = (Diameter Base Accounting); the
   others use 0 (Diameter Common = Messages).

If this is OK, I can submit -08 tomorrow...

Best regards,
Pasi

------_=_NextPart_001_01C4586D.C1E869B0-- From owner-aaa-wg@merit.edu Tue Jun 22 12:44:40 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21689 for ; Tue, 22 Jun 2004 12:44:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1364391258; Tue, 22 Jun 2004 12:44:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D91CA9125A; Tue, 22 Jun 2004 12:44:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E38C391258 for ; Tue, 22 Jun 2004 12:44:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D13E959BE6; Tue, 22 Jun 2004 12:44:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 56CA959BCD for ; Tue, 22 Jun 2004 12:44:27 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5MGiKu12434; Tue, 22 Jun 2004 09:44:20 -0700 Date: Tue, 22 Jun 2004 09:44:20 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > E.g. If the DCCA server application sends an ASR to the DCCA client, then > the application-id in the ASR is not DCCA but the base Diameter > application-id (0)? Correct. > If that is the case, what is the reasoning behind this? The issue is that Diameter agents (such as RADIUS/Diameter gateways) will fail if an unknown Application-ID is included. In cases where no new mandatory AVPs are added, using an existing Application-ID is required by RFC 3588, since otherwise interoperability would be broken without any benefits. From owner-aaa-wg@merit.edu Tue Jun 22 13:35:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03641 for ; Tue, 22 Jun 2004 13:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C4619125A; Tue, 22 Jun 2004 13:34:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27B539125B; Tue, 22 Jun 2004 13:34:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DF4AE9125A for ; Tue, 22 Jun 2004 13:34:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD64859AF4; Tue, 22 Jun 2004 13:34:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 3B1BE59A53 for ; Tue, 22 Jun 2004 13:34:52 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5MHYWl21739; Tue, 22 Jun 2004 13:34:32 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 13:34:28 -0400 Message-ID: From: "Christopher Richards" To: "'Bernard Aboba'" Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Tue, 22 Jun 2004 13:34:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4587F.2653C008" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4587F.2653C008 Content-Type: text/plain Thanks Bernard, So, when a peer advertises support for a Diameter application in the Capabilities exchange, should it also include support for applications that it uses messages from - even though the application may not be supported, just the use of the message by the application. Chris. -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: June 22, 2004 12:44 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP > E.g. If the DCCA server application sends an ASR to the DCCA client, > then the application-id in the ASR is not DCCA but the base Diameter > application-id (0)? Correct. > If that is the case, what is the reasoning behind this? The issue is that Diameter agents (such as RADIUS/Diameter gateways) will fail if an unknown Application-ID is included. In cases where no new mandatory AVPs are added, using an existing Application-ID is required by RFC 3588, since otherwise interoperability would be broken without any benefits. ------_=_NextPart_001_01C4587F.2653C008 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Thanks Bernard,

So, when a peer advertises support for a Diameter = application in the Capabilities exchange, should it also include = support for applications that it uses messages from - even though the = application may not be supported, just the use of the message by the = application.

Chris.

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] =
Sent: June 22, 2004 12:44 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for = EAP


> E.g. If the DCCA server application sends an ASR = to the DCCA client,
> then the application-id in the ASR is not DCCA = but the base Diameter
> application-id (0)?

Correct.

> If that is the case, what is the reasoning = behind this?

The issue is that Diameter agents (such as = RADIUS/Diameter gateways) will fail if an unknown Application-ID is = included.  In cases where no new mandatory AVPs are added, using = an existing Application-ID is required by RFC 3588, since otherwise = interoperability would be broken without any benefits.

------_=_NextPart_001_01C4587F.2653C008-- From owner-aaa-wg@merit.edu Tue Jun 22 14:58:38 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18840 for ; Tue, 22 Jun 2004 14:58:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AB2B09125B; Tue, 22 Jun 2004 14:58:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74A839125D; Tue, 22 Jun 2004 14:58:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 831939125B for ; Tue, 22 Jun 2004 14:58:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4EA4F59A35; Tue, 22 Jun 2004 14:58:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 9051D599ED for ; Tue, 22 Jun 2004 14:58:20 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5MIwDl20198; Tue, 22 Jun 2004 11:58:13 -0700 Date: Tue, 22 Jun 2004 11:58:12 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Yes. Otherwise the Diameter peer won't know that it can send messages with that Application-Id to and from that peer. On Tue, 22 Jun 2004, Christopher Richards wrote: > Thanks Bernard, > > So, when a peer advertises support for a Diameter application in the > Capabilities exchange, should it also include support for applications that > it uses messages from - even though the application may not be supported, > just the use of the message by the application. > > Chris. From owner-aaa-wg@merit.edu Tue Jun 22 15:09:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20550 for ; Tue, 22 Jun 2004 15:09:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 457D091228; Tue, 22 Jun 2004 15:09:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 111CE9125D; Tue, 22 Jun 2004 15:09:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C884B91228 for ; Tue, 22 Jun 2004 15:09:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B2D0259949; Tue, 22 Jun 2004 15:09:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 86730599C4 for ; Tue, 22 Jun 2004 15:09:28 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5MJ9DK26679; Tue, 22 Jun 2004 15:09:13 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 15:09:13 -0400 Message-ID: From: "Christopher Richards" To: "'Bernard Aboba'" Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Tue, 22 Jun 2004 15:09:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4588C.5FDFCBC0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4588C.5FDFCBC0 Content-Type: text/plain But how does the other end know that the advertised application support is limited to a message(s) only and the support is not for the application as a whole? My point was: shouldn't an application that originates a message put it's application-id in the message so that the message is delivered to the correct application at the endpoint. A base message may include AVPs that are defined by the application that originated the message - as such, the base application will not (and should not) know about the application AVPs - so how does it know how to handle them? -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: June 22, 2004 2:58 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Yes. Otherwise the Diameter peer won't know that it can send messages with that Application-Id to and from that peer. On Tue, 22 Jun 2004, Christopher Richards wrote: > Thanks Bernard, > > So, when a peer advertises support for a Diameter application in the > Capabilities exchange, should it also include support for applications > that it uses messages from - even though the application may not be > supported, just the use of the message by the application. > > Chris. ------_=_NextPart_001_01C4588C.5FDFCBC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

But how does the other end know that the advertised = application support is limited to a message(s) only and the support is = not for the application as a whole?

My point was: shouldn't an application that = originates a message put it's application-id in the message so that the = message is delivered to the correct application at the endpoint. A base = message may include AVPs that are defined by the application that = originated the message - as such, the base application will not (and = should not) know about the application AVPs - so how does it know how = to handle them?

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] =
Sent: June 22, 2004 2:58 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for = EAP


Yes.  Otherwise the Diameter peer won't know = that it can send messages with that Application-Id to and from that = peer.

On Tue, 22 Jun 2004, Christopher Richards = wrote:

> Thanks Bernard,
>
> So, when a peer advertises support for a = Diameter application in the
> Capabilities exchange, should it also include = support for applications
> that it uses messages from - even though the = application may not be
> supported, just the use of the message by the = application.
>
> Chris.

------_=_NextPart_001_01C4588C.5FDFCBC0-- From owner-aaa-wg@merit.edu Tue Jun 22 16:02:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24813 for ; Tue, 22 Jun 2004 16:02:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02C059125F; Tue, 22 Jun 2004 16:02:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C059B91262; Tue, 22 Jun 2004 16:02:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEDBA9125F for ; Tue, 22 Jun 2004 16:02:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB2CB5994C; Tue, 22 Jun 2004 16:02:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 4634B599D5 for ; Tue, 22 Jun 2004 16:02:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5MK2EA23972; Tue, 22 Jun 2004 13:02:14 -0700 Date: Tue, 22 Jun 2004 13:02:14 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > But how does the other end know that the advertised application support is > limited to a message(s) only and the support is not for the application as a > whole? It doesn't. But that's not an issue if we are talking about advertising support for Diameter Base Common Messages. From owner-aaa-wg@merit.edu Tue Jun 22 16:27:22 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26188 for ; Tue, 22 Jun 2004 16:27:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C4B591263; Tue, 22 Jun 2004 16:27:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49C1791266; Tue, 22 Jun 2004 16:27:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D37991263 for ; Tue, 22 Jun 2004 16:27:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED33359A35; Tue, 22 Jun 2004 16:27:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 930DC59151 for ; Tue, 22 Jun 2004 16:27:07 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5MKQvK18604; Tue, 22 Jun 2004 16:26:57 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 22 Jun 2004 16:26:57 -0400 Message-ID: From: "Christopher Richards" To: "'Bernard Aboba'" Cc: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Tue, 22 Jun 2004 16:26:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45897.3F697D28" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45897.3F697D28 Content-Type: text/plain But from RFC 3588, section 3:- Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section 11.3 for the possible values that the application-id may use. The application-id in the header MUST be the same as what is contained in any relevant AVPs contained in the message. From that, I take it that if the Acct-Application-Id AVP contained value x, then the command header will also contain value x. And if the command contained AVPs that were relevant to application y, then the command header would contain application-id = y also. -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: June 22, 2004 4:02 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP > But how does the other end know that the advertised application > support is limited to a message(s) only and the support is not for the > application as a whole? It doesn't. But that's not an issue if we are talking about advertising support for Diameter Base Common Messages. ------_=_NextPart_001_01C45897.3F697D28 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

But from RFC 3588, section 3:-

Application-ID
      Application-ID is = four octets and is used to identify to which
      application the = message is applicable for.  The application can be
      an authentication = application, an accounting application or a
      vendor specific = application.  See Section 11.3 for the possible
      values that the = application-id may use.

      The application-id in = the header MUST be the same as what is
      contained in any = relevant AVPs contained in the message.

From that, I take it that if the Acct-Application-Id = AVP contained value x, then the command header will also contain value = x. And if the command contained AVPs that were relevant to application = y, then the command header would contain application-id =3D y = also.

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com] =
Sent: June 22, 2004 4:02 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for = EAP


> But how does the other end know that the = advertised application
> support is limited to a message(s) only and the = support is not for the
> application as a whole?

It doesn't.  But that's not an issue if we are = talking about advertising support for Diameter Base Common = Messages.

------_=_NextPart_001_01C45897.3F697D28-- From owner-aaa-wg@merit.edu Wed Jun 23 05:23:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10586 for ; Wed, 23 Jun 2004 05:23:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 096DE912DC; Wed, 23 Jun 2004 05:23:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0D5E912DD; Wed, 23 Jun 2004 05:23:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C34B9912DC for ; Wed, 23 Jun 2004 05:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9EF159DBC; Wed, 23 Jun 2004 05:23:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3B15459D84 for ; Wed, 23 Jun 2004 05:23:31 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D043589817; Wed, 23 Jun 2004 12:23:14 +0300 (EEST) Message-ID: <40D94AEE.3020403@kolumbus.fi> Date: Wed, 23 Jun 2004 12:18:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Application IDs for EAP References: <052E0C61B69C3741AFA5FE88ACC775A6010C3B20@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3B20@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This text looks good (with Bernard's correction). Ship it. --Jari Pasi.Eronen@nokia.com wrote: > Hi, > > Here's proposed text about the application identifiers: > > When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used > for AUTHORIZE_ONLY messages in conjunction with EAP (see Section > 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and > the commands follow the rules and ABNF defined in [NASREQ]. > > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), > Session-Termination-Request (STR), Session-Termination-Answer (STA), > Abort-Session-Request (ASR), Abort-Session-Answer (ASA), > Accounting-Request (ACR), and Accounting-Answer (ACA) commands are > used together with the Diameter EAP application, they follow the > rules in [NASREQ] and [BASE]. The accounting commands use > Application Identifier value of 3 (Diameter Base Accounting); the > others use 0 (Diameter Common Messages). > > If this is OK, I can submit -08 tomorrow... > > Best regards, > Pasi > From owner-aaa-wg@merit.edu Wed Jun 23 10:05:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00932 for ; Wed, 23 Jun 2004 10:05:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E0B391232; Wed, 23 Jun 2004 10:04:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2395D91257; Wed, 23 Jun 2004 10:04:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B62291232 for ; Wed, 23 Jun 2004 10:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E30C459E20; Wed, 23 Jun 2004 10:04:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 4B02059E0B for ; Wed, 23 Jun 2004 10:04:47 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NE4ii20406; Wed, 23 Jun 2004 10:04:44 -0400 (EDT) Date: Wed, 23 Jun 2004 10:04:44 -0400 (EDT) Message-Id: <200406231404.i5NE4ii20406@zrtps06s.nortelnetworks.com> Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jun 2004 10:04:44 -0400 Received: from nortelnetworks.com ([47.102.177.127] RDNS failed) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 23 Jun 2004 09:04:26 -0500 From: Joe Harvell To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk Microsoft Mail Internet Headers Version 2.0 Message-ID: <40D98D8E.1000900@nortelnetworks.com> Date: Wed, 23 Jun 2004 14:02:54 +0000 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [AAA-WG]: Application IDs for EAP References: <40D94AEE.3020403@kolumbus.fi> In-Reply-To: <40D94AEE.3020403@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: harvell@nortelnetworks.com X-OriginalArrivalTime: 23 Jun 2004 14:04:27.0075 (UTC) FILETIME=[FEC09930:01C4592A] There is still the issue of the MUST requirement in RFC 3588. From Section 3 (Diameter Header): Application-ID Application-ID is four octets and is used to identify to which application the message is applicable for. The application can be an authentication application, an accounting application or a vendor specific application. See Section 11.3 for the possible values that the application-id may use. ****The application-id in the header MUST be the same as what is contained in any relevant AVPs contianed in the message.**** The ASR, RAR and STR each require an Auth-Applicaiton-Id. I would say the above text requires it to be the same as the Application-ID in the header. I am unsure if the text below suggests using 0 in the Auth-Application-Id AVPs for RAR, ASR and STA. If it does not, then it violates the MUST requirement above. If it does, it should state that it does. Jari Arkko wrote: > This text looks good (with Bernard's correction). > Ship it. > > --Jari > > Pasi.Eronen@nokia.com wrote: > > Hi, > > > > Here's proposed text about the application identifiers: > > > > When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are > used > > for AUTHORIZE_ONLY messages in conjunction with EAP (see Section > > 2.3.3), an Application Identifier value of 1 (NASREQ) is used, and > > the commands follow the rules and ABNF defined in [NASREQ]. > > > > Similarly, when the Re-Auth-Request (RAR), Re-Auth-Answer (RAA), > > Session-Termination-Request (STR), Session-Termination-Answer (STA), > > Abort-Session-Request (ASR), Abort-Session-Answer (ASA), > > Accounting-Request (ACR), and Accounting-Answer (ACA) commands are > > used together with the Diameter EAP application, they follow the > > rules in [NASREQ] and [BASE]. The accounting commands use > > Application Identifier value of 3 (Diameter Base Accounting); the > > others use 0 (Diameter Common Messages). > > > > If this is OK, I can submit -08 tomorrow... > > > > Best regards, > > Pasi > > > From owner-aaa-wg@merit.edu Thu Jun 24 09:52:34 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12721 for ; Thu, 24 Jun 2004 09:52:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70DB591300; Thu, 24 Jun 2004 09:52:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3194991303; Thu, 24 Jun 2004 09:52:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 264E691300 for ; Thu, 24 Jun 2004 09:52:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B68E5A0D0; Thu, 24 Jun 2004 09:52:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 1C48D5A0CB for ; Thu, 24 Jun 2004 09:52:19 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ODqH218253; Thu, 24 Jun 2004 16:52:17 +0300 (EET DST) X-Scanned: Thu, 24 Jun 2004 16:51:48 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i5ODpmr8021268; Thu, 24 Jun 2004 16:51:48 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ZCdpsT; Thu, 24 Jun 2004 16:51:46 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5ODpeH18516; Thu, 24 Jun 2004 16:51:40 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Jun 2004 16:51:33 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: [AAA-WG]: Application IDs for EAP Date: Thu, 24 Jun 2004 16:51:34 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C112@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Application IDs for EAP Thread-Index: AcRYl1DQho54F9r2Q7uAymrShWP+QgBWlcvQ From: To: , X-OriginalArrivalTime: 24 Jun 2004 13:51:33.0880 (UTC) FILETIME=[5C4E2780:01C459F2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Christopher Richards wrote: > > But from RFC 3588, section 3:-=20 > > Application-ID=20 > Application-ID is four octets and is used to identify to which=20 > application the message is applicable for. The application can be=20 > an authentication application, an accounting application or a=20 > vendor specific application. See Section 11.3 for the possible=20 > values that the application-id may use.=20 > > The application-id in the header MUST be the same as what is=20 > contained in any relevant AVPs contained in the message.=20 > > From that, I take it that if the Acct-Application-Id AVP > contained value x, then the command header will also contain > value x. And if the command contained AVPs that were relevant > to application y, then the command header would contain > application-id =3D y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs=20 are used for a completely different purpose), this makes me wonder=20 why the AVP was included at all?=20 Or are there cases where the values could be different? Best regards, Pasi From owner-aaa-wg@merit.edu Thu Jun 24 11:31:48 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21662 for ; Thu, 24 Jun 2004 11:31:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 875AD9130A; Thu, 24 Jun 2004 11:08:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E40B9130B; Thu, 24 Jun 2004 11:08:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFEF49130A for ; Thu, 24 Jun 2004 11:08:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D664659F9F; Thu, 24 Jun 2004 11:08:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 4545A5A0A9 for ; Thu, 24 Jun 2004 11:08:23 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5OF8FQ21842; Thu, 24 Jun 2004 11:08:16 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 24 Jun 2004 11:08:14 -0400 Message-ID: From: "Christopher Richards" To: "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Thu, 24 Jun 2004 11:08:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C459FD.0A382460" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C459FD.0A382460 Content-Type: text/plain Exactly. > Application-ID is four octets and is used to identify to which > application the message is applicable for. This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless. > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. Again. This makes sense. CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application". But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else. Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: June 24, 2004 9:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Christopher Richards wrote: > > But from RFC 3588, section 3:- > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > From that, I take it that if the Acct-Application-Id AVP contained > value x, then the command header will also contain value x. And if the > command contained AVPs that were relevant to application y, then the > command header would contain application-id = y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs are used for a completely different purpose), this makes me wonder why the AVP was included at all? Or are there cases where the values could be different? Best regards, Pasi ------_=_NextPart_001_01C459FD.0A382460 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Exactly.

>   Application-ID is four octets and is = used to identify to which
>   application the message is = applicable for.  

This statement makes sense. Why would any application = put a different applications Id in the message? It would make the = Application-Id in the message header useless.

>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.

Again. This makes sense.

CER and CEA must by definition use the base = application-id (0) in the message header because these messages are = polling the peer for applications supported - so the CER must be sent = to the "base application".

But for all other messages sent by an application to = a peer application, the application-id only makes sense (and complies = to RFC 3588) if it uses the application-id of the application that sent = the message. It makes no sense (and violates 3588) if it contains = anything else.

Now I agree, that the inclusion of the = Acct-Application-Id or Auth-Application-Id AVPs are then redundant in = all messages except CER/CEA since it will be the same as the value in = the message header.

Cheers,
Chris

Tel:    +1 613 763 8031
ESN:    393 8031


-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] =
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for = EAP



Christopher Richards wrote:
>
> But from RFC 3588, section 3:-
>
> Application-ID
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  The application can be
>   an authentication application, an = accounting application or a
>   vendor specific application.  = See Section 11.3 for the possible
>   values that the application-id may = use.
>
>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
>
> From that, I take it that if the = Acct-Application-Id AVP contained
> value x, then the command header will also = contain value x. And if the
> command contained AVPs that were relevant to = application y, then the
> command header would contain application-id =3D = y also.

If the Auth/Acct-Application-Id AVP and command = header always contain the same value (except for CER/CEA, where the = same AVPs

are used for a completely different purpose), this = makes me wonder
why the AVP was included at all?

Or are there cases where the values could be = different?

Best regards,
Pasi

------_=_NextPart_001_01C459FD.0A382460-- From owner-aaa-wg@merit.edu Fri Jun 25 09:38:55 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29637 for ; Fri, 25 Jun 2004 09:38:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DE8A912A4; Fri, 25 Jun 2004 09:38:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 593D0912AA; Fri, 25 Jun 2004 09:38:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE24A912A4 for ; Fri, 25 Jun 2004 09:38:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C283C59EE5; Fri, 25 Jun 2004 09:38:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 5B62059EDA for ; Fri, 25 Jun 2004 09:38:33 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5PDcQV02708; Fri, 25 Jun 2004 09:38:26 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 09:38:27 -0400 Message-ID: From: "Christopher Richards" To: "Christopher Richards" , "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Date: Fri, 25 Jun 2004 09:38:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45AB9.A952E2C0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45AB9.A952E2C0 Content-Type: text/plain Hi Bernard, Jari, Pasi, Joe, So are we all in agreement that the application-id in the message header is the application-id of the application to which it needs to be handled by (i.e. the one that generated the message) as per 3588 requirements. And the only time that the application-id in the message header will be different from that contained in any optional auth-application-id or acct-application-id AVPs is in the CER/CEA messages. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: June 24, 2004 11:08 AM To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Exactly. > Application-ID is four octets and is used to identify to which > application the message is applicable for. This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless. > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. Again. This makes sense. CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application". But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else. Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: June 24, 2004 9:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Christopher Richards wrote: > > But from RFC 3588, section 3:- > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > From that, I take it that if the Acct-Application-Id AVP contained > value x, then the command header will also contain value x. And if the > command contained AVPs that were relevant to application y, then the > command header would contain application-id = y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs are used for a completely different purpose), this makes me wonder why the AVP was included at all? Or are there cases where the values could be different? Best regards, Pasi ------_=_NextPart_001_01C45AB9.A952E2C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Hi Bernard, Jari, Pasi, Joe,

So are we all in agreement that the application-id in = the message header is the application-id of the application to which it = needs to be handled by (i.e. the one that generated the message) as per = 3588 requirements.

And the only time that the application-id in the = message header will be different from that contained in any optional = auth-application-id or acct-application-id AVPs is in the CER/CEA = messages.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031

-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH] =
Sent: June 24, 2004 11:08 AM
To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for = EAP


Exactly.

>   Application-ID is four octets and is = used to identify to which
>   application the message is = applicable for.  

This statement makes sense. Why would any application = put a different applications Id in the message? It would make the = Application-Id in the message header useless.

>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.

Again. This makes sense.
CER and CEA must by definition use the base = application-id (0) in the message header because these messages are = polling the peer for applications supported - so the CER must be sent = to the "base application".

But for all other messages sent by an application to = a peer application, the application-id only makes sense (and complies = to RFC 3588) if it uses the application-id of the application that sent = the message. It makes no sense (and violates 3588) if it contains = anything else.

Now I agree, that the inclusion of the = Acct-Application-Id or Auth-Application-Id AVPs are then redundant in = all messages except CER/CEA since it will be the same as the value in = the message header.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031


-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] =
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for EAP =



Christopher Richards wrote:
>
> But from RFC 3588, section 3:-
>
> Application-ID
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  The application can be
>   an authentication application, an = accounting application or a
>   vendor specific application.  = See Section 11.3 for the possible
>   values that the application-id may = use.
>
>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
>
> From that, I take it that if the = Acct-Application-Id AVP contained
> value x, then the command header will also = contain value x. And if the
> command contained AVPs that were relevant to = application y, then the
> command header would contain application-id =3D = y also.
If the Auth/Acct-Application-Id AVP and command = header always contain the same value (except for CER/CEA, where the = same AVPs

are used for a completely different purpose), this = makes me wonder
why the AVP was included at all?
Or are there cases where the values could be = different?
Best regards,
Pasi

------_=_NextPart_001_01C45AB9.A952E2C0-- From owner-aaa-wg@merit.edu Fri Jun 25 10:28:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03837 for ; Fri, 25 Jun 2004 10:28:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC640912A0; Fri, 25 Jun 2004 10:28:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91A13912AA; Fri, 25 Jun 2004 10:28:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92A31912A0 for ; Fri, 25 Jun 2004 10:28:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D29759E64; Fri, 25 Jun 2004 10:28:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id E111A59E10; Fri, 25 Jun 2004 10:28:20 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5PESIV19662; Fri, 25 Jun 2004 10:28:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 10:28:19 -0400 Message-ID: From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Date: Fri, 25 Jun 2004 10:28:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45AC0.A4D35810" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45AC0.A4D35810 Content-Type: text/plain Hi John, Thanks for the reply. I understood that the command code space is shared for all applications so any application defining a new command cannot re-use an existing command code (It's also managed by IANA). I.e. command codes are unique across all applications. Any application that generates a message must indicate the peer application for which the message is destined. Additionally my understanding is that the Diameter base definition (app-id 0) is not a true application. I.e. you cannot implement and instantiate a Diameter base peer. RFC 3588 section 3.1 states that the "is used to determine the action that is to be taken for a particular message.". I don't think the command code is used to discriminate the application for which the command is destined for - that's the purpose of the application-id. Besides, the AVPs in the message are specific to the application to which the message is destined (e.g. session-id which has no meaning or association outside the application that the message is destined for). Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 9:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, In this case, I believe it is implicit that the implementation of an application must not use commands defined by any other application, except base commands. Otherwise, if the application ID is other than that of the application that defined the command how would the recipient understand what command definition to use to interpret it. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 14:38 To: "Christopher Richards" , "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu cc: Subject: RE: [AAA-WG]: Application IDs for EAP Hi Bernard, Jari, Pasi, Joe, So are we all in agreement that the application-id in the message header is the application-id of the application to which it needs to be handled by (i.e. the one that generated the message) as per 3588 requirements. And the only time that the application-id in the message header will be different from that contained in any optional auth-application-id or acct-application-id AVPs is in the CER/CEA messages. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: June 24, 2004 11:08 AM To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Exactly. > Application-ID is four octets and is used to identify to which > application the message is applicable for. This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless. > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. Again. This makes sense. CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application". But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else. Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: June 24, 2004 9:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Christopher Richards wrote: > > But from RFC 3588, section 3:- > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > From that, I take it that if the Acct-Application-Id AVP contained > value x, then the command header will also contain value x. And if the > command contained AVPs that were relevant to application y, then the > command header would contain application-id = y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs are used for a completely different purpose), this makes me wonder why the AVP was included at all? Or are there cases where the values could be different? Best regards, Pasi **************************************************************************** ** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie@vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G **************************************************************************** ** ------_=_NextPart_001_01C45AC0.A4D35810 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Hi John,

Thanks for the reply.

I understood that the command code space is shared = for all applications so any application defining a new command cannot = re-use an existing command code (It's also managed by IANA). I.e. = command codes are unique across all applications.

Any application that generates a message must = indicate the peer application for which the message is destined. = Additionally my understanding is that the Diameter base definition = (app-id 0) is not a true application. I.e. you cannot implement and = instantiate a Diameter base peer.

RFC 3588 section 3.1 states that the "is used to = determine the action that is to be taken for a particular = message.". I don't think the command code is used to discriminate = the application for which the command is destined for - that's the = purpose of the application-id.

Besides, the AVPs in the message are specific to the = application to which the message is destined (e.g. session-id which has = no meaning or association outside the application that the message is = destined for).

Cheers,
Chris

Tel:    +1 613 763 8031
ESN:    393 8031

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: June 25, 2004 9:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; Richards, Christopher = [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; = 'Pasi.Eronen@nokia.com'
Subject: RE: [AAA-WG]: Application IDs for = EAP



Hi Chris,

In this case, I believe it is implicit that the = implementation of an application must not use commands defined by any = other application, except base commands.

Otherwise, if the application ID is other than that = of the application that defined the command how would the recipient = understand what command definition to use to interpret it.

Regards,

John.




"Christopher Richards" = <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
25/06/2004 14:38
       
        = To:        "Christopher = Richards" <crich@nortelnetworks.com>, = "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>, = aaa-wg@merit.edu

        = cc:        
        = Subject:        RE: [AAA-WG]: = Application IDs for EAP



Hi Bernard, Jari, Pasi, Joe,
So are we all in agreement that the application-id = in the message header is the application-id of the application to which = it needs to be handled by (i.e. the one that generated the message) as = per 3588 requirements.

And the only time that the application-id in the = message header will be different from that contained in any optional = auth-application-id or acct-application-id AVPs is in the CER/CEA = messages.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH] =
Sent: June 24, 2004 11:08 AM
To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu =
Subject: RE: [AAA-WG]: Application IDs for EAP =
Exactly.
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  
This statement makes sense. Why would any = application put a different applications Id in the message? It would = make the Application-Id in the message header useless.

>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
Again. This makes sense.
CER and CEA must by definition use the base = application-id (0) in the message header because these messages are = polling the peer for applications supported - so the CER must be sent = to the "base application".

But for all other messages sent by an application to = a peer application, the application-id only makes sense (and complies = to RFC 3588) if it uses the application-id of the application that sent = the message. It makes no sense (and violates 3588) if it contains = anything else.

Now I agree, that the inclusion of the = Acct-Application-Id or Auth-Application-Id AVPs are then redundant in = all messages except CER/CEA since it will be the same as the value in = the message header.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] =
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for EAP =


Christopher Richards wrote:
>
> But from RFC 3588, section 3:-
>
> Application-ID
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  The application can be
>   an authentication application, an = accounting application or a
>   vendor specific application.  = See Section 11.3 for the possible
>   values that the application-id may = use.
>
>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
>
> From that, I take it that if the = Acct-Application-Id AVP contained
> value x, then the command header will also = contain value x. And if the
> command contained AVPs that were relevant to = application y, then the
> command header would contain application-id =3D = y also.
If the Auth/Acct-Application-Id AVP and command = header always contain the same value (except for CER/CEA, where the = same AVPs

are used for a completely different purpose), this = makes me wonder
why the AVP was included at all?
Or are there cases where the values could be = different?
Best regards,
Pasi


***************************************************************= ***************

The content of this e-mail may be confidential or = legally
privileged. If you are not the named addressee or = the intended
recipient please do not copy it or forward it to = anyone. If you have
received this email in error please destroy it and = kindly notify the
sender and postmaster.ie@vodafone.com. Email cannot = be
guaranteed to be secure or error-free, it is your = responsibility
to ensure that the message (including attachments) = is safe
and authorised for use in your environment.
Vodafone Ireland Limited. Directors: Peter Bamford = Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive = (UK),
Gerry Fahy, Dermot Griffin, David Boorman = (UK),
David Smithwhite (UK), Patrick Teahon, Alfred = Kane.
Registered in Ireland at MountainView, Leopardstown, = Dublin 18.
Co Reg No.: 326967 VAT Reg No. IE6346967G

***************************************************************= ***************

------_=_NextPart_001_01C45AC0.A4D35810-- From owner-aaa-wg@merit.edu Fri Jun 25 11:51:09 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14269 for ; Fri, 25 Jun 2004 11:51:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFB1791341; Fri, 25 Jun 2004 11:48:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B03291343; Fri, 25 Jun 2004 11:48:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD7F191341 for ; Fri, 25 Jun 2004 11:46:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C42259E7D; Fri, 25 Jun 2004 11:46:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id D366B59E10; Fri, 25 Jun 2004 11:46:43 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5PFkfV14032; Fri, 25 Jun 2004 11:46:41 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 25 Jun 2004 11:46:42 -0400 Message-ID: From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Date: Fri, 25 Jun 2004 11:46:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45ACB.95899750" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45ACB.95899750 Content-Type: text/plain Hi John, Unfortunately there is no definitive statement for the re-use or not of command codes by applications. I've tried to extract some relevant text from section 1.2 in RFC3588:- 1.2:- "It is expected that command codes are reused; new command codes can only be created by IETF Consensus..." Presumably this applies to command codes defined by applications other than RFC3588. 1.2.3 and 1.2.4:- "An implementation MAY add arbitrary non-mandatory AVPs (AVPs with the "M" bit not set) to any command defined in an** application, including vendor-specific AVPs, without needing to define a new accounting application. Please refer to Section 11.1.1 for details." Note: ** I presume that "an" means "any". Is there a technical reason why application X cannot re-use a command from application Y. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 10:51 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, Thanks for your reply. I was thinking of the possibility of an entire command definition bein borrowed from another application. My interpretation is that this is not permissible. If a command is to be used by an application (base commands excepted) then it must be defined by that application and use the application-ID of that application. Is that your understanding too? Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 15:28 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Hi John, Thanks for the reply. I understood that the command code space is shared for all applications so any application defining a new command cannot re-use an existing command code (It's also managed by IANA). I.e. command codes are unique across all applications. Any application that generates a message must indicate the peer application for which the message is destined. Additionally my understanding is that the Diameter base definition (app-id 0) is not a true application. I.e. you cannot implement and instantiate a Diameter base peer. RFC 3588 section 3.1 states that the "is used to determine the action that is to be taken for a particular message.". I don't think the command code is used to discriminate the application for which the command is destined for - that's the purpose of the application-id. Besides, the AVPs in the message are specific to the application to which the message is destined (e.g. session-id which has no meaning or association outside the application that the message is destined for). Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 9:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, In this case, I believe it is implicit that the implementation of an application must not use commands defined by any other application, except base commands. Otherwise, if the application ID is other than that of the application that defined the command how would the recipient understand what command definition to use to interpret it. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 14:38 To: "Christopher Richards" , "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu cc: Subject: RE: [AAA-WG]: Application IDs for EAP Hi Bernard, Jari, Pasi, Joe, So are we all in agreement that the application-id in the message header is the application-id of the application to which it needs to be handled by (i.e. the one that generated the message) as per 3588 requirements. And the only time that the application-id in the message header will be different from that contained in any optional auth-application-id or acct-application-id AVPs is in the CER/CEA messages. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: June 24, 2004 11:08 AM To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Exactly. > Application-ID is four octets and is used to identify to which > application the message is applicable for. This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless. > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. Again. This makes sense. CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application". But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else. Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: June 24, 2004 9:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Christopher Richards wrote: > > But from RFC 3588, section 3:- > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > From that, I take it that if the Acct-Application-Id AVP contained > value x, then the command header will also contain value x. And if the > command contained AVPs that were relevant to application y, then the > command header would contain application-id = y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs are used for a completely different purpose), this makes me wonder why the AVP was included at all? Or are there cases where the values could be different? Best regards, Pasi **************************************************************************** ** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie@vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G **************************************************************************** ** ------_=_NextPart_001_01C45ACB.95899750 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Application IDs for EAP

Hi John,

Unfortunately there is no definitive statement for = the re-use or not of command codes by applications. I've tried to = extract some relevant text from section 1.2 in RFC3588:-

1.2:-

   "It is expected that command codes = are reused; new command codes can only be
   created by IETF = Consensus..."

Presumably this applies to command codes defined by = applications other than RFC3588.

1.2.3 and 1.2.4:-

   "An implementation MAY add = arbitrary non-mandatory
   AVPs (AVPs with the "M" bit = not set) to any command defined in an**
   application, including vendor-specific = AVPs, without needing to
   define a new accounting = application.  Please refer to Section 11.1.1
   for details."

Note: ** I presume that "an" means = "any".

Is there a technical reason why application X cannot = re-use a command from application Y.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: June 25, 2004 10:51 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; = owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com'
Subject: RE: [AAA-WG]: Application IDs for = EAP



Hi Chris,

Thanks for your reply.

I was thinking of the possibility of an entire = command definition bein borrowed from another application.  My = interpretation is that this is not permissible.  If a command is = to be used by an application (base commands excepted) then it must be = defined by that application and use the application-ID of that = application.

Is that your understanding too?

Regards,

John.




"Christopher Richards" = <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
25/06/2004 15:28
       
        = To:        = "'John.Prudhoe@vodafone.com'" = <John.Prudhoe@vodafone.com>
        = cc:        aaa-wg@merit.edu, = owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" = <Pasi.Eronen@nokia.com>
        = Subject:        RE: [AAA-WG]: = Application IDs for EAP



Hi John,
Thanks for the reply.
I understood that the command code space is shared = for all applications so any application defining a new command cannot = re-use an existing command code (It's also managed by IANA). I.e. = command codes are unique across all applications.

Any application that generates a message must = indicate the peer application for which the message is destined. = Additionally my understanding is that the Diameter base definition = (app-id 0) is not a true application. I.e. you cannot implement and = instantiate a Diameter base peer.

RFC 3588 section 3.1 states that the "is used to = determine the action that is to be taken for a particular = message.". I don't think the command code is used to discriminate = the application for which the command is destined for - that's the = purpose of the application-id.

Besides, the AVPs in the message are specific to the = application to which the message is destined (e.g. session-id which has = no meaning or association outside the application that the message is = destined for).

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.c= om]
Sent: June 25, 2004 9:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; Richards, Christopher = [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' =
Subject: RE: [AAA-WG]: Application IDs for EAP =


Hi Chris,
In this case, I believe it is implicit that the = implementation of an application must not use commands defined by any = other application, except base commands.

Otherwise, if the application ID is other than that = of the application that defined the command how would the recipient = understand what command definition to use to interpret it.

Regards,
John.



"Christopher Richards" = <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
25/06/2004 14:38
      
       = To:        "Christopher = Richards" <crich@nortelnetworks.com>, = "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>, = aaa-wg@merit.edu

        = cc:        
       = Subject:        RE: [AAA-WG]: = Application IDs for EAP


Hi Bernard, Jari, Pasi, Joe,
So are we all in agreement that the application-id = in the message header is the application-id of the application to which = it needs to be handled by (i.e. the one that generated the message) as = per 3588 requirements.

And the only time that the application-id in the = message header will be different from that contained in any optional = auth-application-id or acct-application-id AVPs is in the CER/CEA = messages.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH] =
Sent: June 24, 2004 11:08 AM
To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu =
Subject: RE: [AAA-WG]: Application IDs for EAP =
Exactly.
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  
This statement makes sense. Why would any = application put a different applications Id in the message? It would = make the Application-Id in the message header useless.

>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
Again. This makes sense.
CER and CEA must by definition use the base = application-id (0) in the message header because these messages are = polling the peer for applications supported - so the CER must be sent = to the "base application".

But for all other messages sent by an application to = a peer application, the application-id only makes sense (and complies = to RFC 3588) if it uses the application-id of the application that sent = the message. It makes no sense (and violates 3588) if it contains = anything else.

Now I agree, that the inclusion of the = Acct-Application-Id or Auth-Application-Id AVPs are then redundant in = all messages except CER/CEA since it will be the same as the value in = the message header.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] =
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for EAP =
Christopher Richards wrote:
>
> But from RFC 3588, section 3:-
>
> Application-ID
>   Application-ID is four octets and = is used to identify to which
>   application the message is = applicable for.  The application can be
>   an authentication application, an = accounting application or a
>   vendor specific application.  = See Section 11.3 for the possible
>   values that the application-id may = use.
>
>   The application-id in the header = MUST be the same as what is
>   contained in any relevant AVPs = contained in the message.
>
> From that, I take it that if the = Acct-Application-Id AVP contained
> value x, then the command header will also = contain value x. And if the
> command contained AVPs that were relevant to = application y, then the
> command header would contain application-id =3D = y also.
If the Auth/Acct-Application-Id AVP and command = header always contain the same value (except for CER/CEA, where the = same AVPs

are used for a completely different purpose), this = makes me wonder
why the AVP was included at all?
Or are there cases where the values could be = different?
Best regards,
Pasi
***************************************************************= ***************
The content of this e-mail may be confidential or = legally
privileged. If you are not the named addressee or = the intended
recipient please do not copy it or forward it to = anyone. If you have
received this email in error please destroy it and = kindly notify the
sender and postmaster.ie@vodafone.com. Email cannot = be
guaranteed to be secure or error-free, it is your = responsibility
to ensure that the message (including attachments) = is safe
and authorised for use in your environment.
Vodafone Ireland Limited. Directors: Peter Bamford = Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive = (UK),
Gerry Fahy, Dermot Griffin, David Boorman (UK), =
David Smithwhite (UK), Patrick Teahon, Alfred Kane. =
Registered in Ireland at MountainView, Leopardstown, = Dublin 18.
Co Reg No.: 326967 VAT Reg No. IE6346967G
***************************************************************= ***************

------_=_NextPart_001_01C45ACB.95899750-- From owner-aaa-wg@merit.edu Mon Jun 28 00:48:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23951 for ; Mon, 28 Jun 2004 00:48:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F365E91214; Mon, 28 Jun 2004 00:48:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF06391218; Mon, 28 Jun 2004 00:48:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AA4891214 for ; Mon, 28 Jun 2004 00:48:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83CB359F4E; Mon, 28 Jun 2004 00:48:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by segue.merit.edu (Postfix) with ESMTP id 2EE6C59C50 for ; Mon, 28 Jun 2004 00:48:27 -0400 (EDT) Received: from wire.cs.nthu.edu.tw (localhost.localdomain [127.0.0.1]) by wire.cs.nthu.edu.tw (Postfix) with ESMTP id 675E317C3C for ; Mon, 28 Jun 2004 12:54:29 +0800 (CST) From: "ting" To: aaa-wg@merit.edu Subject: [AAA-WG]: WIRE DIAMETER Date: Mon, 28 Jun 2004 12:54:29 +0800 Message-Id: <20040628045215.M14705@wire.cs.nthu.edu.tw> X-Mailer: Open WebMail 2.20 20031014 X-OriginatingIP: 221.169.21.176 (ting) MIME-Version: 1.0 Content-Type: text/plain; charset=big5 Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello folks, I implement and design a diameter testbed(we name as WIRE DIAMETER),we support some authentication method, as follows,1) MD5, 2) TLS, 3) TTLS (phase2: chap,ms-chap,ms-chap-v2,pap), 4) PEAP (phase2: ms-chap-v2). through to extending the library of opendiamter-1.0.5. Our testbed can work with many client softwares, e.g Open1x, WIRE1x, Ageis client,...etc. In short term,I plan to writing a paper about this testbed for my first paper. But I have no idea what conference is suit me. Hope someone can get me a suggestion, thanks !! ^_^ Wen-Ting Wu http://wire.cs.nthu.edu.tw -- Open WebMail Project (http://openwebmail.org) From owner-aaa-wg@merit.edu Mon Jun 28 01:04:39 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24578 for ; Mon, 28 Jun 2004 01:04:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 859ED91218; Mon, 28 Jun 2004 01:04:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 595D991260; Mon, 28 Jun 2004 01:04:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1687491218 for ; Mon, 28 Jun 2004 01:04:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 010EE59F03; Mon, 28 Jun 2004 01:04:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 697C759F4E for ; Mon, 28 Jun 2004 01:04:25 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5S54IL26585; Mon, 28 Jun 2004 01:04:18 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jun 2004 01:04:18 -0400 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371FA2E59@zrc2hxm2.corp.nortel.com> From: "Ahmad Muhanna" To: "'Bernard Aboba'" , jonwood@speakeasy.net, aaa-wg@merit.edu Subject: [AAA-WG]: RE: A question about security consideration in RFC3539 Date: Mon, 28 Jun 2004 01:04:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45CCD.52C632B8" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45CCD.52C632B8 Content-Type: text/plain Bernard, Thanks!. I think this is a good idea especially when the client does not know the other end support for IPSec. Reading RFC3588 Base Diameter, It made it a must on Diameter servers and clients to support IPSec. I assume they have to support IKE to establish IPSec. The other thing which attracted my attention is that RFC2409 mandates ONLY pre-shared secret key authentication for phase 1 negotiation. Also, RFC3588 mandates the use of pre-shared secret-key and optional digital signature. In that case; should not the client knows ahead of time the server capabilities with respect to IKE? Regards, Ahmad -----Original Message----- From: Bernard Aboba [mailto:bernarda@windows.microsoft.com] Sent: Friday, June 25, 2004 9:53 PM To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; jonwood@speakeasy.net; aaa-wg@merit.edu Subject: RE: A question about security consideration in RFC3539 The issue is that if the responder doesn't support IKE the result is a timeout, since most initiators drop incoming ICMP port unreachable messages. So the question is how to determine if the responder doesn't support IKE in a more timely way. For some protocols (e.g. TCP or SCTP) the "send cleartext, respond back with IKE) approach is tempting, because no data is sent in the initial packet (a SYN) so that there is not much security exposure, assuming that the initiator can determine whether IPsec has been negotiated before sending any data. However, with Diameter the only alternative if IKE negotiation fails is to try to bring up a non-IPsec protected TCP connection and then switch the connection over to TLS. There is no application-specific security available to serve as a safety net. -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com ] Sent: Fri 6/25/2004 6:22 PM To: Bernard Aboba; 'jonwood@speakeasy.net' Subject: A question about security consideration in RFC3539 Hello Bernard/Jonathan I would appreciate it much if you comment on the following paragraph under section 4. In particular the following sentence: " ........................................................In order to enable a AAA client to determine what security mechanisms are in use on an agent or server without prior knowledge, it may be tempting to initiate a connection in the clear, and then to have the AAA agent respond with IKE [RFC2409]. " Excerpt Under section 4.0 it reads: Where IPsec [RFC2401] is used to provide security, it is important that IPsec policy require IPsec on incoming packets. In order to enable a AAA client to determine what security mechanisms are in use on an agent or server without prior knowledge, it may be tempting to initiate a connection in the clear, and then to have the AAA agent respond with IKE [RFC2409]. While this approach minimizes required client configuration, it increases the vulnerability to denial of service attack, since a connection request can now not only tie up transport resources, but also resources within the IKE implementation. Thanks! Regards, Ahmad ------_=_NextPart_001_01C45CCD.52C632B8 Content-Type: text/html Message
Bernard,
Thanks!.
 
I think this is a good idea especially when the client does not know the other end support for IPSec.
Reading RFC3588 Base Diameter, It made it a must on Diameter servers and clients to support IPSec.
I assume they have to support IKE to establish IPSec.
 
The other thing which attracted my attention is that RFC2409 mandates ONLY pre-shared secret key authentication for phase 1 negotiation. Also, RFC3588 mandates the use of pre-shared secret-key and optional digital signature.
In that case; should not the client knows ahead of time the server capabilities with respect to IKE?
 
Regards,
Ahmad
-----Original Message-----
From: Bernard Aboba [mailto:bernarda@windows.microsoft.com]
Sent: Friday, June 25, 2004 9:53 PM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; jonwood@speakeasy.net; aaa-wg@merit.edu
Subject: RE: A question about security consideration in RFC3539

The issue is that if the responder doesn't support IKE the result is a timeout, since most initiators drop incoming ICMP port unreachable messages.  So the question is how to determine if the responder doesn't support IKE in a more timely way. 

For some protocols (e.g. TCP or SCTP) the "send cleartext, respond back with IKE) approach is tempting, because no data is sent in the initial packet (a SYN) so that there is not much security exposure, assuming that the initiator can determine whether IPsec has been negotiated before sending any data.

However, with Diameter the only alternative if IKE negotiation fails is to try to bring up a non-IPsec protected TCP connection and then switch the connection over to TLS.  There is no application-specific security available to serve as a safety net.

-----Original Message-----
From: Ahmad Muhanna [mailto:amuhanna@nortelnetworks.com]
Sent: Fri 6/25/2004 6:22 PM
To: Bernard Aboba; 'jonwood@speakeasy.net'
Subject: A question about security consideration in RFC3539

Hello Bernard/Jonathan

I would appreciate it much if you comment on the following paragraph under
section 4.
In particular the following sentence:

"
   ........................................................In order to
   enable a AAA client to determine what security mechanisms are in use
   on an agent or server without prior knowledge, it may be tempting to
   initiate a connection in the clear, and then to have the AAA agent
   respond with IKE [RFC2409].
"

Excerpt
Under section 4.0 it reads:

   Where IPsec [RFC2401] is used to provide security, it is important
   that IPsec policy require IPsec on incoming packets.  In order to
   enable a AAA client to determine what security mechanisms are in use
   on an agent or server without prior knowledge, it may be tempting to
   initiate a connection in the clear, and then to have the AAA agent
   respond with IKE [RFC2409].  While this approach minimizes required
   client configuration, it increases the vulnerability to denial of
   service attack, since a connection request can now not only tie up
   transport resources, but also resources within the IKE
   implementation.


Thanks!

Regards,
Ahmad


------_=_NextPart_001_01C45CCD.52C632B8-- From owner-aaa-wg@merit.edu Mon Jun 28 01:42:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26056 for ; Mon, 28 Jun 2004 01:42:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D44A91264; Mon, 28 Jun 2004 01:42:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66C2591266; Mon, 28 Jun 2004 01:42:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D1AD91264 for ; Mon, 28 Jun 2004 01:42:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C12859EFA; Mon, 28 Jun 2004 01:42:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B2C6959E0E for ; Mon, 28 Jun 2004 01:42:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5S5fUP21744; Sun, 27 Jun 2004 22:41:31 -0700 Date: Sun, 27 Jun 2004 22:41:30 -0700 (PDT) From: Bernard Aboba To: Ahmad Muhanna Cc: "'Bernard Aboba'" , jonwood@speakeasy.net, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: A question about security consideration in RFC3539 In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371FA2E59@zrc2hxm2.corp.nortel.com> Message-ID: References: <6FC4416DDE56C44DA0AEE67BC7CA4371FA2E59@zrc2hxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The other thing which attracted my attention is that RFC2409 mandates ONLY > pre-shared secret key authentication for phase 1 negotiation. Also, RFC3588 > mandates the use of pre-shared secret-key and optional digital signature. > In that case; should not the client knows ahead of time the server > capabilities with respect to IKE? For IKE to work, it is always necessary to pre-provision some credentials. Assuming that the Diameter client and server are provisioned with compatible credentials, they can use the IKE negotiation to negotiate the use of them. I'd note that an implementation of IKE with only pre-shared keys is considerably smaller than one supporting certificate exchanges (only 200 KB or so, see RFC 3723 for details). So if resource availability is an issue, then this is an economical way to secure Diameter (and RADIUS too, see RFC 3579). From owner-aaa-wg@merit.edu Mon Jun 28 07:53:05 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28183 for ; Mon, 28 Jun 2004 07:53:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5808591229; Mon, 28 Jun 2004 07:52:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27B6A9122B; Mon, 28 Jun 2004 07:52:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19A3491229 for ; Mon, 28 Jun 2004 07:52:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 051A459ADB; Mon, 28 Jun 2004 07:52:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 47E2A5990C for ; Mon, 28 Jun 2004 07:52:50 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SBqn206381 for ; Mon, 28 Jun 2004 14:52:49 +0300 (EET DST) X-Scanned: Mon, 28 Jun 2004 14:51:34 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i5SBpYwB008986 for ; Mon, 28 Jun 2004 14:51:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 001SGcK2; Mon, 28 Jun 2004 14:51:32 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5SBWbH15000 for ; Mon, 28 Jun 2004 14:32:37 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Jun 2004 14:32:35 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: [AAA-WG]: Diameter EAP -08 Date: Mon, 28 Jun 2004 14:32:35 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3B3A@esebe023.ntc.nokia.com> Thread-Topic: Diameter EAP -08 Thread-Index: AcRdA5tL4hXySLoRR3Sj4KjxeixJtQ== From: To: X-OriginalArrivalTime: 28 Jun 2004 11:32:35.0809 (UTC) FILETIME=[9C147D10:01C45D03] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Version -08 is now available from the I-D repository: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt As proposed by Bernard and Jari, this version uses the application=20 identifiers from BASE for the commands defined there. An HTML diff=20 from -07 is available from the usual place: http://www.cs.hut.fi/~peronen/eap/diameter_eap.html Best regards, Pasi From owner-aaa-wg@merit.edu Mon Jun 28 09:08:31 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03501 for ; Mon, 28 Jun 2004 09:08:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F41489122E; Mon, 28 Jun 2004 09:08:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1B4091230; Mon, 28 Jun 2004 09:08:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6920D9122E for ; Mon, 28 Jun 2004 09:08:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 48005599D7; Mon, 28 Jun 2004 09:08:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 84E6859BE6; Mon, 28 Jun 2004 09:08:11 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5SD89L06070; Mon, 28 Jun 2004 09:08:09 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jun 2004 09:08:09 -0400 Message-ID: From: "Christopher Richards" To: "'John.Prudhoe@vodafone.com'" Cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Date: Mon, 28 Jun 2004 09:08:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45D10.F38BDA00" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45D10.F38BDA00 Content-Type: text/plain Hi John, That's a good description and example of the issue. I've inlined some comments below. Cheers, Chris -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 12:13 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, That's the scenario I was trying to work out. Imagine a hypothetical application x with three commands. Those commands would use an application ID - let's call that x too. Someone wants to add a new command so, as clearly delineated by RFC 3588, that leads to a new application, y. This application is effectively application x plus one new command. The new command definitely would use it's own application ID. Again, for simplicity, let's use the value y. The big question I think you have all been discussing is what application ID is used within application y for the commands inherited. My first thoughts were that the original commands should use an application ID of x. Your proposal, as I understand it, is that they should include an application ID of y. [[Chris Richards] ] Yes. And to put it the other way: How would application x deal with messages and AVPs generated and destined for application y? Application x probably does not know about application y. The peer cannot make any assumptions about how the applications are implemented on the destination device. What needs to be clear is how the implementor of application y should cope with commands from application x. An initial assumption is that if the capabilities exchange is completed only for application y, then the recipient shouldn't acept commands with an application ID of x. On the otherhand, if application y doesn't define those commands an application y client or server wouldn't necessarily implement support for them. The rules in RFC 3588 that cause new applications to be created lead me to believe that there will eventually be a number of applications that inherit commands from earlier applications, however there doesn't seem to be a clear definition of how an application should inherit commands. Should there be a new RFC to clarify that? Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 16:46 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Hi John, Unfortunately there is no definitive statement for the re-use or not of command codes by applications. I've tried to extract some relevant text from section 1.2 in RFC3588:- 1.2:- "It is expected that command codes are reused; new command codes can only be created by IETF Consensus..." Presumably this applies to command codes defined by applications other than RFC3588. 1.2.3 and 1.2.4:- "An implementation MAY add arbitrary non-mandatory AVPs (AVPs with the "M" bit not set) to any command defined in an** application, including vendor-specific AVPs, without needing to define a new accounting application. Please refer to Section 11.1.1 for details." Note: ** I presume that "an" means "any". Is there a technical reason why application X cannot re-use a command from application Y. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 10:51 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, Thanks for your reply. I was thinking of the possibility of an entire command definition bein borrowed from another application. My interpretation is that this is not permissible. If a command is to be used by an application (base commands excepted) then it must be defined by that application and use the application-ID of that application. Is that your understanding too? Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 15:28 To: "'John.Prudhoe@vodafone.com'" cc: aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP Hi John, Thanks for the reply. I understood that the command code space is shared for all applications so any application defining a new command cannot re-use an existing command code (It's also managed by IANA). I.e. command codes are unique across all applications. Any application that generates a message must indicate the peer application for which the message is destined. Additionally my understanding is that the Diameter base definition (app-id 0) is not a true application. I.e. you cannot implement and instantiate a Diameter base peer. RFC 3588 section 3.1 states that the "is used to determine the action that is to be taken for a particular message.". I don't think the command code is used to discriminate the application for which the command is destined for - that's the purpose of the application-id. Besides, the AVPs in the message are specific to the application to which the message is destined (e.g. session-id which has no meaning or association outside the application that the message is destined for). Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: John.Prudhoe@vodafone.com [ mailto:John.Prudhoe@vodafone.com] Sent: June 25, 2004 9:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Chris, In this case, I believe it is implicit that the implementation of an application must not use commands defined by any other application, except base commands. Otherwise, if the application ID is other than that of the application that defined the command how would the recipient understand what command definition to use to interpret it. Regards, John. "Christopher Richards" Sent by: owner-aaa-wg@merit.edu 25/06/2004 14:38 To: "Christopher Richards" , "'Pasi.Eronen@nokia.com'" , aaa-wg@merit.edu cc: Subject: RE: [AAA-WG]: Application IDs for EAP Hi Bernard, Jari, Pasi, Joe, So are we all in agreement that the application-id in the message header is the application-id of the application to which it needs to be handled by (i.e. the one that generated the message) as per 3588 requirements. And the only time that the application-id in the message header will be different from that contained in any optional auth-application-id or acct-application-id AVPs is in the CER/CEA messages. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: June 24, 2004 11:08 AM To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Exactly. > Application-ID is four octets and is used to identify to which > application the message is applicable for. This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless. > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. Again. This makes sense. CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application". But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else. Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Pasi.Eronen@nokia.com [ mailto:Pasi.Eronen@nokia.com] Sent: June 24, 2004 9:52 AM To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application IDs for EAP Christopher Richards wrote: > > But from RFC 3588, section 3:- > > Application-ID > Application-ID is four octets and is used to identify to which > application the message is applicable for. The application can be > an authentication application, an accounting application or a > vendor specific application. See Section 11.3 for the possible > values that the application-id may use. > > The application-id in the header MUST be the same as what is > contained in any relevant AVPs contained in the message. > > From that, I take it that if the Acct-Application-Id AVP contained > value x, then the command header will also contain value x. And if the > command contained AVPs that were relevant to application y, then the > command header would contain application-id = y also. If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs are used for a completely different purpose), this makes me wonder why the AVP was included at all? Or are there cases where the values could be different? Best regards, Pasi **************************************************************************** ** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie@vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G **************************************************************************** ** ------_=_NextPart_001_01C45D10.F38BDA00 Content-Type: text/html Message
Hi John,
 
That's a good description and example of the issue. I've inlined some comments below.

Cheers,
Chris

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: June 25, 2004 12:13 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com'
Subject: RE: [AAA-WG]: Application IDs for EAP

Hi Chris,

That's the scenario I was trying to work out.  Imagine a hypothetical application x with three commands.  Those commands would use an application ID - let's call that x too.

Someone wants to add a new command so, as clearly delineated by RFC 3588, that leads to a new application, y.  This application is effectively application x plus one new command.  The new command definitely would use it's own application ID.  Again, for simplicity, let's use the value y.

The big question I think you have all been discussing is what application ID is used within application y for the commands inherited.  My first thoughts were that the original commands should use an application ID of x.  Your proposal, as I understand it, is that they should include an application ID of y.

[[Chris Richards] ] Yes. And to put it the other way: How would application x deal with messages and AVPs generated and destined for application y? Application x probably does not know about application y. The peer cannot make any assumptions about how the applications are implemented on the destination device.


What needs to be clear is how the implementor of application y should cope with commands from application x.  An initial assumption is that if the capabilities exchange is completed only for application y, then the recipient shouldn't acept commands with an application ID of x.

On the otherhand, if application y doesn't define those commands an application y client or server wouldn't necessarily implement support for them.

The rules in RFC 3588 that cause new applications to be created lead me to believe that there will eventually be a number of applications that inherit commands from earlier applications, however there doesn't seem to be a clear definition of how an application should inherit commands.  Should there be a new RFC to clarify that?

Regards,

John.




"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu

25/06/2004 16:46

       
        To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
        cc:        aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>
        Subject:        RE: [AAA-WG]: Application IDs for EAP



Hi John,

Unfortunately there is no definitive statement for the re-use or not of command codes by applications. I've tried to extract some relevant text from section 1.2 in RFC3588:-

1.2:-

   "It is expected that command codes are reused; new command codes can only be
  created by IETF Consensus..."

Presumably this applies to command codes defined by applications other than RFC3588.

1.2.3 and 1.2.4:-

   "An implementation MAY add arbitrary non-mandatory
  AVPs (AVPs with the "M" bit not set) to any command defined in an**
  application, including vendor-specific AVPs, without needing to
  define a new accounting application.  Please refer to Section 11.1.1
  for details."

Note: ** I presume that "an" means "any".

Is there a technical reason why application X cannot re-use a command from application Y.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031

-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: June 25, 2004 10:51 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; 'John.Prudhoe@vodafone.com'; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com'
Subject: RE: [AAA-WG]: Application IDs for EAP


Hi Chris,

Thanks for your reply.

I was thinking of the possibility of an entire command definition bein borrowed from another application.  My interpretation is that this is not permissible.  If a command is to be used by an application (base commands excepted) then it must be defined by that application and use the application-ID of that application.

Is that your understanding too?

Regards,

John.



"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
25/06/2004 15:28
       
       To:        "'John.Prudhoe@vodafone.com'" <John.Prudhoe@vodafone.com>
       cc:        aaa-wg@merit.edu, owner-aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>
       Subject:        RE: [AAA-WG]: Application IDs for EAP


Hi John,
Thanks for the reply.
I understood that the command code space is shared for all applications so any application defining a new command cannot re-use an existing command code (It's also managed by IANA). I.e. command codes are unique across all applications.

Any application that generates a message must indicate the peer application for which the message is destined. Additionally my understanding is that the Diameter base definition (app-id 0) is not a true application. I.e. you cannot implement and instantiate a Diameter base peer.

RFC 3588 section 3.1 states that the "is used to determine the action that is to be taken for a particular message.". I don't think the command code is used to discriminate the application for which the command is destined for - that's the purpose of the application-id.

Besides, the AVPs in the message are specific to the application to which the message is destined (e.g. session-id which has no meaning or association outside the application that the message is destined for).

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com]
Sent: June 25, 2004 9:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; owner-aaa-wg@merit.edu; 'Pasi.Eronen@nokia.com'
Subject: RE: [AAA-WG]: Application IDs for EAP

Hi Chris,
In this case, I believe it is implicit that the implementation of an application must not use commands defined by any other application, except base commands.

Otherwise, if the application ID is other than that of the application that defined the command how would the recipient understand what command definition to use to interpret it.

Regards,
John.


"Christopher Richards" <crich@nortelnetworks.com>
Sent by: owner-aaa-wg@merit.edu
25/06/2004 14:38
     
      To:        "Christopher Richards" <crich@nortelnetworks.com>, "'Pasi.Eronen@nokia.com'" <Pasi.Eronen@nokia.com>, aaa-wg@merit.edu

        cc:        
      Subject:        RE: [AAA-WG]: Application IDs for EAP

Hi Bernard, Jari, Pasi, Joe,
So are we all in agreement that the application-id in the message header is the application-id of the application to which it needs to be handled by (i.e. the one that generated the message) as per 3588 requirements.

And the only time that the application-id in the message header will be different from that contained in any optional auth-application-id or acct-application-id AVPs is in the CER/CEA messages.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: June 24, 2004 11:08 AM
To: 'Pasi.Eronen@nokia.com'; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for EAP
Exactly.
>   Application-ID is four octets and is used to identify to which
>   application the message is applicable for.  
This statement makes sense. Why would any application put a different applications Id in the message? It would make the Application-Id in the message header useless.

>   The application-id in the header MUST be the same as what is
>   contained in any relevant AVPs contained in the message.
Again. This makes sense.
CER and CEA must by definition use the base application-id (0) in the message header because these messages are polling the peer for applications supported - so the CER must be sent to the "base application".

But for all other messages sent by an application to a peer application, the application-id only makes sense (and complies to RFC 3588) if it uses the application-id of the application that sent the message. It makes no sense (and violates 3588) if it contains anything else.

Now I agree, that the inclusion of the Acct-Application-Id or Auth-Application-Id AVPs are then redundant in all messages except CER/CEA since it will be the same as the value in the message header.

Cheers,
Chris
Tel:    +1 613 763 8031
ESN:    393 8031
-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]
Sent: June 24, 2004 9:52 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Application IDs for EAP
Christopher Richards wrote:
>
> But from RFC 3588, section 3:-
>
> Application-ID
>   Application-ID is four octets and is used to identify to which
>   application the message is applicable for.  The application can be
>   an authentication application, an accounting application or a
>   vendor specific application.  See Section 11.3 for the possible
>   values that the application-id may use.
>
>   The application-id in the header MUST be the same as what is
>   contained in any relevant AVPs contained in the message.
>
> From that, I take it that if the Acct-Application-Id AVP contained
> value x, then the command header will also contain value x. And if the
> command contained AVPs that were relevant to application y, then the
> command header would contain application-id = y also.
If the Auth/Acct-Application-Id AVP and command header always contain the same value (except for CER/CEA, where the same AVPs

are used for a completely different purpose), this makes me wonder
why the AVP was included at all?
Or are there cases where the values could be different?
Best regards,
Pasi
******************************************************************************
The content of this e-mail may be confidential or legally
privileged. If you are not the named addressee or the intended
recipient please do not copy it or forward it to anyone. If you have
received this email in error please destroy it and kindly notify the
sender and postmaster.ie@vodafone.com. Email cannot be
guaranteed to be secure or error-free, it is your responsibility
to ensure that the message (including attachments) is safe
and authorised for use in your environment.
Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK),
Pauline Best (UK), Paul Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David Boorman (UK),
David Smithwhite (UK), Patrick Teahon, Alfred Kane.
Registered in Ireland at MountainView, Leopardstown, Dublin 18.
Co Reg No.: 326967 VAT Reg No. IE6346967G
******************************************************************************

------_=_NextPart_001_01C45D10.F38BDA00-- From owner-aaa-wg@merit.edu Mon Jun 28 11:58:12 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12953 for ; Mon, 28 Jun 2004 11:58:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9F77A91232; Mon, 28 Jun 2004 11:57:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6911291233; Mon, 28 Jun 2004 11:57:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F54991232 for ; Mon, 28 Jun 2004 11:57:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5593659CFD; Mon, 28 Jun 2004 11:57:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id B926A59CFC for ; Mon, 28 Jun 2004 11:57:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5SFv5a25178; Mon, 28 Jun 2004 08:57:07 -0700 Date: Mon, 28 Jun 2004 08:57:05 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: "'John.Prudhoe@vodafone.com'" , aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The big question I think you have all been discussing is what application ID > is used within application y for the commands inherited. My first thoughts > were that the original commands should use an application ID of x. Your > proposal, as I understand it, is that they should include an application ID > of y. RFC 3588 is fairly clear on what is required. Changing the application ID of existing commands and AVPs to "y" from "x" unecessarily will break interoperability with existing implementations of those commands. > An initial assumption is that if the capabilities exchange is completed > only for application y, then the recipient shouldn't acept commands with > an application ID of x. A Diameter peer should advertise *all* applications that it supports. So if commands with application X and commands with application Y are being used, then *both* should be advertised. > On the otherhand, if application y doesn't define those commands an > application y client or server wouldn't necessarily implement support for > them. That's also true -- a Diameter application document needs to explicitly state what commands MUST, SHOULD or MAY be implemented for that application. It also needs to state what application-IDs must be used for those commands. > The rules in RFC 3588 that cause new applications to be created lead me to > believe that there will eventually be a number of applications that inherit > commands from earlier applications, however there doesn't seem to be a clear > definition of how an application should inherit commands. RFC 3588 is very explicit on this point -- new application IDs can only be used if the command is fundamentally changed, such as by changing the round-trips, or adding a new mandatory AVP. Otherwise the existing command definition (and application ID) is used. Doing anything else breaks Diameter interoperability. From owner-aaa-wg@merit.edu Mon Jun 28 11:59:59 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13049 for ; Mon, 28 Jun 2004 11:59:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C391391233; Mon, 28 Jun 2004 11:59:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9348591246; Mon, 28 Jun 2004 11:59:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A19FC91233 for ; Mon, 28 Jun 2004 11:59:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8986F59CF6; Mon, 28 Jun 2004 11:59:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id 1602159CAF for ; Mon, 28 Jun 2004 11:59:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5SFx9f25289; Mon, 28 Jun 2004 08:59:09 -0700 Date: Mon, 28 Jun 2004 08:59:09 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter EAP -08 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > What happened to the discussion regarding the issues with using the base > application-id's? Clearly, as it stands, the spec is in violation of the > Diameter Base RFC. Yes, the issue does not appear to have been addressed. From owner-aaa-wg@merit.edu Mon Jun 28 12:23:45 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14053 for ; Mon, 28 Jun 2004 12:23:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9DB1C91246; Mon, 28 Jun 2004 12:23:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6727A91257; Mon, 28 Jun 2004 12:23:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD78591246 for ; Mon, 28 Jun 2004 12:23:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B189F59C57; Mon, 28 Jun 2004 12:23:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 4988459CA1 for ; Mon, 28 Jun 2004 12:23:31 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5SGNTL15064 for ; Mon, 28 Jun 2004 12:23:29 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jun 2004 12:23:29 -0400 Message-ID: From: "Christopher Richards" To: aaa-wg@merit.edu Subject: [AAA-WG]: Application ID collision for MIPv4 and DCC Date: Mon, 28 Jun 2004 12:23:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45D2C.39ED4618" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45D2C.39ED4618 Content-Type: text/plain Hi All, I was just comparing some text in the MIPv4 draft spec (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-18.txt ) and the DCCA draft spec (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt ) and noticed that both drafts have been assigned the same application-id (4). The MIPv4 draft has expired so I presume that it is no longer valid and it's application-id can be re-assigned to DCCA without issue. Is that right? Cheers, Chris -----Original Message----- From: John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] Sent: June 28, 2004 12:18 PM To: Bernard Aboba Cc: aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH]; 'John.Prudhoe@vodafone.com'; 'Pasi.Eronen@nokia.com' Subject: RE: [AAA-WG]: Application IDs for EAP Hi Bernard, Thanks. I think your answer is clear, but if you don't mind I'll just try to put it into my own words. Please let me know if I've got anything wrong. I think the key point is that the application definition must explicitly state which application ID is to be used for inherited commands (and newly defined commands). If I understand your answer correctly, if a new application defines a new command and re-uses a number of existing commands without significant change, the only option is for those re-used commands to be used with their original application ID. So, in the example below, any implementation of application y is going to include commands with an application ID of x, so a capabilities exchange using just an application ID of y is not a practical proposition. Regards, John. Bernard Aboba 28/06/2004 16:57 To: Christopher Richards cc: "'John.Prudhoe@vodafone.com'" , aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'" Subject: RE: [AAA-WG]: Application IDs for EAP > The big question I think you have all been discussing is what application ID > is used within application y for the commands inherited. My first thoughts > were that the original commands should use an application ID of x. Your > proposal, as I understand it, is that they should include an application ID > of y. RFC 3588 is fairly clear on what is required. Changing the application ID of existing commands and AVPs to "y" from "x" unecessarily will break interoperability with existing implementations of those commands. > An initial assumption is that if the capabilities exchange is completed > only for application y, then the recipient shouldn't acept commands with > an application ID of x. A Diameter peer should advertise *all* applications that it supports. So if commands with application X and commands with application Y are being used, then *both* should be advertised. > On the otherhand, if application y doesn't define those commands an > application y client or server wouldn't necessarily implement support for > them. That's also true -- a Diameter application document needs to explicitly state what commands MUST, SHOULD or MAY be implemented for that application. It also needs to state what application-IDs must be used for those commands. > The rules in RFC 3588 that cause new applications to be created lead me to > believe that there will eventually be a number of applications that inherit > commands from earlier applications, however there doesn't seem to be a clear > definition of how an application should inherit commands. RFC 3588 is very explicit on this point -- new application IDs can only be used if the command is fundamentally changed, such as by changing the round-trips, or adding a new mandatory AVP. Otherwise the existing command definition (and application ID) is used. Doing anything else breaks Diameter interoperability. **************************************************************************** ** The content of this e-mail may be confidential or legally privileged. If you are not the named addressee or the intended recipient please do not copy it or forward it to anyone. If you have received this email in error please destroy it and kindly notify the sender and postmaster.ie@vodafone.com. Email cannot be guaranteed to be secure or error-free, it is your responsibility to ensure that the message (including attachments) is safe and authorised for use in your environment. Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), Pauline Best (UK), Paul Donovan Chief Executive (UK), Gerry Fahy, Dermot Griffin, David Boorman (UK), David Smithwhite (UK), Patrick Teahon, Alfred Kane. Registered in Ireland at MountainView, Leopardstown, Dublin 18. Co Reg No.: 326967 VAT Reg No. IE6346967G **************************************************************************** ** ------_=_NextPart_001_01C45D2C.39ED4618 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi=20 All,
 
I was=20 just comparing some text in the MIPv4 draft spec (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter= -mobileip-18.txt)=20 and the DCCA draft spec (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05= .txt)=20 and noticed that both drafts have been assigned the same application-id = (4).
 
The=20 MIPv4 draft has expired so I presume that it is no longer valid and = it's=20 application-id can be re-assigned to DCCA without issue. Is that=20 right?

Cheers,
Chris

-----Original = Message-----
From:=20 John.Prudhoe@vodafone.com [mailto:John.Prudhoe@vodafone.com] =
Sent:=20 June 28, 2004 12:18 PM
To: Bernard Aboba
Cc:=20 aaa-wg@merit.edu; Richards, Christopher [RICH2:2Q40:EXCH];=20 'John.Prudhoe@vodafone.com'; 'Pasi.Eronen@nokia.com'
Subject: = RE:=20 [AAA-WG]: Application IDs for EAP


Hi=20 Bernard,

Thanks.  I = think your=20 answer is clear, but if you don't mind I'll just try to put it into = my own=20 words.  Please let me know if I've got anything wrong. =  =20

I think the key point is that the = application=20 definition must explicitly state which application ID is to be used = for=20 inherited commands (and newly defined commands).

If I understand your answer correctly, if a new = application=20 defines a new command and re-uses a number of existing commands = without=20 significant change, the only option is for those re-used commands to = be used=20 with their original application ID.

So,=20 in the example below, any implementation of application y is going to = include=20 commands with an application ID of x, so a capabilities exchange = using just an=20 application ID of y is not a practical proposition. =

Regards,

John.=20

 



Bernard Aboba=20 <aboba@internaut.com>=20

28/06/2004 16:57 =

        =
        To: =    =20    Christopher Richards=20 <crich@nortelnetworks.com>
        cc:      =20  "'John.Prudhoe@vodafone.com'" = <John.Prudhoe@vodafone.com>,=20 aaa-wg@merit.edu, "'Pasi.Eronen@nokia.com'"=20 <Pasi.Eronen@nokia.com>
        Subject:     =  =20  RE: [AAA-WG]: Application IDs for=20 EAP



> The big question I think you have all been discussing = is what=20 application ID
> is used within application y for the commands=20 inherited.  My first thoughts
> were that the original = commands=20 should use an application ID of x.  Your
> proposal, as I=20 understand it, is that they should include an application ID
> = of=20 y.

RFC 3588 is fairly clear on what is required. =  Changing the=20 application ID
of existing commands and AVPs to "y" from "x" = unecessarily=20 will break
interoperability with existing implementations of those = commands.

> An initial assumption is that if the = capabilities=20 exchange is completed
> only for application y, then the = recipient=20 shouldn't acept commands with
> an application ID of = x.

A=20 Diameter peer should advertise *all* applications that it supports.=20  So
if commands with application X and commands with = application Y are=20 being
used, then *both* should be advertised.

> On the = otherhand,=20 if application y doesn't define those commands an
> application = y client=20 or server wouldn't necessarily implement support for
>=20 them.

That's also true -- a Diameter application document = needs to=20 explicitly
state what commands MUST, SHOULD or MAY be implemented = for=20 that
application.  It also needs to state what = application-IDs must be=20 used for
those commands.

> The rules in RFC 3588 that = cause new=20 applications to be created lead me to
> believe that there will = eventually be a number of applications that inherit
> commands = from=20 earlier applications, however there doesn't seem to be a = clear
>=20 definition of how an application should inherit commands.

RFC = 3588 is=20 very explicit on this point -- new application IDs can only = be
used if the=20 command is fundamentally changed, such as by changing = the
round-trips, or=20 adding a new mandatory AVP.  Otherwise the existing
command = definition=20 (and application ID) is used.  Doing anything else
breaks = Diameter=20 interoperability.





*******************************************************= ***********************

The=20 content of this e-mail may be confidential or legally
privileged. = If you=20 are not the named addressee or the intended
recipient please do = not copy it=20 or forward it to anyone. If you have
received this email in error = please=20 destroy it and kindly notify the
sender and = postmaster.ie@vodafone.com.=20 Email cannot be
guaranteed to be secure or error-free, it is your=20 responsibility
to ensure that the message (including attachments) = is=20 safe
and authorised for use in your environment.
Vodafone = Ireland=20 Limited. Directors: Peter Bamford Chairman (UK),
Pauline Best = (UK), Paul=20 Donovan Chief Executive (UK),
Gerry Fahy, Dermot Griffin, David = Boorman=20 (UK),
David Smithwhite (UK), Patrick Teahon, Alfred = Kane.
Registered in=20 Ireland at MountainView, Leopardstown, Dublin 18.
Co Reg No.: = 326967 VAT=20 Reg No.=20 = IE6346967G

******************************************************= ************************
------_=_NextPart_001_01C45D2C.39ED4618-- From owner-aaa-wg@merit.edu Mon Jun 28 13:08:35 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16615 for ; Mon, 28 Jun 2004 13:08:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 995219122F; Mon, 28 Jun 2004 13:08:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62EBE91269; Mon, 28 Jun 2004 13:08:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 755839122F for ; Mon, 28 Jun 2004 13:08:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A82259CD1; Mon, 28 Jun 2004 13:08:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id C56F559C35 for ; Mon, 28 Jun 2004 13:08:18 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5SH7Tr29336; Mon, 28 Jun 2004 10:07:29 -0700 Date: Mon, 28 Jun 2004 10:07:28 -0700 (PDT) From: Bernard Aboba To: Christopher Richards Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Application ID collision for MIPv4 and DCC In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The MIPv4 draft has expired so I presume that it is no longer valid and it's > application-id can be re-assigned to DCCA without issue. Is that right? No. Diameter MIPv4 is now under consideration by the IESG. Please assign another application-id. From owner-aaa-wg@merit.edu Mon Jun 28 13:25:06 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17240 for ; Mon, 28 Jun 2004 13:25:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5B13991236; Mon, 28 Jun 2004 13:24:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2ACB691237; Mon, 28 Jun 2004 13:24:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 004BC91236 for ; Mon, 28 Jun 2004 13:24:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE5FD59B99; Mon, 28 Jun 2004 13:24:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrtps06s.nortelnetworks.com (zrtps06s.nortelnetworks.com [47.140.48.50]) by segue.merit.edu (Postfix) with ESMTP id 6C95359CA1 for ; Mon, 28 Jun 2004 13:24:52 -0400 (EDT) Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps06s.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5SHOZW08716; Mon, 28 Jun 2004 13:24:35 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 28 Jun 2004 13:24:35 -0400 Message-ID: From: "Christopher Richards" To: "'Bernard Aboba'" Cc: aaa-wg@merit.edu, "'marco.stura@nokia.com'" , Harri.Hakala@ericsson.com, Leena.Mattila@ericsson.com, juha-pekka.koskinen@nokia.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: Application ID collision for MIPv4 and DCC Date: Mon, 28 Jun 2004 13:24:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45D34.A49DD270" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45D34.A49DD270 Content-Type: text/plain I think DCCA is also with the IESG. So I'll leave it to the author's or WG chairs to follow up on this issue. Cheers, Chris Tel: +1 613 763 8031 ESN: 393 8031 -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: June 28, 2004 1:07 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Application ID collision for MIPv4 and DCC > The MIPv4 draft has expired so I presume that it is no longer valid > and it's application-id can be re-assigned to DCCA without issue. Is > that right? No. Diameter MIPv4 is now under consideration by the IESG. Please assign another application-id. ------_=_NextPart_001_01C45D34.A49DD270 Content-Type: text/html RE: [AAA-WG]: Application ID collision for MIPv4 and DCC

I think DCCA is also with the IESG. So I'll leave it to the author's or WG chairs to follow up on this issue.

Cheers,
Chris

Tel:    +1 613 763 8031
ESN:    393 8031


-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: June 28, 2004 1:07 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Application ID collision for MIPv4 and DCC


> The MIPv4 draft has expired so I presume that it is no longer valid
> and it's application-id can be re-assigned to DCCA without issue. Is
> that right?

No. Diameter MIPv4 is now under consideration by the IESG.  Please assign another application-id.

------_=_NextPart_001_01C45D34.A49DD270-- From owner-aaa-wg@merit.edu Mon Jun 28 16:52:51 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03501 for ; Mon, 28 Jun 2004 16:52:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 621C39123C; Mon, 28 Jun 2004 16:50:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31B27912B3; Mon, 28 Jun 2004 16:50:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 760989123C for ; Mon, 28 Jun 2004 16:50:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CEF359CB0; Mon, 28 Jun 2004 16:50:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.sttnwaho.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id D55E359C1D for ; Mon, 28 Jun 2004 16:50:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i5SKnCK09909 for ; Mon, 28 Jun 2004 13:49:12 -0700 Date: Mon, 28 Jun 2004 13:49:12 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG Last Call on draft-ietf-aaa-eap-08.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is an announcement of a AAA WG Last Call on the Diameter EAP document, prior to sending this document to the IESG for consideration as a Proposed Standard. The document is available for examination here: http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-08.txt The WG last call will last until midnite PDT on July 14, 2004. Please send your comments to the AAA WG mailing list at aaa-wg@merit.edu in the format specified on the AAA WG Issues list: http://www.drizzle.com/~aboba/AAA/issues.html From owner-aaa-wg@merit.edu Tue Jun 29 02:11:10 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20562 for ; Tue, 29 Jun 2004 02:11:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1E0F9121F; Tue, 29 Jun 2004 02:10:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 676A99123F; Tue, 29 Jun 2004 02:10:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AEE29121F for ; Tue, 29 Jun 2004 02:10:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D1B559FD2; Tue, 29 Jun 2004 02:10:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from eagle.ericsson.se (eagle.ericsson.se [193.180.251.53]) by segue.merit.edu (Postfix) with ESMTP id 8CB1C59FD5 for ; Tue, 29 Jun 2004 02:10:54 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i5T6AiAh019704 for ; Tue, 29 Jun 2004 08:10:53 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 29 Jun 2004 08:10:44 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 29 Jun 2004 08:10:44 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'Christopher Richards'" , "'Bernard Aboba'" Cc: aaa-wg@merit.edu, "'marco.stura@nokia.com'" , "Leena Mattila (TU/LMF)" , juha-pekka.koskinen@nokia.com, john.loughney@nokia.com Subject: RE: [AAA-WG]: Application ID collision for MIPv4 and DCC Date: Tue, 29 Jun 2004 08:10:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 29 Jun 2004 06:10:44.0656 (UTC) FILETIME=[D0262300:01C45D9F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, RFC 3588 defines (sections 2.4 & 11.3) following Application Identifier = Values: Diameter Common Messages 0 NASREQ 1 [NASREQ] Mobile-IP 2 [DIAMMIP] Diameter Base Accounting 3 Relay 0xffffffff I assume that the MIPv4 should use the Application Identifier defined = by the RFC 3588, that is the MIPv4 should use the already allocated value 2 in their = application.=20 We have suggested Application Id value 4 to the IANA, so I think that = we don't have any=20 collision between Application Ids. But in the end it will be up to the = IANA to allocate=20 Application Identifier values for Diameter applications.=20 Regards..........Harri -----Original Message----- From: Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 28. kes=E4kuuta 2004 20:24 To: 'Bernard Aboba' Cc: aaa-wg@merit.edu; 'marco.stura@nokia.com'; Harri Hakala (JO/LMF); = Leena Mattila (TU/LMF); juha-pekka.koskinen@nokia.com; = john.loughney@nokia.com Subject: RE: [AAA-WG]: Application ID collision for MIPv4 and DCC I think DCCA is also with the IESG. So I'll leave it to the author's or = WG chairs to follow up on this issue.=20 Cheers,=20 Chris=20 Tel: +1 613 763 8031=20 ESN: 393 8031=20 -----Original Message-----=20 From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: June 28, 2004 1:07 PM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: aaa-wg@merit.edu=20 Subject: Re: [AAA-WG]: Application ID collision for MIPv4 and DCC=20 > The MIPv4 draft has expired so I presume that it is no longer valid=20 > and it's application-id can be re-assigned to DCCA without issue. Is=20 > that right?=20 No. Diameter MIPv4 is now under consideration by the IESG. Please = assign another application-id.=20 From owner-aaa-wg@merit.edu Tue Jun 29 03:07:24 2004 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27011 for ; Tue, 29 Jun 2004 03:07:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2C549122C; Tue, 29 Jun 2004 03:07:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A27BE9127F; Tue, 29 Jun 2004 03:07:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FD899122C for ; Tue, 29 Jun 2004 03:07:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 551F659F95; Tue, 29 Jun 2004 03:07:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 92E2F59FF1 for ; Tue, 29 Jun 2004 03:07:07 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T773J29644; Tue, 29 Jun 2004 10:07:03 +0300 (EET DST) X-Scanned: Tue, 29 Jun 2004 10:05:44 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5T75itr008282; Tue, 29 Jun 2004 10:05:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00UToVI5; Tue, 29 Jun 2004 10:05:43 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5T75gH18678; Tue, 29 Jun 2004 10:05:42 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 29 Jun 2004 10:05:41 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: [AAA-WG]: Application IDs for EAP Date: Tue, 29 Jun 2004 10:05:41 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C11B@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Application IDs for EAP Thread-Index: AcRdKNuwJnu6SA9nQymlueOpychMOQAenAAw From: To: , X-OriginalArrivalTime: 29 Jun 2004 07:05:41.0846 (UTC) FILETIME=[7D6D6760:01C45DA7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > > The rules in RFC 3588 that cause new applications to be=20 > > created lead me to believe that there will eventually be=20 > > a number of applications that inherit commands from earlier=20 > > applications, however there doesn't seem to be a clear > > definition of how an application should inherit commands. >=20 > RFC 3588 is very explicit on this point -- new application=20 > IDs can only be used if the command is fundamentally changed,=20 > such as by changing the round-trips, or adding a new mandatory AVP. =20 > Otherwise the existing command definition (and application ID) is=20 > used. Doing anything else breaks Diameter interoperability. This seems to imply that a new application can't borrow only=20 a subset of mandatory commands from an existing application..? Otherwise we could get a conflict. Let's assume that application X has commands C1 and C2, and application Y defines a new command C3 and borrows C1 from X (without any new mandatory AVPs). It seems that a Diameter server implementing only Y can't advertise support for X, since it does not implement C2.=20 But using application identifier of X for C1 is not allowed either, since this seems to contradict the text saying that=20 "When a request is routed, the target server MUST have=20 advertised the Application Identifier (see Section 2.4) for=20 the given message". Another related issue is whether two different applications could use the same AVP (in the same command and with the same application ID) for slightly different purposes. At least this happens all the time with RADIUS, but perhaps the different uses can be distinguished even if the application ID is the same... Best regards, Pasi