From owner-aaa-wg@merit.edu Sat May 1 02:28: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 CAA11797 for ; Sat, 1 May 2004 02:28:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D8049121B; Sat, 1 May 2004 02:28:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 670839121E; Sat, 1 May 2004 02:28: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 7770C9121B for ; Sat, 1 May 2004 02:28:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 66A9A58E9B; Sat, 1 May 2004 02:28:26 -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 BDA0E58E9E for ; Sat, 1 May 2004 02:28:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i416WxA07246 for ; Fri, 30 Apr 2004 23:32:59 -0700 Date: Fri, 30 Apr 2004 23:32:59 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk David Mitton has updated the NASREQ draft for perhaps the last time. This version is available at: http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt Further changes have been made to the section on re-auth. If there are no objections, the draft will be submitted for publication by the RFC editor by May 6, 2004. From owner-aaa-wg@merit.edu Sat May 1 02:41: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 CAA12788 for ; Sat, 1 May 2004 02:41:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B599E9121E; Sat, 1 May 2004 02:40:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B5F79121F; Sat, 1 May 2004 02:40: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 4A9939121E for ; Sat, 1 May 2004 02:40:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 345F358E84; Sat, 1 May 2004 02:40:58 -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 6FC2758E57 for ; Sat, 1 May 2004 02:40:57 -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 i416elH29563; Sat, 1 May 2004 09:40:47 +0300 (EET DST) X-Scanned: Sat, 1 May 2004 09:39:32 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i416dWn5022915; Sat, 1 May 2004 09:39:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00NdDPgy; Sat, 01 May 2004 09:39:31 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i416dVH19813; Sat, 1 May 2004 09:39:31 +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); Sat, 1 May 2004 09:39:31 +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]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Sat, 1 May 2004 09:39:30 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Thread-Index: AcQvRZxYFoS2eRscRRKSgvgjHtsvKQAAVk5w From: To: , X-OriginalArrivalTime: 01 May 2004 06:39:31.0259 (UTC) FILETIME=[0EE998B0:01C42F47] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, > David Mitton has updated the NASREQ draft for perhaps the last time. > This version is available at: > http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-15.txt >=20 > Further changes have been made to the section on re-auth. >=20 > If there are no objections, the draft will be submitted for = publication by > the RFC editor by May 6, 2004. I had a quick look at the changes & I say ship it. John From owner-aaa-wg@merit.edu Sat May 1 12:21: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 MAA29523 for ; Sat, 1 May 2004 12:21:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42D399121F; Sat, 1 May 2004 12:20:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1491391221; Sat, 1 May 2004 12:20: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 EE6ED9121F for ; Sat, 1 May 2004 12:20:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4C7158E89; Sat, 1 May 2004 12:20:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hotmail.com (bay18-f63.bay18.hotmail.com [65.54.187.113]) by segue.merit.edu (Postfix) with ESMTP id 8566358B81 for ; Sat, 1 May 2004 12:20:57 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 1 May 2004 09:20:56 -0700 Received: from 212.213.204.99 by by18fd.bay18.hotmail.msn.com with HTTP; Sat, 01 May 2004 16:20:56 GMT X-Originating-IP: [212.213.204.99] X-Originating-Email: [marco_stura@hotmail.com] X-Sender: marco_stura@hotmail.com From: "Stura Marco" To: crich@nortelnetworks.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCC: CLIENT, SESSION BASED State Machine Date: Sat, 01 May 2004 19:20:56 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 May 2004 16:20:56.0783 (UTC) FILETIME=[484E1DF0:01C42F98] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, >Would it not be better to grant some limited service usage to the end user >and move to the Open state. This will then allow the DCC client to >re-authorise the used service at a later time when it may pass. When the failure to send event or temporary error occur, we have clearly a problem with the server because e.g. the server is down, too busy or the connection is broken. We also tried, without success, to contact an alternative server if failover for the session was supported. There is actually no reason to keep the session open in the client in such circumstances. Note that during the lifetime of the problem the server may close the session or may not have even opened the session yet (i.e. in case of the first interrogation), therefore you would just consume resources in the client in vain. Your client may eventually attempt to open a new session (i.e. sending initial CCR) for the ongoing service e.g. when the transport connection is brought up again or according to some other implementation dependant strategies. As per the level of service you grant to the end user when CCFH=CONTINUE, this may depend on some local policy. I think the state machine is good enough as it is, you can implement all the non-mandatory policies/strategies on top of that if you want to. Regards Marco _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus From owner-aaa-wg@merit.edu Sat May 1 14:01:00 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 OAA11568 for ; Sat, 1 May 2004 14:01:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3C3F9121D; Sat, 1 May 2004 14:00:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD5C591221; Sat, 1 May 2004 14:00: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 8F14D9121D for ; Sat, 1 May 2004 14:00:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7142F58DA6; Sat, 1 May 2004 14:00: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 0D60B58CF4 for ; Sat, 1 May 2004 14:00:46 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id E06988981B; Sat, 1 May 2004 21:00:38 +0300 (EEST) Message-ID: <4093E504.2060204@kolumbus.fi> Date: Sat, 01 May 2004 20:57:24 +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: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs References: <5.2.1.1.2.20040430181746.03328890@getmail.mitton.com> In-Reply-To: <5.2.1.1.2.20040430181746.03328890@getmail.mitton.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 I agree with David on this one. In general, translation between RADIUS and Diameter is dependent on the specific application (such as NASREQ) that we are talking about. --Jari David Mitton wrote: > On 4/30/2004 04:26 PM -0500, Christopher Richards wrote: > >> Thanks Dave. >> >> Does the NASREQ draft apply to non-NASREQ Diameter applications? >> >> Specifically, RFC3588 does not say that RADIUS code 26 is prohibited. >> >> Should your description be added to the errata of RFC3588? >> >> Cheers, >> Chris. > > > No. > > NASreq is intended to be the generic RADIUS "replacement" within Diameter. > A RADIUS interaction such as VSAs is properly addressed there. > > Even as it is, NASreq Section 9 does not explicitly address all > potential RADIUS interaction problems. We are certainly not going to > backfill it into RFC 3588. > > The Diameter drafts/RFCs are purposely segmented so that they may get > finished within our useful lifetimes. Expect more application bolt-ons, > not less. > > Dave. > > From owner-aaa-wg@merit.edu Mon May 3 03:06: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 DAA10688 for ; Mon, 3 May 2004 03:06:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EAB69123A; Mon, 3 May 2004 03:06:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 022699123C; Mon, 3 May 2004 03:06:03 -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 A93299123A for ; Mon, 3 May 2004 03:06:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86A1758F85; Mon, 3 May 2004 03:06:00 -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 8B7A958F79 for ; Mon, 3 May 2004 03:05:59 -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 i4375iJ10949; Mon, 3 May 2004 10:05:44 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 10:04:19 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4374JYX005527; Mon, 3 May 2004 10:04:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00M0NY35; Mon, 03 May 2004 10:04:18 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 i4374IH14862; Mon, 3 May 2004 10:04:18 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 10:04:17 +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]: Questions on RFC 3588 Date: Mon, 3 May 2004 10:04:17 +0300 Message-ID: Thread-Topic: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1g From: To: , X-OriginalArrivalTime: 03 May 2004 07:04:17.0645 (UTC) FILETIME=[D9B199D0:01C430DC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Ulrich, > 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx = Rel-5) for which IANA has=20 > allocated an application-Id (167772151). Now 3GPP are in the process = of defining a new version=20 > of this application (3GPP Cx Rel-6). The new version is an extension = of the old version,i.e.=20 > nodes supporting the new version do also support the old version. The = new version does not=20 > replace the old version, i.e. interworking between nodes supporting = only the old version and=20 > nodes supporting the old and the new version is required. > > Let us assume that the difference between the old version and the new = version is that a new AVP=20 > is added to a command and this AVP has the M-bit set. A new mandatory AVP is a requirement for a new application ID. > The first question is: Is it necessary to get a new application-Id = allocated by IANA for the=20 > new version, or is it possible for both versions to share the same = (already allocated)=20 > application-Id, and to achieve interoperability between the two = versions by means of the mechanism=20 > defined in RFC 3588 section 4.1 (description of the 'M' bit), i.e. the = node sending the new=20 > mandatory AVP must be prepared to receive error code 5001 (unsupported = AVP) and re-send the command=20 > in a Rel-5 compliant form? If you wanted the above behavior, the new AVP defined by 3GPP should not = be mandatory, but it should be optional, then the above behavior would be compliant to 3588. > Here are some quotes from RFC 3588 which you might want to consider = when answering the question: > -In section 1.1: "AVPs may be added arbitrarily to Diameter messages, = so long as the required AVPs=20 > are included and AVPs that are explicitly excluded are not included."=20 > -In section 1.2.3:" Should a new Diameter usage scenario find itself = unable to fit within an=20 > existing application without requiring major changes to the = specification, it may be desirable=20 > to create a new Diameter application. Major changes to an application = include: - Adding new=20 > AVPs to the command, which have the "M" bit set." > -In section 1.2.3:"Creation of a new application should be viewed as a = last resort." =20 Defining new applications are a last resort, of course. A real reason = for having a new application would be because you are adding new functionality to Diameter that = cannot be met with existing applicaitions. Adding a new AVPs would not really qualify, in my = opinion, unless they drastically changed the behavior. > The second question is similar: If the difference between the old = version and the new version=20 > is that an existing mandatory AVP is removed from a command is it then = necessary to get a=20 > new application-Id allocated, or can interoperability be achieved in = the way that the node=20 > omitting the mandatory AVP must be prepared to receive error 5005 = (missing AVP) and re-send the=20 > command in a Rel-5 compliant form? You are saying that you are removing an mandatory AVP? I guess to = ensure interoperability, a new Application ID would be needed - but why are you removing the AVP? The = question is quite hypothetical, and it is hard to advise the proper behavior without more concrete = examples. > The last question: If the difference beween the old version and the = new version is that a new=20 > command is added is it then necessary to get a new application-Id = allocated, or can interoperability=20 > be achieved in the way that the node sending the new command must be = prepared to receive the error=20 > 3001 (unsupported command) and fall back to Rel-5? In general, adding new commands mean that a new Application ID is = needed. However, your questions are extremely hypothetical. The important = questions are why are you adding new (mandatory) AVPs and commands. Are these really = needed? Arbitrarily adding new mandatory AVPs and commands create interoperability problems, and = that is why the Diameter Base spec tries to advise against doing so, unless absolutely = necessarily. best regards, John From owner-aaa-wg@merit.edu Mon May 3 04:04:23 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 EAA13338 for ; Mon, 3 May 2004 04:04:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E9A489123C; Mon, 3 May 2004 04:04:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4FDA9123D; Mon, 3 May 2004 04:04:11 -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 E94DC9123C for ; Mon, 3 May 2004 04:04:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CFA1A58367; Mon, 3 May 2004 04:04:09 -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 DE09358BA2 for ; Mon, 3 May 2004 04:04:08 -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 i43841J16582; Mon, 3 May 2004 11:04:01 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 11:02:27 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i4382R9X006468; Mon, 3 May 2004 11:02:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00j2kWRm; Mon, 03 May 2004 11:02:26 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 i4382PH27985; Mon, 3 May 2004 11:02:25 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 11:02:15 +0300 Message-ID: <4095FC87.80800@nokia.com> Date: Mon, 03 May 2004 11:02:15 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-app-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 08:02:15.0092 (UTC) FILETIME=[F269E740:01C430E4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Wolfgang: Thanks for your review. See answers below: ext Beck01, Wolfgang wrote: > Hello, > > p 12, section 5.3 > > step 12: "SIP server 2 will validate the credentials.." > How can the SIP server do this? It has asked for authentication > parameters in steps 5 and 6, but it doesn't have the user's password. I think you have a point here, but let me investigate a bit more. I will reply in a separate e-mail laster. > > p 32, section 7.7 > "The SIP-Method AVP MUST include the SIP method name of the SIP > request that triggered this Diameter MAR message. > > The Diameter MAR message MUST include a SIP-AOR AVP. The SIP-AOR AVP > indicates the intended Address-of-Record of the SIP request. " > > Why are SIP-Method and SIP-AOR mandatory? I would have expected a > mandatory Contact: or From: URI, or some other information about > the user requesting authentication. Let me first start saying that these AVPs are here in support for the scenario decribed in Section 5.4, where a SIP Server (Diameter Client) is requesting authentication/authorization from the SIP Client. The idea is: a user may be authorized to send certain SIP requests (e.g., INVITE) but not others (SUBSCRIBE) to a certain server (i.e., the SIP-AOR). Since the Diameter server is authorizing those SIP transactions, the Diameter server must get the SIP method and Address-of-Record included in the SIP message. The Contact header merely indicates a hostname or IP address where the user is logged in, but typically this is a dynamic address (e.g., allocated by DHCP). So it does not have any value for the purpose of authentication/authorization. The From header in SIP is even worse. Like in e-mail, From is an end-to-end header in SIP, meaning that the SIP client can insert any value. Actually, the SIP RFC recommends to insert a From header set to miningless URI (e.g., sip:anonymous@anonymous.invalid) when the user request privacy. So we can't use the From header for authentication purposes, since it does not contain any meaningful information. The action that we are looing for is to authenticate the user. Authentication of the user can be achieved by the HTTP Digest algorithm, but not by the From or Contact headers. > > p 48, typo 'Digest-Relam' Good. We will fix it. > > Regards, > > Wolfgang > Thanks a lot for your review. - Miguel > > -- > Wolfgang Beck > T-Systems > Internet Netzplattformen > Am Kavalleriesand 3 > 64295 Darmstadt > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 3 05:03:17 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 FAA15587 for ; Mon, 3 May 2004 05:03:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD5EC9123D; Mon, 3 May 2004 05:03:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AFE99123E; Mon, 3 May 2004 05:03:03 -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 2D8679123D for ; Mon, 3 May 2004 05:03:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 196A658A1D; Mon, 3 May 2004 05:03:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 0B4E758E0A for ; Mon, 3 May 2004 05:03:01 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i4387LkM019835 for ; Mon, 3 May 2004 10:07:21 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [AAA-WG]: Questions on RFC 3588 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 3 May 2004 11:02:54 +0200 Message-ID: <64F95EC22E92334EA21188664F36A4820241C3@gkshfd03.gksag.net> Thread-Topic: [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxA= From: "Wiehe Ulrich" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello John, Thank you for your response. I'm not sure whether I correctly understand = your answer. Can you please confirm that a) A new mandatory AVP (i.e. an AVP which is not surrounded by square brackets in the command's ABNF definition) is a requirement for a new application ID. b) A new optional AVP (i.e. an AVP surrounded by square brackets in the command's ABNF definition) may be added without requiring a new = application ID. If the optional AVP's M-bit is set the behavior described in RFC = 3588 section 4.1 applies i.e. the sending (Rel-6) node shall be prepared to receive error 5001 and may then decide to re-send the command in a Rel-5 compliant form. If the optional AVP's M-bit is cleared the = reciving(Rel-5) node will silently discard the AVP. Thank you again Ulrich -----Urspr=FCngliche Nachricht----- Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Montag, 3. Mai 2004 09:04 An: Wiehe Ulrich; aaa-wg@merit.edu Betreff: RE: [AAA-WG]: Questions on RFC 3588 Hello Ulrich, > 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx = Rel-5) for which IANA has=20 > allocated an application-Id (167772151). Now 3GPP are in the process = of defining a new version=20 > of this application (3GPP Cx Rel-6). The new version is an extension = of the old version,i.e.=20 > nodes supporting the new version do also support the old version. The = new version does not=20 > replace the old version, i.e. interworking between nodes supporting = only the old version and=20 > nodes supporting the old and the new version is required. > > Let us assume that the difference between the old version and the new version is that a new AVP=20 > is added to a command and this AVP has the M-bit set. A new mandatory AVP is a requirement for a new application ID. > The first question is: Is it necessary to get a new application-Id allocated by IANA for the=20 > new version, or is it possible for both versions to share the same = (already allocated)=20 > application-Id, and to achieve interoperability between the two = versions by means of the mechanism=20 > defined in RFC 3588 section 4.1 (description of the 'M' bit), i.e. the = node sending the new=20 > mandatory AVP must be prepared to receive error code 5001 (unsupported = AVP) and re-send the command=20 > in a Rel-5 compliant form? If you wanted the above behavior, the new AVP defined by 3GPP should not = be mandatory, but it should be optional, then the above behavior would be compliant to 3588. > Here are some quotes from RFC 3588 which you might want to consider = when answering the question: > -In section 1.1: "AVPs may be added arbitrarily to Diameter messages, = so long as the required AVPs=20 > are included and AVPs that are explicitly excluded are not included."=20 > -In section 1.2.3:" Should a new Diameter usage scenario find itself = unable to fit within an=20 > existing application without requiring major changes to the = specification, it may be desirable=20 > to create a new Diameter application. Major changes to an application include: - Adding new=20 > AVPs to the command, which have the "M" bit set." > -In section 1.2.3:"Creation of a new application should be viewed as a = last resort." =20 Defining new applications are a last resort, of course. A real reason = for having a new application would be because you are adding new functionality to Diameter that = cannot be met with existing applicaitions. Adding a new AVPs would not really qualify, in my = opinion, unless they drastically changed the behavior. > The second question is similar: If the difference between the old = version and the new version=20 > is that an existing mandatory AVP is removed from a command is it then necessary to get a=20 > new application-Id allocated, or can interoperability be achieved in = the way that the node=20 > omitting the mandatory AVP must be prepared to receive error 5005 = (missing AVP) and re-send the=20 > command in a Rel-5 compliant form? You are saying that you are removing an mandatory AVP? I guess to = ensure interoperability, a new Application ID would be needed - but why are you removing the AVP? The question is quite hypothetical, and it is hard to advise the proper behavior without more concrete = examples. > The last question: If the difference beween the old version and the = new version is that a new=20 > command is added is it then necessary to get a new application-Id allocated, or can interoperability=20 > be achieved in the way that the node sending the new command must be prepared to receive the error=20 > 3001 (unsupported command) and fall back to Rel-5? In general, adding new commands mean that a new Application ID is = needed. However, your questions are extremely hypothetical. The important = questions are why are you adding new (mandatory) AVPs and commands. Are these really = needed? Arbitrarily adding new mandatory AVPs and commands create interoperability problems, and = that is why the Diameter Base spec tries to advise against doing so, unless absolutely = necessarily. best regards, John From owner-aaa-wg@merit.edu Mon May 3 06:07: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 GAA18276 for ; Mon, 3 May 2004 06:07:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7B0C9123E; Mon, 3 May 2004 06:07:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B53FD9123F; Mon, 3 May 2004 06:07: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 84C089123E for ; Mon, 3 May 2004 06:07:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F92158FA1; Mon, 3 May 2004 06:07:25 -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 66A9858B2D for ; Mon, 3 May 2004 06:07:24 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 3 May 2004 10:23:05 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 10:23:04 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu Subject: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-a pp-02 Date: Mon, 3 May 2004 10:23:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, >> Why are SIP-Method and SIP-AOR mandatory? I would have expected a >> mandatory Contact: or From: URI, or some other information about >> the user requesting authentication. > > Let me first start saying that these AVPs are here in support for the > scenario decribed in Section 5.4, where a SIP Server (Diameter Client) > is requesting authentication/authorization from the SIP Client. > > The idea is: a user may be authorized to send certain SIP requests > (e.g., INVITE) but not others (SUBSCRIBE) to a certain server (i.e., the > SIP-AOR). Since the Diameter server is authorizing those SIP > transactions, the Diameter server must get the SIP method and > Address-of-Record included in the SIP message. Of course, this a realistic and useful scenario. But is it really a MUST? Is this functionality really vital? > The action that we are looing for is to authenticate the user. > Authentication of the user can be achieved by the HTTP Digest algorithm, > but not by the From or Contact headers. That was a misunderstanding. I did not want to suggest an authentication based on the Contact: or From: header. I was thinking of user-specific nonces or challenges that might be required by future authentication methods. Wolfgang -- Wolfgang Beck T-Systems Internet Netzplattformen +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt From owner-aaa-wg@merit.edu Mon May 3 06:22: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 GAA18836 for ; Mon, 3 May 2004 06:22:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4E839123F; Mon, 3 May 2004 06:22:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C71991240; Mon, 3 May 2004 06:22: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 63D059123F for ; Mon, 3 May 2004 06:22:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 481A558F85; Mon, 3 May 2004 06:22:12 -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 7F60158AD4 for ; Mon, 3 May 2004 06:22:11 -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 i43AMAk26693; Mon, 3 May 2004 13:22:10 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:19:40 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i43AJerJ010534; Mon, 3 May 2004 13:19:40 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00vRzxUi; Mon, 03 May 2004 13:19:39 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 i43AJcH09826; Mon, 3 May 2004 13:19:38 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:19:30 +0300 Message-ID: <40961CB2.2020109@nokia.com> Date: Mon, 03 May 2004 13:19:30 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: Re: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-a pp-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 10:19:30.0944 (UTC) FILETIME=[1F5D3000:01C430F8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ext Beck01, Wolfgang wrote: > Miguel, > > >>>Why are SIP-Method and SIP-AOR mandatory? I would have expected a >>>mandatory Contact: or From: URI, or some other information about >>>the user requesting authentication. >> >>Let me first start saying that these AVPs are here in support for the >>scenario decribed in Section 5.4, where a SIP Server (Diameter Client) >>is requesting authentication/authorization from the SIP Client. >> >>The idea is: a user may be authorized to send certain SIP requests >>(e.g., INVITE) but not others (SUBSCRIBE) to a certain server (i.e., the >>SIP-AOR). Since the Diameter server is authorizing those SIP >>transactions, the Diameter server must get the SIP method and >>Address-of-Record included in the SIP message. > > Of course, this a realistic and useful scenario. But is it really a MUST? > Is this functionality really vital? > Yes, I think it is a MUST. All SIP requests contain a method name (INVITE, REGISTER, etc.) and a Request-URI (the intended destination). So there is no problem in the Diameter client inserting this information. Now it is a matter of the Diameter server using that information for authorization or not. Some Diameter servers will be configured to use this information, others will simply provide authorization based on "the user has to be a customer of our network". In short: the Diameter client always send them, the Diameter server decides whether use them or not. > >>The action that we are looing for is to authenticate the user. >>Authentication of the user can be achieved by the HTTP Digest algorithm, >>but not by the From or Contact headers. > > That was a misunderstanding. I did not want to suggest an authentication > based on the Contact: or From: header. I was thinking of user-specific > nonces or challenges that might be required by future authentication methods. > I wouldn't dare to think too much in "future authentication methods", when we don't even provide support for all the *current authentication methods". Bear in mind that we are providing support for HTTP Digest authentication applied to SIP. We don't provide support for other authentication mechanisms (e.g., TLS, S/MIME, etc.). We have a two-folded reason: a) SIP only mandates HTTP Digest authentication. Other methods are optional b) We found very clear requirements to support HTTP Digest authentication, we didn't find any interest (nore requirements) in supporting other current authentication mechanisms. Consequently, I wouldn't dare to start thinking of furutre authentication mechanisms when we don't even have full support for current mechanisms. But if you have some clear requirement or scenario in your mind, please let us know it. - Miguel > > Wolfgang > > > -- > Wolfgang Beck > T-Systems > Internet Netzplattformen > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 3 06:52:00 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 GAA20369 for ; Mon, 3 May 2004 06:52:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE05C91240; Mon, 3 May 2004 06:51:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8973291242; Mon, 3 May 2004 06:51: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 0DFD991240 for ; Mon, 3 May 2004 06:51:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E17B658F3D; Mon, 3 May 2004 06:51:46 -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 E92EC58D31 for ; Mon, 3 May 2004 06:51:45 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43ApiH14496 for ; Mon, 3 May 2004 13:51:45 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 13:50:44 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43AoixR019062 for ; Mon, 3 May 2004 13:50:44 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00iFDu7B; Mon, 03 May 2004 13:50: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 i43AogH22570 for ; Mon, 3 May 2004 13:50:42 +0300 (EET DST) Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 13:50:42 +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]: question on Diameter Date: Mon, 3 May 2004 13:50:41 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAFA9@esebe012.ntc.nokia.com> Thread-Topic: [AAA-WG]: question on Diameter Thread-Index: AcQuyBurtXDUqzNqQkq3EWVj7PapygCMkQiw From: To: X-OriginalArrivalTime: 03 May 2004 10:50:42.0474 (UTC) FILETIME=[7AE200A0:01C430FC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Correct me if I'm wrong, but according to the Peer State Machine defined in RFC3588 CER/CEA negotiation is possible within existing connection. > Upgrade on the fly? Yes, this is one possible use-case. Other would be configuration change -- for example an ISP could enable a Diameter-Proxy to support an additional Diameter Application. > Even if a peer is upgraded on the fly without going down, the=20 > right answer is probably to bring up other connections, negotiate = CER/CEA,=20 > and if they are upgraded, drop the existing connections. I think this might be typical behavior, but I don't see any reason in the spec why change in capabilities couldn't be negotiated on-the-fly within existing connection. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: 30 April, 2004 18:34 > To: MCarmen > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: question on Diameter >=20 >=20 >=20 > I don't think this makes sense. >=20 > The peers announce all their capabilities in the CER/CEA and this is > typically something that does not change on the fly. In what scenario > would the fundamental capabilities of the peers change in=20 > mid-connection? > Upgrade on the fly? >=20 > In a situation where firmware is upgraded, connections will > typically go down and the peer will announce its new capabilities and > negotiate them within the CER/CEA. >=20 > Even if a peer is upgraded on the fly without going down, the=20 > right answer > is probably to bring up other connections, negotiate CER/CEA,=20 > and if they > are upgraded, drop the existing connections. This could be=20 > an issue with > RFC 3588 because Diameter only allows one connection at a=20 > time between two > peers. So I think you'd need to bring down a connection=20 > between two peers > to re-negotiate CER/CEA between them. >=20 >=20 >=20 > On Fri, 30 Apr 2004, MCarmen wrote: >=20 > > Hi all, > > > > Just a question on RFC3588. In the CER/CEA chapter it is said: > > > > " When two Diameter peers establish a transport connection,=20 > they MUST > > exchange the Capabilities Exchange messages, as specified=20 > in the peer > > state machine (see Section 5.6). This message allows the=20 > discovery of a > > peer's identity and its capabilities (protocol version=20 > number, supported > > Diameter applications, security mechanisms, etc.) " > > > > Is it possible to exchange again the Capabilities Exchange=20 > messages once > > the connection is already established to modify my capabilities? > > > > thanks, > > MCarmen > > >=20 From owner-aaa-wg@merit.edu Mon May 3 08:57: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 IAA26238 for ; Mon, 3 May 2004 08:57:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BECC91244; Mon, 3 May 2004 08:56:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 175A891245; Mon, 3 May 2004 08:56:55 -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 CCEA491244 for ; Mon, 3 May 2004 08:56:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B620D58FE6; Mon, 3 May 2004 08:56:53 -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 8A08358FE3 for ; Mon, 3 May 2004 08:56:52 -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 i43Cucv21544; Mon, 3 May 2004 15:56:38 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 15:54:46 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i43Cskqh031416; Mon, 3 May 2004 15:54:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00SknJjy; Mon, 03 May 2004 15:54:44 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 i43CsSH09273; Mon, 3 May 2004 15:54:33 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 15:54:10 +0300 Message-ID: <409640F4.3040101@nokia.com> Date: Mon, 03 May 2004 15:54:12 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu, Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: Re: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-app-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 12:54:10.0534 (UTC) FILETIME=[BA6E4060:01C4310D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Wolfang: After doing some research, here is the answer to your first concern. Sorry for the long e-mail, but the subject deserves our attention. Beck01, Wolfgang wrote: > Hello, > > p 12, section 5.3 > > step 12: "SIP server 2 will validate the credentials.." > How can the SIP server do this? It has asked for authentication > parameters in steps 5 and 6, but it doesn't have the user's password. > Let's start from the beginning. The Diameter SIP application offers supports for two scenarios: one where the Diameter server authenticates and authorizes the user, the other where the Diameter server delegates the authentication and authorization to the SIP server. The former is supported in Section 5.2, the latter in Section 5.3. Your concern is about Section 5.3. You are right that the SIP server does not have the password at this stage, therefore, it cannot validate the credentials. Having said that, a possible solution consist of adding a new Digest-Password AVP to the SIP-Authenticate grouped AVP. THIS IS AWFUL because it breaks any security model. We don't want to send passwords over the wire. So I don't pursue this idea anymore. One can thing of the Diameter server sending what RFC 2617 calls H(A1), which is a digest of the username/realm/password that does not change with time. This solution is also fragile, since once guessed, anyone can use it to build digest-requests even without really knowing the password. A feasible solution is: the Diameter server, when creating the authentication challenge (SIP-Authenticate grouped AVP), calculates the expected response from the SIP client, and adds it into a new Digest-Expected-Response AVP. This solution is nice, since it does not break any security. However, its applicability is very limited, since it will only work in the case there is not client information in the computation of the digest-request. For instance, if the client uses qop="auth" or qop="auth-int", then the computation fo the request-digest is based on, among others, the chosen value of qop, the cnonce, perhaps the body... So in this case there is no way the Diameter server can pre-calculate an expected response. Consequently, the only possibility is to fall back to authentication in the Diameter server, which is the scenario supported in Section 5.2 of the Diameter SIP application. However, if there is not qop parameter used, then the Diameter server can pre-calculate an expected response, since it is not dependent on any client information, and send it to the SIP server. The SIP server challenges the SIP client, receives the credentials (request-digest), compares the response with the expected response, and authorizes the SIP request. Is this ok? Any other comments? If not, I propose to modify the Diameter SIP application as follows: a) we add a new Digest-Expected-Response AVP to the SIP-Authenticate grouped AVP. This will convey the expected response calculated at the Diameter server to the SIP server. b) we indicate somewhere in the draft that if the qop parameter is not used (in the Authorization or Proxy-Authorization headers), the SIP proxy can verify the request by itself by comparing the response and the expected response. Otherwise, the SIP server has to fall back to the scenario supported in Section 5.2 (Diameter server authenticates the client). How does that sound? BR, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 3 09:36: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 JAA28086 for ; Mon, 3 May 2004 09:36:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6A34D91246; Mon, 3 May 2004 09:35:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BD7791248; Mon, 3 May 2004 09:35: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 0D67991246 for ; Mon, 3 May 2004 09:35:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EADE558FDB; Mon, 3 May 2004 09:35:56 -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 3AD0D58F77 for ; Mon, 3 May 2004 09:35:56 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 3 May 2004 13:15:24 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 13:15:23 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu Subject: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-s ip-app-02 Date: Mon, 3 May 2004 13:15:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, you wrote: > Yes, I think it is a MUST. All SIP requests contain a method name > (INVITE, REGISTER, etc.) and a Request-URI (the intended destination). > So there is no problem in the Diameter client inserting this > information. To stretch your argument: Why stop here? Wouldn't it be useful to include the whole SIP message? Then, the DIAMETER server could even take SDP into account and restrict the use of certain codecs. Of course, then either the DIAMETER server must be able to parse SIP messages or we must replicate any SIP header with a corresponding AVP. > Consequently, I wouldn't dare to start thinking of future > authentication mechanisms when we don't even have full support for > current mechanisms. > > But if you have some clear requirement or scenario in your mind, please > let us know it. Forget my comment. I was just wondering why you made the request target mandatory and did not mention other headers, like the request origin. Wolfgang From owner-aaa-wg@merit.edu Mon May 3 09:39:07 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 JAA28508 for ; Mon, 3 May 2004 09:39:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8717591248; Mon, 3 May 2004 09:38:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 549C99124A; Mon, 3 May 2004 09:38:55 -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 52E6391248 for ; Mon, 3 May 2004 09:38:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C282658FF6; Mon, 3 May 2004 09:38:53 -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 C5BFD59008 for ; Mon, 3 May 2004 09:38:49 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i43DcfJ28678 for ; Mon, 3 May 2004 16:38:41 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 16:38:06 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i43Dc61J004273 for ; Mon, 3 May 2004 16:38:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00vp0Mvk; Mon, 03 May 2004 16:38:05 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 i43DbxH06388 for ; Mon, 3 May 2004 16:37:59 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 16:37:58 +0300 Message-ID: <40964B36.3010908@nokia.com> Date: Mon, 03 May 2004 16:37:58 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: AAA mailing list Subject: [AAA-WG]: I-D AAA URI -01 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 13:37:58.0686 (UTC) FILETIME=[D8EE6BE0:01C43113] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: I have just submitted a new version of the AAA URI document. There are no functional changes with respect the previous version, just editorial and error fixes. For what I am concerned, this document is finished. The chairs can request WGLC whenever they want (meaning: please read it and provide comments asap). While the document is available in the IETF repository you can download a copy from: http://people.nokia.net/~miguel/drafts/draft-ietf-aaa-uri-01.txt http://people.nokia.net/~miguel/drafts/draft-ietf-aaa-uri-01.html - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 3 10:33: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 KAA05299 for ; Mon, 3 May 2004 10:33:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BAE5F9124A; Mon, 3 May 2004 10:33:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 886A49124B; Mon, 3 May 2004 10:33:37 -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 7A7D49124A for ; Mon, 3 May 2004 10:33:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6517058B0E; Mon, 3 May 2004 10:33: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 620AB58E98 for ; Mon, 3 May 2004 10:33:35 -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 i43EXYH17414; Mon, 3 May 2004 17:33:34 +0300 (EET DST) X-Scanned: Mon, 3 May 2004 17:31:57 +0300 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i43EVvM7013692; Mon, 3 May 2004 17:31:57 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00rm5nhP; Mon, 03 May 2004 17:31:55 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 i43EVoH28475; Mon, 3 May 2004 17:31:50 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 3 May 2004 17:31:49 +0300 Message-ID: <409657D5.1050704@nokia.com> Date: Mon, 03 May 2004 17:31:49 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: Re: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-s ip-app-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 May 2004 14:31:49.0650 (UTC) FILETIME=[5EBC6720:01C4311B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ext Beck01, Wolfgang wrote: > Miguel, > > you wrote: > >>Yes, I think it is a MUST. All SIP requests contain a method name >>(INVITE, REGISTER, etc.) and a Request-URI (the intended destination). >>So there is no problem in the Diameter client inserting this >>information. > > To stretch your argument: Why stop here? Wouldn't it be useful to > include the whole SIP message? Then, the DIAMETER server could > even take SDP into account and restrict the use of certain codecs. > Of course, then either the DIAMETER server must be able to parse SIP > messages or we must replicate any SIP header with a corresponding > AVP. Yes, I see your point, but as you may understand, there might be a stopping point. Perhaps the stoppint point is that the SIP Method and the Request-URI are needed to compute what HTTP Digest calls "A2" (see Section 3.2.2.3 in RFC 2617). A2 is neeeded to compute request-digest (i.e., the response the client sends). So if authentication is done at the Diameter server, then it needs to get the SIP method and the Request-URI, even when those parameters are not used for authorization purposes. Regards, - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 3 10:55: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 KAA06430 for ; Mon, 3 May 2004 10:55:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E41FB9124D; Mon, 3 May 2004 10:55:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3A529124E; Mon, 3 May 2004 10:55: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 9FAD19124D for ; Mon, 3 May 2004 10:55:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6CC2158FC4; Mon, 3 May 2004 10:55:39 -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 B46F658FBB for ; Mon, 3 May 2004 10:55:38 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Mon, 3 May 2004 15:19:54 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 15:19:54 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-a pp-02 Date: Mon, 3 May 2004 15:19:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, > However, if there is not qop parameter used, then the Diameter server > can pre-calculate an expected response, since it is not dependent on any > client information, and send it to the SIP server. The SIP server > challenges the SIP client, receives the credentials (request-digest), > compares the response with the expected response, and authorizes the SIP > request. From RfC 2617, section 3.2.1 about optionality of the qop directive: "This directive is optional, but is made so only for backward compatibility with RFC 2069 [6]; it SHOULD be used by all implementations compliant with this version of the Digest scheme." Is support for an obsolete RfC worth the effort? When I read section 5.3 of your draft, I expected the SIP server to have a local user/passwd/profile database and was a bit confused about steps 5 and 6. But without centralized user/passwd/profile storage, the DIAMETER server becomes in fact a SIP redirecting proxy. Can't we just drop 5.3 completely? Wolfgang From owner-aaa-wg@merit.edu Mon May 3 15:59: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 PAA25883 for ; Mon, 3 May 2004 15:59:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBCED91253; Mon, 3 May 2004 15:58:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 953CE91255; Mon, 3 May 2004 15:58:51 -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 812B791253 for ; Mon, 3 May 2004 15:58:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E4E058AA9; Mon, 3 May 2004 15:58:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from fep21-app.kolumbus.fi (fep21-0.kolumbus.fi [193.229.0.48]) by segue.merit.edu (Postfix) with ESMTP id 8F61C58C1C for ; Mon, 3 May 2004 15:58:49 -0400 (EDT) Received: from kolumbus.fi ([80.186.217.250]) by fep21-app.kolumbus.fi with ESMTP id <20040503195848.MWUS19565.fep21-app.kolumbus.fi@kolumbus.fi>; Mon, 3 May 2004 22:58:48 +0300 Message-ID: <4096A3B2.6040101@kolumbus.fi> Date: Mon, 03 May 2004 22:55:30 +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: Christopher Richards Cc: David Mitton , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs References: <161AA64DA85DFC4BA4D2EB5629B59753068D6ED2@zrc2c012.us.nortel.com> In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B59753068D6ED2@zrc2c012.us.nortel.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 Hmm... good question. Let me think... Well, it seems that for this specific draft, the point is rather moot, because there's currently nothing that DCC could be translated into. When there is, then we can talk about it, but as discussed previously on this list, the translation would be in that other definition i.e. RADIUS prepaid and not in DCC. But your question is valid for other applications. Diameter EAP, for instance, points to NASREQ for the general explanation of the AVP mappings. This may be sufficient for other applications as well. --Jari Christopher Richards wrote: > Hi Jari, > > OK. But does that mean that each application must describe how to handle > RADIUS VSA AVPs within the application? If so, DCC needs this description. > > We could simply paste in the NASREQ statements into DCC. > > Cheers, > Chris. > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Saturday, May 01, 2004 12:57 PM > To: David Mitton > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > I agree with David on this one. In general, translation > between RADIUS and Diameter is dependent on the specific application > (such as NASREQ) that we are talking about. > > --Jari > > David Mitton wrote: > > On 4/30/2004 04:26 PM -0500, Christopher Richards wrote: > > > >> Thanks Dave. > >> > >> Does the NASREQ draft apply to non-NASREQ Diameter applications? > >> > >> Specifically, RFC3588 does not say that RADIUS code 26 is prohibited. > >> > >> Should your description be added to the errata of RFC3588? > >> > >> Cheers, > >> Chris. > > > > > > No. > > > > NASreq is intended to be the generic RADIUS "replacement" within > > Diameter. A RADIUS interaction such as VSAs is properly addressed > > there. > > > > Even as it is, NASreq Section 9 does not explicitly address all > > potential RADIUS interaction problems. We are certainly not going to > > backfill it into RFC 3588. > > > > The Diameter drafts/RFCs are purposely segmented so that they may get > > finished within our useful lifetimes. Expect more application bolt-ons, > > not less. > > > > Dave. > > > > > From owner-aaa-wg@merit.edu Mon May 3 16:22: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 QAA27194 for ; Mon, 3 May 2004 16:22:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BA3D91257; Mon, 3 May 2004 16:22:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E925E91258; Mon, 3 May 2004 16:22: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 7BD9691257 for ; Mon, 3 May 2004 16:22:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6263E58C7B; Mon, 3 May 2004 16:22:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 000AA58B2F for ; Mon, 3 May 2004 16:22:24 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i43KLrI11347; Mon, 3 May 2004 15:21:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 May 2004 15:21:54 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B597530698CEBE@zrc2c012.us.nortel.com> From: "Christopher Richards" To: Jari Arkko Cc: David Mitton , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 3 May 2004 15:21:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4314C.4517F9F2" 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_01C4314C.4517F9F2 Content-Type: text/plain Hi Jari, It's not just for translating AVPs on the fly, but also for how to re-use existing RADIUS VSA AVPs. I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to use in Diameter. I want to avoid having to completely redefine it. From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined for 3GPP. When I want to put this information into a Diameter AVP, do I set the Vendor-ID flag or not? Cheers, Chris. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Monday, May 03, 2004 2:56 PM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: David Mitton; aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hmm... good question. Let me think... Well, it seems that for this specific draft, the point is rather moot, because there's currently nothing that DCC could be translated into. When there is, then we can talk about it, but as discussed previously on this list, the translation would be in that other definition i.e. RADIUS prepaid and not in DCC. But your question is valid for other applications. Diameter EAP, for instance, points to NASREQ for the general explanation of the AVP mappings. This may be sufficient for other applications as well. --Jari Christopher Richards wrote: > Hi Jari, > > OK. But does that mean that each application must describe how to > handle > RADIUS VSA AVPs within the application? If so, DCC needs this description. > > We could simply paste in the NASREQ statements into DCC. > > Cheers, > Chris. > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Saturday, May 01, 2004 12:57 PM > To: David Mitton > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > I agree with David on this one. In general, translation between RADIUS > and Diameter is dependent on the specific application (such as NASREQ) > that we are talking about. > > --Jari > > David Mitton wrote: > > On 4/30/2004 04:26 PM -0500, Christopher Richards wrote: > > > >> Thanks Dave. > >> > >> Does the NASREQ draft apply to non-NASREQ Diameter applications? > >> >> Specifically, RFC3588 does not say that RADIUS code 26 is > prohibited. >> > >> Should your description be added to the errata of RFC3588? > >> > >> Cheers, > >> Chris. > > > > > > No. > > > > NASreq is intended to be the generic RADIUS "replacement" within > > Diameter. A RADIUS interaction such as VSAs is properly addressed > > there. > > > > Even as it is, NASreq Section 9 does not explicitly address all > > potential RADIUS interaction problems. We are certainly not going to > > backfill it into RFC 3588. > > > > The Diameter drafts/RFCs are purposely segmented so that they may get > > finished within our useful lifetimes. Expect more application bolt-ons, > > not less. > > > > Dave. > > > > > ------_=_NextPart_001_01C4314C.4517F9F2 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Jari,

It's not just for translating AVPs on the fly, but = also for how to re-use existing RADIUS VSA AVPs.

I currently have a RADIUS VSA AVP - a VSA that was = defined for RADIUS, that I now want to use in Diameter. I want to avoid = having to completely redefine it.

From my reading of RFC3588, it says something along = the lines that all AVP codes 0 to 255 are reserved for RADIUS AVPs. = From this I also took that RADIUS AVP code 26 was included.

As an example, if you have access to 3GPP TS 29.061, = take a look at the RADIUS VSAs defined for 3GPP.

When I want to put this information into a Diameter = AVP, do I set the Vendor-ID flag or not?

Cheers,
Chris.


-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
Sent: Monday, May 03, 2004 2:56 PM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: David Mitton; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Diameter encoding of RADIUS = VSA AVPs


Hmm... good question. Let me think... Well, it seems = that
for this specific draft, the point is rather = moot,
because there's currently nothing that DCC could = be
translated into. When there is, then we can talk = about
it, but as discussed previously on this list, the = translation would be in that other definition i.e. RADIUS prepaid and = not in DCC.

But your question is valid for other applications. = Diameter EAP, for instance, points to NASREQ for the general = explanation of the AVP mappings. This may be sufficient for other = applications as well.

--Jari

Christopher Richards wrote:
> Hi Jari,
>
> OK. But does that mean that each application = must describe how to
> handle
> RADIUS VSA AVPs within the application? If so, = DCC needs this description.
>
> We could simply paste in the NASREQ statements = into DCC.
>
> Cheers,
> Chris.
>
> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
> Sent: Saturday, May 01, 2004 12:57 PM
> To: David Mitton
> Cc: aaa-wg@merit.edu
> Subject: Re: [AAA-WG]: Diameter encoding of = RADIUS VSA AVPs
>
>
>
> I agree with David on this one. In general, = translation between RADIUS
> and Diameter is dependent on the specific = application (such as NASREQ)
> that we are talking about.
>
> --Jari
>
> David Mitton wrote:
>  > On 4/30/2004 04:26 PM -0500, = Christopher Richards wrote:
>  >
>  >> Thanks Dave.
>  >>
>  >> Does the NASREQ draft apply to = non-NASREQ Diameter applications? 
> >>  >> Specifically, RFC3588 = does not say that RADIUS code 26 is
> prohibited.  >>
>  >> Should your description be added = to the errata of RFC3588?
>  >>
>  >> Cheers,
>  >> Chris.
>  >
>  >
>  > No.
>  >
>  > NASreq is intended to be the generic = RADIUS "replacement" within
>  > Diameter. A RADIUS interaction such = as VSAs is properly addressed
>  > there.
>  >
>  > Even as it is, NASreq Section 9 does = not explicitly address all
>  > potential RADIUS interaction = problems.  We are certainly not going to
>  > backfill it into RFC 3588.
>  >
>  > The Diameter drafts/RFCs are = purposely segmented so that they may get
>  > finished within our useful = lifetimes.  Expect more application bolt-ons,
>  > not less.
>  >
>  > Dave.
>  >
>  >
>

------_=_NextPart_001_01C4314C.4517F9F2-- From owner-aaa-wg@merit.edu Mon May 3 16:24: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 QAA27280 for ; Mon, 3 May 2004 16:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B141B91258; Mon, 3 May 2004 16:24:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80BD491259; Mon, 3 May 2004 16:24:07 -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 504C591258 for ; Mon, 3 May 2004 16:24:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4058058CDE; Mon, 3 May 2004 16:24:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id E6EA758CB7 for ; Mon, 3 May 2004 16:24:05 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Mon, 3 May 2004 16:24:05 -0400 Message-ID: From: Mark Jones To: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Mon, 3 May 2004 16:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I have a comment on the following section (2.2) in nasreq-15: If accounting is active, every change of authentication or authorization SHOULD generate an accounting message. If the NAS service is a continuation of the prior user context, then an Accounting-Record-Type of INTERIM_RECORD indicating the new session attributes and cumulative status would be appropriate. If a new user or a significant change in authorization is detected by the NAS, then the service may consider it appropriate to send two messages of the types STOP_RECORD, and START_RECORD. In the re-authorization case, I am not comfortable with letting the NAS implementor deciding what constitutes a "significant change". The re-authorization request is used to trigger events of significant billing interest so predictable behavior across vendors is critical. I think interoperability would be better served by a more explicit requirement on the NAS. Two possible solutions come to mind: EITHER (1) If the re-authorization results in a change to any of the service parameters, the NAS MUST treat this as a new session and send two messages (Stop/Start). OR (2) The AAA server MUST specify whether the Stop/Start is required at the time it requests the re-authorization. If the AAA server does not request a Stop/Start at re-authorization, the NAS MUST NOT send any accounting messages for this event. I have a preference for (2) since it eliminates redundant accounting messages in those cases where the service provider is not dependent on the Stop/Start messages to bill for the service change triggered by re-authorization. Regards Mark From owner-aaa-wg@merit.edu Mon May 3 23:57:15 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 XAA22002 for ; Mon, 3 May 2004 23:57:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 646B491262; Mon, 3 May 2004 23:56:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2FA5091271; Mon, 3 May 2004 23: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 AF42C91262 for ; Mon, 3 May 2004 23:56:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E22358CA9; Mon, 3 May 2004 23:56:12 -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 B7AB158D0D for ; Mon, 3 May 2004 23:56:11 -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 i443twk09597; Tue, 4 May 2004 06:55:58 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 06:55:34 +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 i443tY6P008624; Tue, 4 May 2004 06:55:34 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00ABllvS; Tue, 04 May 2004 06:55:32 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 i443tVH06526; Tue, 4 May 2004 06:55:31 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 06:55:30 +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: RE : [AAA-WG]: Questions on RFC 3588 Date: Tue, 4 May 2004 06:55:27 +0300 Message-ID: Thread-Topic: [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDg From: To: , X-OriginalArrivalTime: 04 May 2004 03:55:30.0305 (UTC) FILETIME=[A47C6F10:01C4318B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Ulrich, > Thank you for your response. I'm not sure whether I correctly > understand your answer. Can you please confirm that > > a) A new mandatory AVP (i.e. an AVP which is not surrounded > by square brackets in the command's ABNF definition) is a > requirement for a new application ID. Yes, a new mandatory AVP is one requirement for a new Applicaiton=20 ID. > b) A new optional AVP (i.e. an AVP surrounded by square > brackets in the command's ABNF definition) may be added > without requiring a new application ID. If the optional AVP's > M-bit is set the behavior described in RFC 3588 section 4.1 > applies i.e. the sending (Rel-6) node shall be prepared to > receive error 5001 and may then decide to re-send the command > in a Rel-5 compliant form. If the optional AVP's M-bit is > cleared the reciving(Rel-5) node will silently discard the AVP. Basically, yes. You've defined a 3GPP Cx applicaiton. If new AVPs are added to this application, they need to be optional. If you want to add mandatory new AVPs, you most likely need a new Application ID. It seems that you really want some sort of improved negotiation capabilities in your application. This could be added to the application, so that it could support negotiating the of 3GPP release versions inside of the application. This is something that would be rather tricky - negotiation capabilities can be complex. There was some discussion of having additional negotiation capabilities in the AAA a few years ago, but the WG decided not to persue it. best regards, John From owner-aaa-wg@merit.edu Tue May 4 00:45:58 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 AAA23949 for ; Tue, 4 May 2004 00:45:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F65791261; Tue, 4 May 2004 00:45:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2D9C91263; Tue, 4 May 2004 00:45: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 8647A91261 for ; Tue, 4 May 2004 00:45:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 726C558367; Tue, 4 May 2004 00:45:46 -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 68B2A58B9D for ; Tue, 4 May 2004 00:45:45 -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 i444jak15344; Tue, 4 May 2004 07:45:36 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 07:45:06 +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 i444j6il009721; Tue, 4 May 2004 07:45:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 007GCPxX; Tue, 04 May 2004 07:45:05 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 i444j5H18195; Tue, 4 May 2004 07:45:05 +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); Tue, 4 May 2004 07:45:05 +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: RE : [AAA-WG]: Questions on RFC 3588 Date: Tue, 4 May 2004 07:45:03 +0300 Message-ID: Thread-Topic: [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAgWnQw From: To: , , X-OriginalArrivalTime: 04 May 2004 04:45:05.0282 (UTC) FILETIME=[91B5E620:01C43192] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Lionel, > I think that the problem comes from the text identifying the=20 > rules for the creation of new applications (section 1.2.3 in=20 > RFC 3588): >=20 > " [...]Should a new Diameter usage scenario find itself=20 > unable to fit within an existing application without=20 > requiring major changes to the specification, it may be=20 > desirable to create a new Diameter application. Major=20 > changes to an application include: >=20 > - Adding new AVPs to the command, which have the "M" bit set. [...] >=20 > [...]In order to justify allocation of a new application=20 > identifier, Diameter applications MUST define one Command=20 > Code, or add new mandatory AVPs to the ABNF." >=20 > From my understanding, a mandatory AVP is used in the RFC=20 > 3588 for an AVP that must be supported by the application i.e=20 > AVP with the M-bit set, regardless of whether it is required=20 > or optional within the ABNF description of the command which=20 > the AVP is included in. >=20 > Therefore, the rule "adding new AVPs to the command, which=20 > have the bit "M" bit set" is not clear: does this apply for=20 > addition of a new "required" AVP in the ABNF descritpion of=20 > the command, creation of a new AVP that must be supported by=20 > the application, or for both? Basically, if a mandatory AVP is not supported, then it cannot be said that the application is fully supporting the specification. Mandatory means that it MUST be supported. New AVPs with the M bit set cannot be added to an existing application. John From owner-aaa-wg@merit.edu Tue May 4 02:29:37 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 CAA11500 for ; Tue, 4 May 2004 02:29:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E3AF291265; Tue, 4 May 2004 02:29:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AB1C291266; Tue, 4 May 2004 02:29: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 9F3AA91265 for ; Tue, 4 May 2004 02:29:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 851EF58E13; Tue, 4 May 2004 02:29:23 -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 C421058E10 for ; Tue, 4 May 2004 02:29:22 -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 i446TEk08240; Tue, 4 May 2004 09:29:14 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 09:28:46 +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 i446SkKe018098; Tue, 4 May 2004 09:28:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 0063G3Bi; Tue, 04 May 2004 09:28:44 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 i446ShH01495; Tue, 4 May 2004 09:28:43 +0300 (EET DST) Received: from nokia.com ([172.21.23.23]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 09:28:40 +0300 Message-ID: <40973818.8090006@nokia.com> Date: Tue, 04 May 2004 09:28:40 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu, maria.carmen.belinchon@ericsson.com, miguel-angel.pallares@ericsson.com, carolina.canales@ericsson.com, mccap@lucent.com, jaakko.rajaniemi@nokia.com, kalle.tammi@nokia.com Subject: Re: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-sip-a pp-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2004 06:28:40.0521 (UTC) FILETIME=[0A481B90:01C431A1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Wolfgang: I am afraid we cannot remove the support for the scenario described in section 5.3. Among other things, the lack of qop is widely used today, no matter what RFC 2617 indicates that it should be used. For instance, 3GPP is using HTTP Digest AKA that does not require qop. So it is not the support of an old RFC, but the support of current networks deployments. - Miguel ext Beck01, Wolfgang wrote: > Miguel, > > > >>However, if there is not qop parameter used, then the Diameter server >>can pre-calculate an expected response, since it is not dependent on any >>client information, and send it to the SIP server. The SIP server >>challenges the SIP client, receives the credentials (request-digest), >>compares the response with the expected response, and authorizes the SIP >>request. > > From RfC 2617, section 3.2.1 about optionality of the qop directive: > "This directive is optional, but is made so only for backward > compatibility with RFC 2069 [6]; it SHOULD be used by all > implementations compliant with this version of the Digest scheme." > Is support for an obsolete RfC worth the effort? When I read section > 5.3 of your draft, I expected the SIP server to have a local > user/passwd/profile database and was a bit confused about steps 5 and 6. > But without centralized user/passwd/profile storage, the DIAMETER server > becomes in fact a SIP redirecting proxy. Can't we just drop 5.3 completely? > > > Wolfgang > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue May 4 02:51: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 CAA12520 for ; Tue, 4 May 2004 02:51:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 808E091268; Tue, 4 May 2004 02:51:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C0BB9126A; Tue, 4 May 2004 02:51: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 A21DC91268 for ; Tue, 4 May 2004 02:51:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8376F58B7C; Tue, 4 May 2004 02:51:40 -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 A98A858C11 for ; Tue, 4 May 2004 02:51:36 -0400 (EDT) Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i446pZWR020131 for ; Tue, 4 May 2004 08:51:35 +0200 (MEST) 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, 4 May 2004 08:51:35 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 4 May 2004 08:51:42 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Joe Harvell'" Cc: aaa-wg@merit.edu, "'marco.stura@nokia.com'" Subject: RE: [AAA-WG]: interaction of DCC failover procedures with AAATran s transport failure detection failover action Date: Tue, 4 May 2004 08:51:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 04 May 2004 06:51:35.0338 (UTC) FILETIME=[3DBC88A0:01C431A4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Joe, sorry for the late response. I've been away from my mail for a while and try now to catch up with the backlog. Your logic in the pseudocode looks ok. In brief, the timer Tx is valid only in case the CCFH has been set to TERMINATE in order to give the service provider the possiblity to _quickly_ tear down the service if we suspect that there are problems with the DCC session and the server might not be able to debit the user's account for the services used (as you have correctly included in your pseudocode). For other CCFH values we rely on the timers and mechanisms on the transport layer (and of course the error codes in the answer messages), and first try to move the session to an alternative server, if possible, and after that take appropriate action based on the CCFH value, if even the communication with the alternative server fails. I also had a look at Marco's answer (thanks, Marco), and don't have anything to add there. I couldn't have answered better. BR, Leena -----Original Message----- From: Joe Harvell [mailto:harvell@nortelnetworks.com] Sent: 24. huhtikuuta 2004 19:49 To: Leena Mattila (TU/LMF) Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: interaction of DCC failover procedures with AAATrans transport failure detection failover action Leena: Thanks for your response. I need some more clarification on Section 5.7 in draft 4. I have included my questions inline below. Could you please provide answers? Also, I have tried to piece together some pseudocode describing how this works based on my current understanding. Could you please look over this and verify my understanding is correct? First, here is an excerpt from Section 5.7 along with my inline questions. > If the Credit-Control-Failure-Handling AVP is set to the value > CONTINUE or RETRY_AND_TERMINATE, the service will be granted to the > end user upon the timer Tx expires. An answer message with granted- > units may arrive later on due to the base protocol transport failover > occurred in the path to the Credit Control Server (Twinit default > value is 3 times more than the Tx recommended value). The credit > control client SHOULD grant the service to the end user, start > monitoring the resource usage and wait for the possible late answer > until the timeout of the request (e.g. 120 seconds). [JH]: So what timer detects the "timeout of the request"? Is this an implementation defined timer not mentioned elsewhere in the spec along with a recommended value? Is the "timeout of the request" you mention here a transport failure detection of the transport connection on which the request is pending? I am assuming that this is not Tx since Tx already expired. If this is the case, why don't the state machines in section 7 reference any event associated with this timer expiring. Please explain. > If the request > fails and the CC-Session-Failover AVP is set to FAILOVER_NOT > SUPPORTED, the credit control client terminates or continues the > service depending on the value set in the CCFH and MUST free all the > reserved resources for the credit control session. [JH]: The action to be taken matches with the behavior for "Failed CC initial answer received" event in the state machine in Section 7. In this context, "Failed answer" refers to an answer received with Permanent Error type result code. Is that what you mean here by "the request fails"? Or are you actually describing what action is taken when "the possible late answer" described above does not arrive before "the timeout of the request" as mentioned above? If a protocol error > DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY is received or the > request timeout and the CC-Session-Failover AVP is set to FAILOVER > SUPPORTED, the credit control client MAY send the request to a backup > server if possible. [JH]: You already indicated in your previous email that "the request timeout" described directly above refers to a transport failure detection for the connection on which the request is pending. If the credit control client receives a successful > answer from the backup server, it continues the credit control session > with such a server. If also the re-transmitted request fails, the > credit control client terminates or continues the service depending on > the value set in the CCFH and MUST free all the reserved resources for > the credit control session. [JH]: I assume the meaning of "also the re-transmitted request fails" is the same as the meaning of "If the request fails" that I asked about above? If not, please explain this, too. Now, here is my pseudocode describing failure procedures as I understand them now: Here are the events that can happen to a pending request: * Failure to Send to Selected Peer---The selected peer is unavailable as determined by Diameter Base Transport Failure Mechanism * Failure to Send---Neither selected peer nor alternate peer is available. * Temporary Error---Client receives one of the following Protocol Error notifications o DIAMETER_TOO_BUSY o DIAMETER_UNABLE_TO_DELIVER + Note: Above notification is generated locally when a peer fails for each request pending with destination host equal to that peer o DIAMETER_LOOP_DETECTED * Permanent Failure o DIAMETER_RATING_FAILED o DIAMETER_AVP_UNSUPPORTED o DIAMETER_UNKNOWN_SESSION_ID o DIAMETER_AUTHORIZATION_REJECTED o DIAMETER_INVALID_AVP_VALUE o DIAMETER_MISSING_AVP o DIAMETER_RESOURCES_EXHAUSTED + Note: Above error is not expected to be used by a DCC application. o DIAMETER_CONTRADICTING_AVPS o DIAMETER_AVP_NOT_ALLOWED o DIAMETER_AVP_OCCURS_TOO_MANY_TIMES o DIAMETER_NO_COMMON_APPLICATION o DIAMETER_UNSUPPORTED_VERSION o DIAMETER_UNABLE_TO_COMPLY o DIAMETER_INVALID_BIT_IN_HEADER o DIAMETER_INVALID_AVP_LENGTH o DIAMETER_INVALID_MESSAGE_LENGTH o DIAMETER_INVALID_AVP_BIT_COMBO o DIAMETER_NO_COMMON_SECURITY * Tx expiry * Transport Failure Detected Failure to Send to Selected Peer or Temporary Error: if(!retransmitted && (CCR(I) || CC-Session-Failover==SUPPORTED) && alternate peer available) { send to alternate peer } else { raise Failure to Send (see below) } Failure to Send or Permanent Failure: if(CCFH==CONTINUE) { Grant Prepaid request and never talk to the Prepaid Server again. (This implies no prepaid resource limits from now on). } else { Terminate GTP context. } Tx Expiry: if(CCFH==TERMINATE) { Terminate GTP context } else { Grant prepaid request } Transport Failure Detected (logic executed for each pending request): if(dstHost in message == failed host) { raise Temporary Error (DIAMETER_UNABLE_TO_DELIVER) (follow logic described above for Temporary Error) } else { if(CCR(I) || CC-Session-Failover==SUPPORTED) { if(!retransmitted AND alternate peer available) { send to alternate peer } else { raise Failure To Send } } else { raise Failure To Send } } Leena Mattila (TU/LMF) wrote: > Hi Joe, > > see answers inline. > > BR, > Leena > > >>From: owner-aaa-wg@merit.edu >>[mailto:owner-aaa-wg@merit.edu]On Behalf Of >>Joe Harvell >>Sent: 14. tammikuuta 2004 2:42 >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: interaction of DCC failover procedures >>with AAATrans >>transport failure detection failover action >> >> >>Section 5.6 describes failover procedures for session based >>credit control. According to these procedures, the DCC >>client may retransmit the CCR to a backup server: >> >> If a protocol error DIAMETER_UNABLE_TO_DELIVER or >>DIAMETER_TOO_BUSY >> is received or the request timeout and the >>CC-Session-Failover AVP >> is set to FAILOVER SUPPORTED, the credit control client >>MAY send the >> request to a backup server if possible. >> >>However, according to section 5.5.3 of the Diameter Base >>Protocol requires the transport failure algorithm in AAATrans >>to be supported. This algorithm describes retransmitting >>pending requests to a backup server upon transport failure detection. >> >>Clearly the DCC client should not retransmit pending requests >>for sessions in which failover is not supported >>(CC-Session-Failover AVP indicates failover is not >>supported). But for pending requests for sessions in which >>failover is supported, should the Diameter client retransmit >>the request upon transport failure detection in addition to >>request timeout? > > The "request timeout" in the referred text means actually transport > failure. We thought that the DCC application will see the transport > layer failure as a Twinit timer expiry. It's the timer Twinit in > AAATrans that is meant here, not the timer Tx in the DCC. Maybe it's > only the wording that should be clarified here. So, Yes, the Diameter > client should re-transmit the request to a backup server upon transport > failure detection. > >>Also, I would like clarification on interaction of transport >>failure initiated failover (AAATrans) and Diameter Credit >>Control's session based failover procedures for pending CCRs >>of CC-Request-Type First Interrogation. My understanding is >>that CCRs of the first interrogation would include the >>Destination-Realm AVP but not the destination host AVP (as >>suggested by section 6.1 of Diameter Base Protocol). > > Yes, this is correct. But I think it is also possible to address > a certain host directly already in the First Interrogation, given > that the Diameter client has the address of the server available, > e.g. preconfigured in the node or received from the AA(A) server. > > >>Furthermore CCRs of type other than First Interrogation would >>contain both Destination-Realm and Destination-Host AVPs. >>This means that when transport failure is detected by the >>Credit Control Client, all pending CCRs of type First >>Interrogation would be immediately sent to an available >>backup server regardless of any CC-Session-Failover >>configuration. > > Yes, in case of First Interrogation it does not really matter > whether the server or client supports failover since no session > state has been established yet in the server. It's the state > transfer between the primary and the secondary server that is > considered to be (on of) the tricky part(s) and why some servers > might not support failover. > > >>The other pending CCRs would not be >>forwardable to a backup server according to section 5.5.5 of >>Diameter Base Protocol, since the Destination-Host AVP must >>have identified the failed host. However, these pending requests >>would actually be retransmitted if session failover is >>supported according to the rules in Section 5.6 of Diameter >>Credit Control Application. My reasoning is that the pending >>Diameter request is internally failed with >>DIAMETER_UNABLE_TO_DELIVER according to Diameter Base >>Protocol 5.5.4, which triggers the session failover described >>in section 5.6 of Diameter Credit Control Application. >> >>Is this an accurate description of the Diameter Credit >>Control client behavior upon transport failure detection? Is >>my reasoning correct? > > Yes, your understanding is correct. > > >>--- >>Joe Harvell >>Shasta GGSN Development >>Nortel Networks >>+1 972.685.4886 >> From owner-aaa-wg@merit.edu Tue May 4 03:00:26 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 DAA12982 for ; Tue, 4 May 2004 03:00:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE8049126A; Tue, 4 May 2004 03:00:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59E799126B; Tue, 4 May 2004 03:00:07 -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 8D4D09126A for ; Tue, 4 May 2004 03:00:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7837B58D34; Tue, 4 May 2004 03:00:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 3CB8B58D19 for ; Tue, 4 May 2004 03:00:01 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i4464HkM024613 for ; Tue, 4 May 2004 08:04:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RE : [AAA-WG]: Questions on RFC 3588 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 08:59:54 +0200 Message-ID: <64F95EC22E92334EA21188664F36A4820241C4@gkshfd03.gksag.net> Thread-Topic: RE : [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LA= From: "Wiehe Ulrich" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, Thank you for this clarification. I do not want to introduce new or improve existing negotiation = capabilities. I just want to understand and possibly make use of the existing = mechanism defined in RFC 3588 chapter 4.1. My understanding of the existing = mechanism is: a) you may add AVPs arbitrarily (see 3588 chapter 1.1). b1) If the added AVPs M-bit is set, the not supporting receiver shall = return error 5001 (see 3588 chapter 7.1.5). When receiving error 5001, the = sender shall re-send the command without the new AVP (see 3588 section 4.1). b2) If the added AVPs M-bit is not set, the not supporting receiver may discard the new AVP (see 3588 section 4.1). From your answers I understand that you do not share my view. Can you = please point me to text in RFC 3588 indicating that my understanding of the = existing mechanism is not correct, or indicating that this mechanism must not be = used. Best regards Ulrich =20 -----Urspr=FCngliche Nachricht----- Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Dienstag, 4. Mai 2004 05:55 An: Wiehe Ulrich; aaa-wg@merit.edu Betreff: RE: RE : [AAA-WG]: Questions on RFC 3588 Hi Ulrich, > Thank you for your response. I'm not sure whether I correctly > understand your answer. Can you please confirm that > > a) A new mandatory AVP (i.e. an AVP which is not surrounded > by square brackets in the command's ABNF definition) is a > requirement for a new application ID. Yes, a new mandatory AVP is one requirement for a new Applicaiton=20 ID. > b) A new optional AVP (i.e. an AVP surrounded by square > brackets in the command's ABNF definition) may be added > without requiring a new application ID. If the optional AVP's > M-bit is set the behavior described in RFC 3588 section 4.1 > applies i.e. the sending (Rel-6) node shall be prepared to > receive error 5001 and may then decide to re-send the command > in a Rel-5 compliant form. If the optional AVP's M-bit is > cleared the reciving(Rel-5) node will silently discard the AVP. Basically, yes. You've defined a 3GPP Cx applicaiton. If new AVPs are added to this application, they need to be optional. If you want to add mandatory new AVPs, you most likely need a new Application ID. It seems that you really want some sort of improved negotiation capabilities in your application. This could be added to the application, so that it could support negotiating the of 3GPP release versions inside of the application. This is something that would be rather tricky - negotiation capabilities can be complex. There was some discussion of having additional negotiation capabilities in the AAA a few years ago, but the WG decided not to persue it. best regards, John From owner-aaa-wg@merit.edu Tue May 4 03:07: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 DAA13360 for ; Tue, 4 May 2004 03:07:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77DEF9126E; Tue, 4 May 2004 03:07:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5ABA99126F; Tue, 4 May 2004 03:07: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 500AD9126B for ; Tue, 4 May 2004 03:06:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 285CA58CB7; Tue, 4 May 2004 03:06:56 -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 382FD58AFD for ; Tue, 4 May 2004 03:06:55 -0400 (EDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 4 May 2004 09:06:50 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 09:06:49 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu Subject: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-s ip-a pp-02 Date: Tue, 4 May 2004 09:06:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, > I am afraid we cannot remove the support for the scenario described in > section 5.3. Among other things, the lack of qop is widely used today, > no matter what RFC 2617 indicates that it should be used. For instance, > 3GPP is using HTTP Digest AKA that does not require qop. So it is not > the support of an old RFC, but the support of current networks deployments. I see. There is one more case were only one MAR/MAA round-trip is required: SIP server 2 selects nonce, opaque etc by itself and challenges the SIP UA. When the SIP UA re-sends its request, SIP server 2 puts the Authorization header contents into a MAR and sends ist to the DIAMETER server. Wolfgang From owner-aaa-wg@merit.edu Tue May 4 03:08: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 DAA13433 for ; Tue, 4 May 2004 03:08:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AB5F91270; Tue, 4 May 2004 03:07:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CB699126B; Tue, 4 May 2004 03:07:03 -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 04D1B9126E for ; Tue, 4 May 2004 03:06:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3E8E58CB7; Tue, 4 May 2004 03:06:59 -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 0656158CBA for ; Tue, 4 May 2004 03:06:59 -0400 (EDT) Received: from g9jbq.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP; Tue, 4 May 2004 09:06:55 +0200 Received: by G9JBQ.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 09:06:54 +0200 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aaa-wg@merit.edu Subject: AW: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diamet er-s ip-app-02 Date: Tue, 4 May 2004 09:06:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Miguel, > Perhaps the stopping point is that the SIP Method and the Request-URI > are needed to compute what HTTP Digest calls "A2" (see Section 3.2.2.3 > in RFC 2617). A2 is neeeded to compute request-digest (i.e., the > response the client sends). So if authentication is done at the Diameter > server, then it needs to get the SIP method and the Request-URI, even > when those parameters are not used for authorization purposes. The are two MAR/MAA exchanges. In the first exchange, SIP Method and Request-URI are not required. The DIAMETER server just chooses some random values (nonce, opaque) and does not decide whether to allow or deny the request. Sending SIP Method and Request-URI here seems to be a waste of bandwidth. In the second exchange, SIP Method and Request-URI are indeed mandatory. So, I would make SIP Method and Request-URI a MUST only in the case where the DIAMETER server makes a authentication decision. Wolfgang From owner-aaa-wg@merit.edu Tue May 4 03:17:37 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 DAA13716 for ; Tue, 4 May 2004 03:17:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BEAF59126B; Tue, 4 May 2004 03:17:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A23C9126F; Tue, 4 May 2004 03:17: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 700A39126B for ; Tue, 4 May 2004 03:17:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5100B58B7C; Tue, 4 May 2004 03:17:23 -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 51B3E58A51 for ; Tue, 4 May 2004 03:17:22 -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 i447HKk25983; Tue, 4 May 2004 10:17:20 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:16:34 +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 i447GYgG005274; Tue, 4 May 2004 10:16:34 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00xq44u9; Tue, 04 May 2004 10:16:33 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 i447GXH15538; Tue, 4 May 2004 10:16:33 +0300 (EET DST) Received: from nokia.com ([172.21.23.23]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 10:16:19 +0300 Message-ID: <40974342.3050006@nokia.com> Date: Tue, 04 May 2004 10:16:18 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: Re: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diameter-ip-a pp-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2004 07:16:19.0016 (UTC) FILETIME=[B213D480:01C431A7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ext Beck01, Wolfgang wrote: > Miguel, > > >>I am afraid we cannot remove the support for the scenario described in >>section 5.3. Among other things, the lack of qop is widely used today, >>no matter what RFC 2617 indicates that it should be used. For instance, >>3GPP is using HTTP Digest AKA that does not require qop. So it is not >>the support of an old RFC, but the support of current networks deployments. > > I see. There is one more case were only one MAR/MAA round-trip is required: > SIP server 2 selects nonce, opaque etc by itself and challenges the SIP UA. > When the SIP UA re-sends its request, SIP server 2 puts the Authorization > header contents into a MAR and sends ist to the DIAMETER server. > Yes, of course, such scenario exist. It is the case when the SIP client sends an unsolicited Digest credentials. So it is a subset of the scenario described in section 5.2, where we have messages 9 to 16. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue May 4 03:29:01 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 DAA13936 for ; Tue, 4 May 2004 03:29:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2BDB891271; Tue, 4 May 2004 03:28:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED75691272; Tue, 4 May 2004 03:28: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 ACD6B91271 for ; Tue, 4 May 2004 03:28:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90C9758E0E; Tue, 4 May 2004 03:28:46 -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 C532658DEF for ; Tue, 4 May 2004 03:28:45 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i447SXv11301; Tue, 4 May 2004 10:28:33 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:27:38 +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 i447Rc3X017594; Tue, 4 May 2004 10:27:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00asuoFx; Tue, 04 May 2004 10:27:37 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 i447RaH13754; Tue, 4 May 2004 10:27:36 +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, 4 May 2004 10:27: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: RE: RE : [AAA-WG]: Questions on RFC 3588 Date: Tue, 4 May 2004 10:27:35 +0300 Message-ID: Thread-Topic: RE : [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAVbpIA== From: To: , X-OriginalArrivalTime: 04 May 2004 07:27:35.0846 (UTC) FILETIME=[457FE460:01C431A9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Ulrich, Starting in with: 1) 5.3. Capabilities Exchange When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. -> CEA/CER is used to advertise supported Diameter applications, so that unrecognized commands and/or AVPs are not sent to a peer. 2.1) Section 1.2.3. Creating New Authentication Applications Every Diameter application specification MUST have an IANA assigned Application Identifier (see Section 2.4) or a vendor specific Application Identifier. 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. -> I interpret this to mean that adding a new mandatory AVP to=20 a command is considered a major change, requiring a new application. 2.2) Section 1.2.4. Creating New Accounting Applications ... When two Diameter peers establish a transport connection, they MUST exchange the Capabilities Exchange messages, as specified in the peer state machine (see Section 5.6). This message allows the discovery of a peer's identity and its capabilities (protocol version number, supported Diameter applications, security mechanisms, etc.) The receiver only issues commands to its peers that have advertised support for the Diameter application that defines the command. A Diameter node MUST cache the supported applications in order to ensure that unrecognized commands and/or AVPs are not unnecessarily sent to a peer. -> I interpret this to mean, for example, applications can add new AVPs to an accounting application, as long as the M bit is not set. 3) Section 4.1. AVP Header .... The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter protocol nor in any of the Diameter Application specifications governing the message in which it appears. It MAY do this in one of the following ways: 1) If a message is rejected because it contains a Mandatory AVP which is neither defined in the base Diameter standard nor in any of the Diameter Application specifications governing the message in which it appears, the implementation may resend the message without the AVP, possibly inserting additional standard AVPs instead. 2) A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problems. -> Interpret this to mean that if an instance of an application receives a command with an AVP that has the M bit set, but is not defined with that application, it can reject the message. However, there is no = mandatory behavior. An conformant application could silently discard the = message as well. There is no discussion about falling back to another = version of the application, etc. > I do not want to introduce new or improve existing negotiation = capabilities. > I just want to understand and possibly make use of the existing = mechanism > defined in RFC 3588 chapter 4.1. My understanding of the existing = mechanism > is: > > a) you may add AVPs arbitrarily (see 3588 chapter 1.1). > b1) If the added AVPs M-bit is set, the not supporting receiver shall = return > error 5001 (see 3588 chapter 7.1.5). When receiving error 5001, the = sender > shall re-send the command without the new AVP (see 3588 section 4.1). > b2) If the added AVPs M-bit is not set, the not supporting receiver = may > discard the new AVP (see 3588 section 4.1). >=20 > From your answers I understand that you do not share my view. Can you = please > point me to text in RFC 3588 indicating that my understanding of the = existing > mechanism is not correct, or indicating that this mechanism must not = be used. I will follow-up in another mail, about this in a more general way. John From owner-aaa-wg@merit.edu Tue May 4 03:35: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 DAA14177 for ; Tue, 4 May 2004 03:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9CEA91272; Tue, 4 May 2004 03:35:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8125191273; Tue, 4 May 2004 03:35:00 -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 48A4491272 for ; Tue, 4 May 2004 03:34:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 355C058D79; Tue, 4 May 2004 03:34:59 -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 49A9B58D0D for ; Tue, 4 May 2004 03:34:58 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i447YvH15833; Tue, 4 May 2004 10:34:57 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:33:55 +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 i447Xt2F031665; Tue, 4 May 2004 10:33:55 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gjjUTi; Tue, 04 May 2004 10:33: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 i447XrH18488; Tue, 4 May 2004 10:33:53 +0300 (EET DST) Received: from nokia.com ([172.21.23.23]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 10:33:51 +0300 Message-ID: <4097475E.2000300@nokia.com> Date: Tue, 04 May 2004 10:33:50 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: "ext Beck01, Wolfgang" Cc: aaa-wg@merit.edu Subject: Re: AW: AW: AW: [AAA-WG]: questions/comments on draft-ietf-aaa-diamet er-s ip-app-02 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2004 07:33:51.0237 (UTC) FILETIME=[25400350:01C431AA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ext Beck01, Wolfgang wrote: > Miguel, > > >>Perhaps the stopping point is that the SIP Method and the Request-URI >>are needed to compute what HTTP Digest calls "A2" (see Section 3.2.2.3 >>in RFC 2617). A2 is neeeded to compute request-digest (i.e., the >>response the client sends). So if authentication is done at the Diameter >>server, then it needs to get the SIP method and the Request-URI, even >>when those parameters are not used for authorization purposes. > > The are two MAR/MAA exchanges. In the first exchange, SIP Method and > Request-URI are not required. The DIAMETER server just chooses some > random values (nonce, opaque) and does not decide whether to allow or > deny the request. Sending SIP Method and Request-URI here seems to be > a waste of bandwidth. > > In the second exchange, SIP Method and Request-URI are indeed mandatory. > So, I would make SIP Method and Request-URI a MUST only in the case > where the DIAMETER server makes a authentication decision. > > > Wolfgang > I agree with the fact that the SIP method and the SIP AOR are not needed in the first MAR/MAA exchange for the purpose of generating the challenge. However, it may be needed for the purpose of authorization. As I said before, a network may implement a policy of not authorizing certain SIP requests destined to certain networks. So the Diameter server will not even come into the authentication procedure, because authorization was denied. In that case I found valuable the SIP server providing the SIP method and SIP AOR to the Diameter server. On the other hand, I also find easier to implement a command that always insert an AVP, rather than taking the decision when to send the AVP, when not. Then we need to provide further procedures at the Diameter server to verify that those AVPs are present when they need to present. I don't agree with you with the bandwidth argument. I think the SIP method and the Request-URI can be encoded typically in 30 bytes (I am exagerating). My suggestion is to leave these AVPs as mandatory as they currently are. - Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue May 4 03:37: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 DAA14444 for ; Tue, 4 May 2004 03:37:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF3C591277; Tue, 4 May 2004 03:37:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54F6F91275; Tue, 4 May 2004 03:37: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 6F83191273 for ; Tue, 4 May 2004 03:37:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5675B58D93; Tue, 4 May 2004 03:37:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 30CDC58D8E for ; Tue, 4 May 2004 03:37:37 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i446frkM024861 for ; Tue, 4 May 2004 08:41:53 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: RE : [AAA-WG]: Questions on RFC 3588 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 09:37:30 +0200 Message-ID: <64F95EC22E92334EA21188664F36A4820241C5@gkshfd03.gksag.net> Thread-Topic: RE : [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAlnpDw From: "Wiehe Ulrich" To: "MORAND Lionel FTRD/DAC/ISS" , , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Dear Lionel, My understanding of the text you are quoting is: a) adding a new AVP with M-bit set is a major change. b) for major changes it *may be desirable* to create a new application = (but it is not an absolute must). c) if you want to create a new application, you must define a new = Command or add a new mandatory AVP to the ABNF. The text does not say: if you want = to add a new command or a new mandatory AVP, you must create a new = application. Best regards Ulrich -----Urspr=FCngliche Nachricht----- Von: MORAND Lionel FTRD/DAC/ISS [mailto:lionel.morand@francetelecom.com] = Gesendet: Montag, 3. Mai 2004 17:18 An: Wiehe Ulrich; john.loughney@nokia.com; aaa-wg@merit.edu Betreff: RE : [AAA-WG]: Questions on RFC 3588 Hi, I think that the problem comes from the text identifying the rules for = the creation of new applications (section 1.2.3 in RFC 3588): " [...]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. [...] [...]In order to justify allocation of a new application identifier, = Diameter applications MUST define one Command Code, or add new mandatory AVPs to = the ABNF." From my understanding, a mandatory AVP is used in the RFC 3588 for an = AVP that must be supported by the application i.e AVP with the M-bit set, regardless of whether it is required or optional within the ABNF = description of the command which the AVP is included in. Therefore, the rule "adding new AVPs to the command, which have the bit = "M" bit set" is not clear: does this apply for addition of a new "required" = AVP in the ABNF descritpion of the command, creation of a new AVP that must = be supported by the application, or for both? BR, Lionel > -----Message d'origine----- > De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] > De la part de Wiehe Ulrich > Envoy=E9 : lundi 3 mai 2004 11:03 > =C0 : john.loughney@nokia.com; aaa-wg@merit.edu > Objet : AW: [AAA-WG]: Questions on RFC 3588 > > > Hello John, > > Thank you for your response. I'm not sure whether I correctly > understand your answer. Can you please confirm that > > a) A new mandatory AVP (i.e. an AVP which is not surrounded > by square brackets in the command's ABNF definition) is a > requirement for a new application ID. > > b) A new optional AVP (i.e. an AVP surrounded by square > brackets in the command's ABNF definition) may be added > without requiring a new application ID. If the optional AVP's > M-bit is set the behavior described in RFC 3588 section 4.1 > applies i.e. the sending (Rel-6) node shall be prepared to > receive error 5001 and may then decide to re-send the command > in a Rel-5 compliant form. If the optional AVP's M-bit is > cleared the reciving(Rel-5) node will silently discard the AVP. > > Thank you again > Ulrich > > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Gesendet: Montag, 3. Mai 2004 09:04 > An: Wiehe Ulrich; aaa-wg@merit.edu > Betreff: RE: [AAA-WG]: Questions on RFC 3588 > > Hello Ulrich, > > > 3GPP have defined a vendor-specific Diameter-Application (3GPP Cx > > Rel-5) > for which IANA has > > allocated an application-Id (167772151). Now 3GPP are in > the process > > of > defining a new version > > of this application (3GPP Cx Rel-6). The new version is an > extension > > of the > old version,i.e. > > nodes supporting the new version do also support the old > version. The > > new > version does not > > replace the old version, i.e. interworking between nodes supporting > > only > the old version and > > nodes supporting the old and the new version is required. > > > > Let us assume that the difference between the old version > and the new > version is that a new AVP > > is added to a command and this AVP has the M-bit set. > > A new mandatory AVP is a requirement for a new application ID. > > > The first question is: Is it necessary to get a new application-Id > allocated by IANA for the > > new version, or is it possible for both versions to share the same > > (already > allocated) > > application-Id, and to achieve interoperability between the two > > versions by > means of the mechanism > > defined in RFC 3588 section 4.1 (description of the 'M' > bit), i.e. the > > node > sending the new > > mandatory AVP must be prepared to receive error code 5001 > (unsupported > > AVP) > and re-send the command > > in a Rel-5 compliant form? > > If you wanted the above behavior, the new AVP defined by 3GPP > should not be mandatory, but it should be optional, then the > above behavior would be compliant to 3588. > > > Here are some quotes from RFC 3588 which you might want to consider > > when > answering the question: > > > -In section 1.1: "AVPs may be added arbitrarily to Diameter > messages, > > so > long as the required AVPs > > are included and AVPs that are explicitly excluded are not > included." > > -In section 1.2.3:" 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." > > -In section 1.2.3:"Creation of a new application should be > viewed as a > > last > resort."=20 > > Defining new applications are a last resort, of course. A > real reason for having a new application would be because you > are adding new functionality to Diameter that cannot be met > with existing applicaitions. Adding a new AVPs would not > really qualify, in my opinion, unless they drastically > changed the behavior. > > > The second question is similar: If the difference between the old > > version > and the new version > > is that an existing mandatory AVP is removed from a command > is it then > necessary to get a > > new application-Id allocated, or can interoperability be > achieved in > > the > way that the node > > omitting the mandatory AVP must be prepared to receive error 5005 > > (missing > AVP) and re-send the > > command in a Rel-5 compliant form? > > You are saying that you are removing an mandatory AVP? I > guess to ensure interoperability, a new Application ID would > be needed - but why are you removing the AVP? The question is > quite hypothetical, and it is hard to advise the proper > behavior without more concrete examples. > > > The last question: If the difference beween the old version and the > > new > version is that a new > > command is added is it then necessary to get a new application-Id > allocated, or can interoperability > > be achieved in the way that the node sending the new command must be > prepared to receive the error > > 3001 (unsupported command) and fall back to Rel-5? > > In general, adding new commands mean that a new Application > ID is needed. > > However, your questions are extremely hypothetical. The > important questions are why are you adding new (mandatory) > AVPs and commands. Are these really needed? Arbitrarily > adding new mandatory AVPs and commands create > interoperability problems, and that is why the Diameter Base > spec tries to advise against doing so, unless absolutely necessarily. > > best regards, > John >=20 From owner-aaa-wg@merit.edu Tue May 4 03:39:21 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 DAA14486 for ; Tue, 4 May 2004 03:39:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 099BE91273; Tue, 4 May 2004 03:39:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C725C91275; Tue, 4 May 2004 03:39:03 -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 B336491273 for ; Tue, 4 May 2004 03:39:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EF4F58C9C; Tue, 4 May 2004 03:39:02 -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 ADD3158DDA for ; Tue, 4 May 2004 03:39:01 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i447crv25075; Tue, 4 May 2004 10:38:53 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 10:38:24 +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 i447cOkm009670; Tue, 4 May 2004 10:38:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00c5lfVq; Tue, 04 May 2004 10:38:23 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 i447cMH21980; Tue, 4 May 2004 10:38:22 +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, 4 May 2004 10:38:22 +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 support in Diameter Date: Tue, 4 May 2004 10:38:17 +0300 Message-ID: Thread-Topic: RE : [AAA-WG]: Questions on RFC 3588 Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EA== From: To: , X-OriginalArrivalTime: 04 May 2004 07:38:22.0515 (UTC) FILETIME=[C6F1C030:01C431AA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, There have been a number of mails about Application IDs and mandatory = AVPs, and so forth in Diameter. It seems that there is a desire to support = application versioning (at least adding new mandatory AVPs to existing applications. It is my opinion that an implementation adding additional mandatory AVPs = cannot be considered conformant to the Diameter Application if it does this. A = Diameter implementation receiving a command with a new mandatory AVP is not = required to process the message in any way. It MAY send an error with error code = 5001, but is not required to. Additionally, if more than one unsupported = mandatory AVP=20 is sent, Section 7 says: The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order). =20 Therefore, it is problematic to add mandatory AVPs to existing = implementations and it is the intent of the Diameter Base Specification to require a new = Application in instances when new mandatory AVPs are required. John From owner-aaa-wg@merit.edu Tue May 4 04:53:54 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 EAA17817 for ; Tue, 4 May 2004 04:53:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D68F491276; Tue, 4 May 2004 04:53:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A41B091279; Tue, 4 May 2004 04:53: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 46FBA91276 for ; Tue, 4 May 2004 04:53:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29C0758CF4; Tue, 4 May 2004 04:53:37 -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 222D758CEE for ; Tue, 4 May 2004 04:53:36 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i448rYH14304; Tue, 4 May 2004 11:53:34 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 11:53:06 +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 i448r6Fg011646; Tue, 4 May 2004 11:53:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 005Lr3ew; Tue, 04 May 2004 11:53:04 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i448r4H27953; Tue, 4 May 2004 11:53:04 +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); Tue, 4 May 2004 11:52:50 +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]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 4 May 2004 11:52:52 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0535@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcQxTIm58PcL9v2URiKoSsWMC7D9bAAZPb0g From: To: Cc: , , X-OriginalArrivalTime: 04 May 2004 08:52:50.0954 (UTC) FILETIME=[2E576EA0:01C431B5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Chris, >It's not just for translating AVPs on the fly, but also for how to = re-use existing RADIUS=20 >VSA AVPs.=20 >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, = that I now want to=20 >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all = AVP codes 0 to 255=20 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP = code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the = RADIUS VSAs defined >for 3GPP.=20 >When I want to put this information into a Diameter AVP, do I set the = Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS = replacement within Diameter. If you just use the NASREQ defined AVPs, = that practically uses those AVP numbers from 1 through 255 you're = talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think = you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. = According to the mentioned rules the V bit is to be set.=20 I copied here sect. 9.4 of the NASREQ draft, that clearly state that = attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard From owner-aaa-wg@merit.edu Tue May 4 05:53:18 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 FAA19230 for ; Tue, 4 May 2004 05:53:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EE5189127A; Tue, 4 May 2004 05:53:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7B929127B; Tue, 4 May 2004 05:53:05 -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 6EF849127A for ; Tue, 4 May 2004 05:53:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EAA7358E4B; Tue, 4 May 2004 05:53:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 8F25158E31 for ; Tue, 4 May 2004 05:53:02 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i448vIkM025680 for ; Tue, 4 May 2004 10:57:18 +0200 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]: AW: Application support in Diameter X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 11:52:55 +0200 Message-ID: <64F95EC22E92334EA21188664F36A4820241C6@gkshfd03.gksag.net> Thread-Topic: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4A From: "Wiehe Ulrich" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John, RFC 3588 section 4.1 says: "If an AVP with the 'M' bit set is received by a Diameter client, = server, proxy, or translation agent and either the AVP or its value is = unrecognized, the message MUST be rejected." Therefore I'm afraid you are not right in saying that "A Diameter implementation receiving a command with a new mandatory AVP is not = required to process the message in any way." =20 If more than one new AVPs with M-bit set are added then only the first unsupported one is required to be returned. The sender may re-send the command omitting this AVP, but will receiver a second 5001 error. Again, = the sender may re-send the command omitting also the second AVP and so on. Eventually the command will not be rejected with 5001. To avoid this = multiple round trip it would be a good idea to return all unsupported AVPs (the = first detected one must be returned, the others may be returned). Note that = 3588 section 7.1.5 says: " A Diameter message with this error MUST contain = one or more Failed-AVP AVP containing the AVPs that caused the failure. Ulrich -----Urspr=FCngliche Nachricht----- Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Dienstag, 4. Mai 2004 09:38 An: Wiehe Ulrich; aaa-wg@merit.edu Betreff: Application support in Diameter Hi all, There have been a number of mails about Application IDs and mandatory = AVPs, and so forth in Diameter. It seems that there is a desire to support = application versioning (at least adding new mandatory AVPs to existing applications. It is my opinion that an implementation adding additional mandatory AVPs cannot be considered conformant to the Diameter Application if it does this. A Diameter implementation receiving a command with a new mandatory AVP is not = required to process the message in any way. It MAY send an error with error code 5001, but is not required to. Additionally, if more than one unsupported = mandatory AVP=20 is sent, Section 7 says: The Result-Code AVP describes the error that the Diameter node encountered in its processing. In case there are multiple errors, the Diameter node MUST report only the first error it encountered (detected possibly in some implementation dependent order). =20 Therefore, it is problematic to add mandatory AVPs to existing implementations and it is the intent of the Diameter Base Specification to require a new Application in instances when new mandatory AVPs are required. John From owner-aaa-wg@merit.edu Tue May 4 06:43: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 GAA21403 for ; Tue, 4 May 2004 06:43:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E0ED59127D; Tue, 4 May 2004 06:43:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC7229127E; Tue, 4 May 2004 06:43: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 7C0E49127D for ; Tue, 4 May 2004 06:43:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61F7A58E45; Tue, 4 May 2004 06:43:28 -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 07A2358E15 for ; Tue, 4 May 2004 06:43:27 -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 i44AhFk01137; Tue, 4 May 2004 13:43:15 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 13:42:19 +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 i44AgJlm001753; Tue, 4 May 2004 13:42:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00C7f2pK; Tue, 04 May 2004 13:42:17 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 i44AgGH12736; Tue, 4 May 2004 13:42:16 +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, 4 May 2004 13:42:15 +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: RE : [AAA-WG]: Application support in Diameter Date: Tue, 4 May 2004 13:42:15 +0300 Message-ID: Thread-Topic: [AAA-WG]: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAD7ZJAAALLkIA= From: To: , , X-OriginalArrivalTime: 04 May 2004 10:42:15.0789 (UTC) FILETIME=[7749C1D0:01C431C4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lionel, > If a given application is defined with a specific mandatory=20 > AVP, let us called it "Application-Version AVP", defining the=20 > set of mandatory AVPs that must be supported (used with the=20 > M-bit set), it could be possible to define a new set of=20 > mandatory AVPs and remain compliant with the Diameter base protocol. >=20 > * The CER/CEA exhange would be used as defined in RFC=20 > 3588, to advertize supported applications. > * The "Application-Version AVP" would be used along with=20 > the application-ID in every request sent by a =09 > Diameter peer (except CER/CEA). > * The receiver would check the couple (Application-ID +=20 > Application-Version) before any other action. > * The Application-Version AVP defines the set of AVPs=20 > that have to be supported. If the receiver does not=20 > support this version, this would occur an error message. This=20 > error message may inform the originator of the request about=20 > the supported Application-Version. >=20 > It would be therefore possible to add new mandatory AVPs=20 > without creating a new application ID. The only restriction=20 > is to remain unmodified the command code ABNF definition. If=20 > a new AVP is added to the ABNF or a new command is needed, a=20 > new application ID would have to be assigned. In this=20 > context, CER/CEA exchange is then only used to be sure that=20 > the Diameter peers will exchange supported commands (and not=20 > mandatory=20 >=20 > Could it be a generic way to solve this problem application=20 > versioning? This is more-or-less what I was thinking. However, some care probably should be taken in designing this. I think unlimited extensions could casuse some trouble, the application would need to specify what parts could be update by new AVPs, etc. John From owner-aaa-wg@merit.edu Tue May 4 06:48: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 GAA21702 for ; Tue, 4 May 2004 06:48:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6850E9127E; Tue, 4 May 2004 06:48:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33D779127F; Tue, 4 May 2004 06:48: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 036839127E for ; Tue, 4 May 2004 06:48:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DDB2058DA5; Tue, 4 May 2004 06:48:12 -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 D278558D7C for ; Tue, 4 May 2004 06:48:11 -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 i44Am70O026012; Tue, 4 May 2004 12:48:07 +0200 Received: from [138.203.209.107] ([138.203.209.107]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004050412480507:2568 ; Tue, 4 May 2004 12:48:05 +0200 Message-ID: <409774E4.7010006@alcatel.be> Date: Tue, 04 May 2004 12:48:04 +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: Mark Jones , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/04/2004 12:48:05, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/04/2004 12:48:07, Serialize complete at 05/04/2004 12:48:07 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 Mark Jones wrote: >I have a comment on the following section (2.2) in nasreq-15: > > If accounting is active, every change of authentication or > authorization SHOULD generate an accounting message. If the NAS > service is a continuation of the prior user context, then an > Accounting-Record-Type of INTERIM_RECORD indicating the new session > attributes and cumulative status would be appropriate. If a new user > or a significant change in authorization is detected by the NAS, then > the service may consider it appropriate to send two messages of the > types STOP_RECORD, and START_RECORD. > >In the re-authorization case, I am not comfortable with letting the NAS >implementor deciding what constitutes a "significant change". The >re-authorization request is used to trigger events of significant billing >interest so predictable behavior across vendors is critical. I think >interoperability would be better served by a more explicit requirement on >the NAS. Two possible solutions come to mind: > >EITHER > >(1) If the re-authorization results in a change to any of the service >parameters, the NAS MUST treat this as a new session and send two messages >(Stop/Start). > >OR > >(2) The AAA server MUST specify whether the Stop/Start is required at the >time it requests the re-authorization. If the AAA server does not request a >Stop/Start at re-authorization, the NAS MUST NOT send any accounting >messages for this event. > >I have a preference for (2) since it eliminates redundant accounting >messages in those cases where the service provider is not dependent on the >Stop/Start messages to bill for the service change triggered by >re-authorization. > >Regards >Mark > > Then what do we do with current BRAS'es (Redback SMC and Redback SE800 for example) that already send an Accounting-Update packet when an reauthorization happens ? I know that's in RADIUS, but DIAMETER should still be backwards compatible. Your MUST NOT will prevent us from proxying those events. -- Jo Hermans From owner-aaa-wg@merit.edu Tue May 4 06:59: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 GAA22578 for ; Tue, 4 May 2004 06:59:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A7DD9127F; Tue, 4 May 2004 06:59:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E03891280; Tue, 4 May 2004 06:59:37 -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 EE4679127F for ; Tue, 4 May 2004 06:59:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CF20858E54; Tue, 4 May 2004 06:59:36 -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 209E058E46 for ; Tue, 4 May 2004 06:59:36 -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 i44AxY0O029542 for ; Tue, 4 May 2004 12:59:34 +0200 Received: from [138.203.209.107] ([138.203.209.107]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004050412593314:2642 ; Tue, 4 May 2004 12:59:33 +0200 Message-ID: <40977795.9070706@alcatel.be> Date: Tue, 04 May 2004 12:59:33 +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]: question on draft-ietf-aaa-diameter-sip-app-02 X-MIMETrack: Itemize by SMTP Server on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/04/2004 12:59:33, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/04/2004 12:59:33, Serialize complete at 05/04/2004 12:59:33 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 noticed that in draft-ietf-aaa-diameter-sip-app-02.txt, Route-Record is added to each Answer-request (UAA, SAA, LIA, MAA, RTA, PPA). But according to BASE, we have to add this attribute for each request that is forwarded. The purpose is to check for loops, but that's only necessary in requests. I agree that BASE doesn't explicitly forbid this attribute in the response, but none of the command-codes defined in BASE have a Route-Record in a Response. I also checked all the other applications-drafts, but the SIP-application is the only one that does it.. -- Jo Hermans From owner-aaa-wg@merit.edu Tue May 4 07:02: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 HAA22983 for ; Tue, 4 May 2004 07:02:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D12A591280; Tue, 4 May 2004 07:01:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A083E91281; Tue, 4 May 2004 07:01: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 3769C91280 for ; Tue, 4 May 2004 07:01:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AF1558A49; Tue, 4 May 2004 07:01:37 -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 F1D3058DDA for ; Tue, 4 May 2004 07:01:35 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44B1Dv23328; Tue, 4 May 2004 14:01:13 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 13:59:57 +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 i44Axv7S015551; Tue, 4 May 2004 13:59:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00gD5C9j; Tue, 04 May 2004 13:59:55 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 i44AxsH26309; Tue, 4 May 2004 13:59:54 +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, 4 May 2004 13:59: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: RE: [AAA-WG]: AW: Application support in Diameter Date: Tue, 4 May 2004 13:59:53 +0300 Message-ID: Thread-Topic: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAAQETNA= From: To: , X-OriginalArrivalTime: 04 May 2004 10:59:54.0001 (UTC) FILETIME=[EE081810:01C431C6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Ulrich, > RFC 3588 section 4.1 says: > "If an AVP with the 'M' bit set is received by a Diameter client, = server, > proxy, or translation agent and either the AVP or its value is = unrecognized, > the message MUST be rejected." >=20 > Therefore I'm afraid you are not right in saying that "A Diameter > implementation receiving a command with a new mandatory AVP is not = required > to process the message in any way." =20 The first paragraph you show above is correct. The RFC isn't exactly clear on what a recieving end should do if it does recieve an AVP with the M bit set that it doesn't understand. Anyhow, this is a small point, not the main point that you are discussing. =20 > If more than one new AVPs with M-bit set are added then only the first > unsupported one is required to be returned. The sender may re-send the > command omitting this AVP, but will receiver a second 5001 error. = Again, the > sender may re-send the command omitting also the second AVP and so on. > Eventually the command will not be rejected with 5001. To avoid this = multiple > round trip it would be a good idea to return all unsupported AVPs (the = first > detected one must be returned, the others may be returned). Note that = 3588 > section 7.1.5 says: " A Diameter message with this error MUST contain = one or > more Failed-AVP AVP containing the AVPs that caused the failure. This is optional behavior in the Diameter base specification, it is not = mandatory behavior. If you want to have this kind of behavior, it would probably = be best to make this as a requirement in your Diameter Application. John From owner-aaa-wg@merit.edu Tue May 4 07:10:37 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 HAA23702 for ; Tue, 4 May 2004 07:10:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD9AE91281; Tue, 4 May 2004 07:10:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78E6B91282; Tue, 4 May 2004 07: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 2620F91281 for ; Tue, 4 May 2004 07:10:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0C96E58E58; Tue, 4 May 2004 07:10: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 EA2FA58E42 for ; Tue, 4 May 2004 07:10:18 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44BAHH19089 for ; Tue, 4 May 2004 14:10:17 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 14:09:20 +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 i44B9K7b007644 for ; Tue, 4 May 2004 14:09:20 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00JWxlMY; Tue, 04 May 2004 14:09:19 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 i44B9IH04012 for ; Tue, 4 May 2004 14:09:18 +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); Tue, 4 May 2004 14:09:17 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 14:09: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]: AW: Application support in Diameter Date: Tue, 4 May 2004 14:09:16 +0300 Message-ID: <9B95641F3AE80F4C8CD5B288FE8C9631AAAFAD@esebe012.ntc.nokia.com> Thread-Topic: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAARI0/A= From: To: X-OriginalArrivalTime: 04 May 2004 11:09:18.0297 (UTC) FILETIME=[3E60D490:01C431C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, > If more than one new AVPs with M-bit set are added then only the first > unsupported one is required to be returned. The sender may re-send the > command omitting this AVP, but will receiver a second 5001=20 > error. Again, the sender may re-send the command omitting also the = second > AVP and so on. Eventually the command will not be rejected with 5001. I think we should not base application version control on this kind of fallback behavior. It might be so that in some cases the sender is not able to re-send the command omitting the AVP because the command with that AVP is the only kind of command the sender should send in that particular situation. There might also be dependecies between AVPs that need to be taken in account. These fallback scenarios should be = specified explicitly in each application case-by-case (AVP-by-AVP). I think sending back the failed AVP is more useful for troubleshooting purposes instead of version control. It is better to define versions for the applications explicitly and base the version control on that. One possibility to indicate the version of application is the application-id, i.e. each new backward incompatible version of the application would get new application-id. BR, Mikko > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Wiehe Ulrich > Sent: 04 May, 2004 12:53 > To: Loughney John (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: [AAA-WG]: AW: Application support in Diameter >=20 >=20 > John, >=20 > RFC 3588 section 4.1 says: > "If an AVP with the 'M' bit set is received by a Diameter=20 > client, server, > proxy, or translation agent and either the AVP or its value=20 > is unrecognized, > the message MUST be rejected." >=20 > Therefore I'm afraid you are not right in saying that "A Diameter > implementation receiving a command with a new mandatory AVP=20 > is not required > to process the message in any way." =20 >=20 > If more than one new AVPs with M-bit set are added then only the first > unsupported one is required to be returned. The sender may re-send the > command omitting this AVP, but will receiver a second 5001=20 > error. Again, the > sender may re-send the command omitting also the second AVP and so on. > Eventually the command will not be rejected with 5001. To=20 > avoid this multiple > round trip it would be a good idea to return all unsupported=20 > AVPs (the first > detected one must be returned, the others may be returned).=20 > Note that 3588 > section 7.1.5 says: " A Diameter message with this error MUST=20 > contain one or > more Failed-AVP AVP containing the AVPs that caused the failure. >=20 >=20 > Ulrich >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Gesendet: Dienstag, 4. Mai 2004 09:38 > An: Wiehe Ulrich; aaa-wg@merit.edu > Betreff: Application support in Diameter >=20 > Hi all, >=20 > There have been a number of mails about Application IDs and=20 > mandatory AVPs, > and > so forth in Diameter. It seems that there is a desire to=20 > support application > versioning (at least adding new mandatory AVPs to existing=20 > applications. >=20 > It is my opinion that an implementation adding additional=20 > mandatory AVPs > cannot > be considered conformant to the Diameter Application if it=20 > does this. A > Diameter > implementation receiving a command with a new mandatory AVP=20 > is not required > to process the message in any way. It MAY send an error with=20 > error code > 5001, > but is not required to. Additionally, if more than one=20 > unsupported mandatory > AVP=20 > is sent, Section 7 says: >=20 > The Result-Code AVP describes the error that the Diameter node > encountered in its processing. In case there are multiple errors, > the Diameter node MUST report only the first error it encountered > (detected possibly in some implementation dependent order). =20 >=20 > Therefore, it is problematic to add mandatory AVPs to existing > implementations > and it is the intent of the Diameter Base Specification to=20 > require a new > Application > in instances when new mandatory AVPs are required. >=20 > John >=20 From owner-aaa-wg@merit.edu Tue May 4 07:11: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 HAA23806 for ; Tue, 4 May 2004 07:11:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADFD391282; Tue, 4 May 2004 07:11:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 877EA91283; Tue, 4 May 2004 07:11: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 7BCA391282 for ; Tue, 4 May 2004 07:11:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61F3858E5B; Tue, 4 May 2004 07:11:22 -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 08CEE58E59 for ; Tue, 4 May 2004 07:11:20 -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 i44BBJk29426; Tue, 4 May 2004 14:11:19 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 14:11:15 +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 i44BBFM5012598; Tue, 4 May 2004 14:11:15 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00i67eeS; Tue, 04 May 2004 14:11:14 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 i44BBDH05624; Tue, 4 May 2004 14:11:13 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 14:11:13 +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]: question on draft-ietf-aaa-diameter-sip-app-02 Date: Tue, 4 May 2004 14:11:12 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3A80@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: question on draft-ietf-aaa-diameter-sip-app-02 Thread-Index: AcQxxxos3t5/+OuxQoqTo3RikcPGAgAAIk4A From: To: , X-OriginalArrivalTime: 04 May 2004 11:11:13.0675 (UTC) FILETIME=[83261DB0:01C431C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, RFC3588 is inconsistent about this; some text in Section 2.10=20 requires that responses do have Route-Record AVPs. This was discussed in issue #424 (link below), but somehow the issue got closed without really being resolved. http://www.drizzle.com/~aboba/AAA/issues5.html#Issue%20424 Best regards, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu On Behalf Of johan.rh.hermans@alcatel.be > Sent: Tuesday, May 04, 2004 2:00 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: question on draft-ietf-aaa-diameter-sip-app-02 >=20 > I noticed that in draft-ietf-aaa-diameter-sip-app-02.txt, > Route-Record is added to each Answer-request (UAA, SAA, LIA, MAA, > RTA, PPA). But according to BASE, we have to add this attribute for > each request that is forwarded. The purpose is to check for loops, > but that's only necessary in requests. I agree that BASE doesn't > explicitly forbid this attribute in the response, but none of the > command-codes defined in BASE have a Route-Record in a Response. I > also checked all the other applications-drafts, but the > SIP-application is the only one that does it.. > > --=20 > Jo Hermans =20 From owner-aaa-wg@merit.edu Tue May 4 08:01: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 IAA26073 for ; Tue, 4 May 2004 08:01:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25DC991283; Tue, 4 May 2004 08:01:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DAD091269; Tue, 4 May 2004 08:01: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 B3F9891284 for ; Tue, 4 May 2004 08:01:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6224958D27; Tue, 4 May 2004 08:01: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 1BAA658CCB for ; Tue, 4 May 2004 08:01:30 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44BuEB15454; Tue, 4 May 2004 14:56:15 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 14:55:30 +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 i44BtUMk024224; Tue, 4 May 2004 14:55:30 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00OpHIii; Tue, 04 May 2004 14:55:29 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 i44BtJH15320; Tue, 4 May 2004 14:55:19 +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); Tue, 4 May 2004 14:55:15 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 14:55:15 +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: RE : RE : [AAA-WG]: Application support in Diameter Date: Tue, 4 May 2004 14:55:14 +0300 Message-ID: Thread-Topic: RE : [AAA-WG]: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAD7ZJAAALLkIAAAOJA4AAA4oVw From: To: , , X-OriginalArrivalTime: 04 May 2004 11:55:15.0360 (UTC) FILETIME=[A9B74200:01C431CE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lionel, > Maybe I should clarify that the set of mandatory AVPs defined=20 > by the Application-Version "N+1" is equal to the set for=20 > application-Version "N" + new mandatory AVPs. Therefore, to=20 > insure interoperability and backward compatibility, it is=20 > needed to update the reference document for the given=20 > application with the set of new AVPs. > One new Application-version will correspond to one new=20 > version of the reference document and would support all the=20 > previous versions. If it is not possible (or not wanted=20 > anymore) to fulfill this requirement, a new application ID=20 > will be also assigned in this case. What is the difference between application and application version? If you have an application called Foo_v1, then you make modifications so now you have Foo_v2, what problems would this cause? Your server could advertise support for Foo_v1 and Foo_v2. If my client supports only Foo_v1, then we could negotiated that with the CEA/CER messages. Is there a reason why this mechanism is not sufficient and something more complicated needs to be invented? John From owner-aaa-wg@merit.edu Tue May 4 08:25:23 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 IAA27099 for ; Tue, 4 May 2004 08:25:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1750591285; Tue, 4 May 2004 08:25:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF5D591286; Tue, 4 May 2004 08:25: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 A163A91285 for ; Tue, 4 May 2004 08:25:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8736958E52; Tue, 4 May 2004 08:25:09 -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 0611758E4D for ; Tue, 4 May 2004 08:25:08 -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 i44CP6k16517; Tue, 4 May 2004 15:25:06 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:25:05 +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 i44CP5HW022227; Tue, 4 May 2004 15:25:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00MpHV2H; Tue, 04 May 2004 15:25:04 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 i44COwH05510; Tue, 4 May 2004 15:24:58 +0300 (EET DST) Received: from nokia.com ([10.162.12.18]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:24:55 +0300 Message-ID: <40978B98.90601@nokia.com> Date: Tue, 04 May 2004 15:24:56 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: johan.rh.hermans@alcatel.be, aaa-wg@merit.edu Subject: Re: [AAA-WG]: question on draft-ietf-aaa-diameter-sip-app-02 References: <052E0C61B69C3741AFA5FE88ACC775A6010C3A80@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3A80@esebe023.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2004 12:24:55.0820 (UTC) FILETIME=[CEF3E4C0:01C431D2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hmmmm... I was already convinced that Record-Route in answers was a bug in the Diameter SIP application, and I answered that I will fix it. But now that I have read your e-mail, and read the discussion, I believe it is a bug in RFC 3588. Consequently, I will keep the Record-Route AVP in the answers, i.e., no changes with respect the current version. - Miguel Pasi Eronen wrote: > Hi, > > RFC3588 is inconsistent about this; some text in Section 2.10 > requires that responses do have Route-Record AVPs. This was > discussed in issue #424 (link below), but somehow the issue > got closed without really being resolved. > > http://www.drizzle.com/~aboba/AAA/issues5.html#Issue%20424 > > Best regards, > Pasi > > >>-----Original Message----- >>From: owner-aaa-wg@merit.edu On Behalf Of johan.rh.hermans@alcatel.be >>Sent: Tuesday, May 04, 2004 2:00 PM >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: question on draft-ietf-aaa-diameter-sip-app-02 >> >>I noticed that in draft-ietf-aaa-diameter-sip-app-02.txt, >>Route-Record is added to each Answer-request (UAA, SAA, LIA, MAA, >>RTA, PPA). But according to BASE, we have to add this attribute for >>each request that is forwarded. The purpose is to check for loops, >>but that's only necessary in requests. I agree that BASE doesn't >>explicitly forbid this attribute in the response, but none of the >>command-codes defined in BASE have a Route-Record in a Response. I >>also checked all the other applications-drafts, but the >>SIP-application is the only one that does it.. >> >>-- >>Jo Hermans > > > -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Tue May 4 08:35: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 IAA27761 for ; Tue, 4 May 2004 08:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51F2091286; Tue, 4 May 2004 08:34:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 214D491287; Tue, 4 May 2004 08: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 CEDD491286 for ; Tue, 4 May 2004 08:34:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4BF158D8E; Tue, 4 May 2004 08:34:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by segue.merit.edu (Postfix) with ESMTP id 0394758D7C for ; Tue, 4 May 2004 08:34:52 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 14:34:49 +0200 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 : RE : RE : [AAA-WG]: Application support in Diameter Date: Tue, 4 May 2004 14:34:48 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026F22459@ftrdmel2.rd.francetelecom.fr> Thread-Topic: RE : RE : [AAA-WG]: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAD7ZJAAALLkIAAAOJA4AAA4oVwAAE/PuA= From: "MORAND Lionel FTRD/DAC/ISS" To: , , X-OriginalArrivalTime: 04 May 2004 12:34:49.0270 (UTC) FILETIME=[30AD2D60:01C431D4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, From my point of view, it is just an administrative problem. With the current mechanism, a new AVP implies a new application-ID, and = then a request to IANA for allocation number. From my point of view, the procedure is too heavy if you are just = considering addition of mandatory AVPs without modification of the = command ABNF description already specified. With the Application-Version AVP, it would not be necessary to wait for = IANA number allocation to upgrade the application. The aim is to provide = the maximum of flexibility at the application level but to remain = compliant with the RFC 3588 defining the base protocol. BTW, I'm not sure that it would be so complicated to implement and to = manage. Lionel > -----Message d'origine----- > De : owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > De la part de john.loughney@nokia.com > Envoy=E9 : mardi 4 mai 2004 13:55 > =C0 : MORAND Lionel FTRD/DAC/ISS; Ulrich.Wiehe@gksag.de;=20 > aaa-wg@merit.edu > Objet : RE: RE : RE : [AAA-WG]: Application support in Diameter >=20 >=20 > Hi Lionel, >=20 > > Maybe I should clarify that the set of mandatory AVPs defined > > by the Application-Version "N+1" is equal to the set for=20 > > application-Version "N" + new mandatory AVPs. Therefore, to=20 > > insure interoperability and backward compatibility, it is=20 > > needed to update the reference document for the given=20 > > application with the set of new AVPs. > > One new Application-version will correspond to one new=20 > > version of the reference document and would support all the=20 > > previous versions. If it is not possible (or not wanted=20 > > anymore) to fulfill this requirement, a new application ID=20 > > will be also assigned in this case. >=20 > What is the difference between application and application=20 > version? If you have an application called Foo_v1, then you=20 > make modifications so now you have Foo_v2, what problems=20 > would this cause? Your server could advertise support for=20 > Foo_v1 and Foo_v2. If my client supports only Foo_v1, then=20 > we could negotiated that with the CEA/CER messages. Is there=20 > a reason why this mechanism is not sufficient and something=20 > more complicated needs to be invented? >=20 > John >=20 From owner-aaa-wg@merit.edu Tue May 4 08:39: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 IAA27896 for ; Tue, 4 May 2004 08:39:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D148C91287; Tue, 4 May 2004 08:39:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2B3B91288; Tue, 4 May 2004 08:39: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 80A2191287 for ; Tue, 4 May 2004 08:39:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F4A858DB6; Tue, 4 May 2004 08:39:39 -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 01E4A58E15 for ; Tue, 4 May 2004 08:39:38 -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 i44CdTv22847; Tue, 4 May 2004 15:39:29 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:38:11 +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 i44CcBCD024314; Tue, 4 May 2004 15:38:11 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00d0RGwL; Tue, 04 May 2004 15:38:10 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 i44Cc8H16398; Tue, 4 May 2004 15:38:08 +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); Tue, 4 May 2004 15:38:07 +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: RE : RE : RE : [AAA-WG]: Application support in Diameter Date: Tue, 4 May 2004 15:38:06 +0300 Message-ID: Thread-Topic: RE : RE : [AAA-WG]: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAD7ZJAAALLkIAAAOJA4AAA4oVwAAE/PuAAAQrGoA== From: To: , , X-OriginalArrivalTime: 04 May 2004 12:38:07.0582 (UTC) FILETIME=[A6E12FE0:01C431D4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Lionel, > From my point of view, it is just an administrative problem. >=20 > With the current mechanism, a new AVP implies a new=20 > application-ID, and then a request to IANA for allocation number. > From my point of view, the procedure is too heavy if you are=20 > just considering addition of mandatory AVPs without=20 > modification of the command ABNF description already specified. >=20 > With the Application-Version AVP, it would not be necessary=20 > to wait for IANA number allocation to upgrade the=20 > application. The aim is to provide the maximum of flexibility=20 > at the application level but to remain compliant with the RFC=20 > 3588 defining the base protocol. You need to request AVP values from IANA as well, so I am not sure this is anyhow different. My main point is, the mechansims for negotiation with Application IDs are defined already. The mechanism you are proposing isn't documented completely in 3588, so that may be problematic. John From owner-aaa-wg@merit.edu Tue May 4 08:42: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 IAA27974 for ; Tue, 4 May 2004 08:42:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C363C91288; Tue, 4 May 2004 08:42:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92B6F91289; Tue, 4 May 2004 08:42: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 4C2BE91288 for ; Tue, 4 May 2004 08:42:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EBC558E25; Tue, 4 May 2004 08:42:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 8CF3B58DD0 for ; Tue, 4 May 2004 08:42:02 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i44BkHkM026592 for ; Tue, 4 May 2004 13:46:17 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [AAA-WG]: AW: Application support in Diameter X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 14:41:55 +0200 Message-ID: <64F95EC22E92334EA21188664F36A4820241C7@gkshfd03.gksag.net> Thread-Topic: [AAA-WG]: AW: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAAQETNAAAvWscA== From: "Wiehe Ulrich" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, The words "the message MUST be rejected" are perfectly clear. What = behaviour other than returning error 5001 do you think they could mean in the = given context? I think this is the main point of the existing mechanism: rely = on the fact that the unsupported AVPs with M bit set are rejected with = error 5001. Anyway, if 3GPP in their specifications for the Cx application mandate = that a node receiving unsupported M bit AVPs within Cx-commands MUST (or shall) return them all with error 5001, would you still be concered?=20 Ulrich -----Urspr=FCngliche Nachricht----- Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Dienstag, 4. Mai 2004 13:00 An: Wiehe Ulrich; aaa-wg@merit.edu Betreff: RE: [AAA-WG]: AW: Application support in Diameter Hi Ulrich, > RFC 3588 section 4.1 says: > "If an AVP with the 'M' bit set is received by a Diameter client, = server, > proxy, or translation agent and either the AVP or its value is unrecognized, > the message MUST be rejected." >=20 > Therefore I'm afraid you are not right in saying that "A Diameter > implementation receiving a command with a new mandatory AVP is not = required > to process the message in any way." =20 The first paragraph you show above is correct. The RFC isn't exactly clear on what a recieving end should do if it does recieve an AVP with the M bit set that it doesn't understand. Anyhow, this is a small point, not the main point that you are discussing. =20 > If more than one new AVPs with M-bit set are added then only the first > unsupported one is required to be returned. The sender may re-send the > command omitting this AVP, but will receiver a second 5001 error. = Again, the > sender may re-send the command omitting also the second AVP and so on. > Eventually the command will not be rejected with 5001. To avoid this multiple > round trip it would be a good idea to return all unsupported AVPs (the first > detected one must be returned, the others may be returned). Note that = 3588 > section 7.1.5 says: " A Diameter message with this error MUST contain = one or > more Failed-AVP AVP containing the AVPs that caused the failure. This is optional behavior in the Diameter base specification, it is not mandatory behavior. If you want to have this kind of behavior, it would probably = be best to make this as a requirement in your Diameter Application. John From owner-aaa-wg@merit.edu Tue May 4 08:47:01 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 IAA28170 for ; Tue, 4 May 2004 08:47:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10A1391269; Tue, 4 May 2004 08:46:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66AEA91289; Tue, 4 May 2004 08:46:41 -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 3434F91269 for ; Tue, 4 May 2004 08:46:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17C5058B38; Tue, 4 May 2004 08:46:40 -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 21FC158DB6 for ; Tue, 4 May 2004 08:46:39 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44CkUH10056; Tue, 4 May 2004 15:46:30 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:45:43 +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 i44Cjhvk014043; Tue, 4 May 2004 15:45:43 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003aENfz; Tue, 04 May 2004 15:45:43 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44CjgH09495; Tue, 4 May 2004 15:45:42 +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); Tue, 4 May 2004 15:45:41 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:45:42 +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]: AW: Application support in Diameter Date: Tue, 4 May 2004 15:45:41 +0300 Message-ID: Thread-Topic: [AAA-WG]: AW: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAAQETNAAAvWscAABKSzg From: To: , X-OriginalArrivalTime: 04 May 2004 12:45:42.0890 (UTC) FILETIME=[B643ACA0:01C431D5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Ulrich, > Anyway, if 3GPP in their specifications for the Cx application mandate = that a > node receiving unsupported M bit AVPs within Cx-commands MUST (or = shall) > return them all with error 5001, would you still be concered?=20 That would be part of the application definition, and my suggestion is = that the application could & should define this. John From owner-aaa-wg@merit.edu Tue May 4 08:50: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 IAA28362 for ; Tue, 4 May 2004 08:50:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C0CC91289; Tue, 4 May 2004 08:49:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 155959128A; Tue, 4 May 2004 08:49: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 D128D91289 for ; Tue, 4 May 2004 08:49:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD52958E26; Tue, 4 May 2004 08:49:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from utnapashtim.gksag.de (utnapashtim.gksag.de [212.218.229.194]) by segue.merit.edu (Postfix) with ESMTP id 358AD58E25 for ; Tue, 4 May 2004 08:49:56 -0400 (EDT) Received: from gkshfd03.gksag.net ([172.18.1.35]) by utnapashtim.gksag.de (8.12.5/8.12.5/Debian-1) with ESMTP id i44BsBkM026638 for ; Tue, 4 May 2004 13:54:11 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [AAA-WG]: AW: Application support in Diameter X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 May 2004 14:49:49 +0200 Message-ID: <64F95EC22E92334EA21188664F36A48224E458@gkshfd03.gksag.net> Thread-Topic: [AAA-WG]: AW: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAAQETNAAAvWscAABKSzgAAAjoQA= From: "Wiehe Ulrich" To: , Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John, Thank you very much for your help. Best regards Ulrich -----Urspr=FCngliche Nachricht----- Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 Gesendet: Dienstag, 4. Mai 2004 14:46 An: Wiehe Ulrich; aaa-wg@merit.edu Betreff: RE: [AAA-WG]: AW: Application support in Diameter Ulrich, > Anyway, if 3GPP in their specifications for the Cx application mandate = that a > node receiving unsupported M bit AVPs within Cx-commands MUST (or = shall) > return them all with error 5001, would you still be concered?=20 That would be part of the application definition, and my suggestion is = that the application could & should define this. John From owner-aaa-wg@merit.edu Tue May 4 08:58: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 IAA28647 for ; Tue, 4 May 2004 08:58:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C7739128A; Tue, 4 May 2004 08:58:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13BDA9128C; Tue, 4 May 2004 08:58: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 3534F9128A for ; Tue, 4 May 2004 08:58:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1035858E93; Tue, 4 May 2004 08:58:32 -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 9CB4458E8E for ; Tue, 4 May 2004 08:58:30 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i44CwSH22941 for ; Tue, 4 May 2004 15:58:28 +0300 (EET DST) X-Scanned: Tue, 4 May 2004 15:57:46 +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 i44CvkZ6009926 for ; Tue, 4 May 2004 15:57:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00LnBE27; Tue, 04 May 2004 15:57:45 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 i44CviH02787 for ; Tue, 4 May 2004 15:57:44 +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); Tue, 4 May 2004 15:57:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 4 May 2004 15:57:43 +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]: AW: Application support in Diameter Date: Tue, 4 May 2004 15:57:42 +0300 Message-ID: Thread-Topic: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAARI0/AABDw+MA== From: To: , X-OriginalArrivalTime: 04 May 2004 12:57:43.0880 (UTC) FILETIME=[64020480:01C431D7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Mikko, > > If more than one new AVPs with M-bit set are added then only the = first > > unsupported one is required to be returned. The sender may re-send = the > > command omitting this AVP, but will receiver a second 5001=20 > > error. Again, the sender may re-send the command omitting also the = second > > AVP and so on. Eventually the command will not be rejected with = 5001. >=20 > I think we should not base application version control on this kind > of fallback behavior. It might be so that in some cases the sender > is not able to re-send the command omitting the AVP because the = command > with that AVP is the only kind of command the sender should send in = that > particular situation. There might also be dependecies between AVPs = that > need to be taken in account. These fallback scenarios should be = specified > explicitly in each application case-by-case (AVP-by-AVP). > > I think sending back the failed AVP is more useful for troubleshooting > purposes instead of version control. The points you raise are correct, and this is why negotiating AVP-by-AVP is quite complicated. > It is better to define versions for the applications explicitly and > base the version control on that. One possibility to indicate the > version of application is the application-id, i.e. each new backward > incompatible version of the application would get new application-id. This is the intent of the Diameter Base spec, specifically CER/CEA = exchange. I am not sure why something more complicated is needed. John From owner-aaa-wg@merit.edu Tue May 4 09:18:03 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 JAA29464 for ; Tue, 4 May 2004 09:18:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABC6D9128B; Tue, 4 May 2004 09:17:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F3129128C; Tue, 4 May 2004 09:17: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 3693D9128B for ; Tue, 4 May 2004 09:17:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E84E658DC3; Tue, 4 May 2004 09:17:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by segue.merit.edu (Postfix) with ESMTP id 4D89158D27 for ; Tue, 4 May 2004 09:17:48 -0400 (EDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 4 May 2004 15:17:07 +0200 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE : [AAA-WG]: AW: Application support in Diameter Date: Tue, 4 May 2004 15:17:06 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026F22493@ftrdmel2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: AW: Application support in Diameter Thread-Index: AcQuvYw9T82rDN62RMewnw6ojlQt1ACHhC1gAAHtXxAAC2WaIAAecYDgAAWd2LAAAgh6EAAC8l4AAARI0/AABDw+MAAAKCig From: "MORAND Lionel FTRD/DAC/ISS" To: , , X-OriginalArrivalTime: 04 May 2004 13:17:07.0108 (UTC) FILETIME=[19588640:01C431DA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, > > It is better to define versions for the applications explicitly and=20 > > base the version control on that. One possibility to indicate the=20 > > version of application is the application-id, i.e. each new=20 > backward=20 > > incompatible version of the application would get new=20 > application-id. >=20 > This is the intent of the Diameter Base spec, specifically=20 > CER/CEA exchange. I am not sure why something more=20 > complicated is needed. Because I think that the original purpose was to distinguish application (1) from application (2) (e.g. NASREQ from MIPv4) that have few overlapping in term of procedures, commands or AVPs. The problem is quite different when you are considering versions of the same application, with the same command and a common set of AVPs. And I'm not sure that this point was clearly in mind. Lionel =20 From owner-aaa-wg@merit.edu Tue May 4 10:25: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 KAA04152 for ; Tue, 4 May 2004 10:25:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E42019128F; Tue, 4 May 2004 10:25:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF5D791290; Tue, 4 May 2004 10:25: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 A3B629128F for ; Tue, 4 May 2004 10:25:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86CBF58DDF; Tue, 4 May 2004 10:25:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 4787F58DB6 for ; Tue, 4 May 2004 10:25:18 -0400 (EDT) Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i44EPGT15887 for ; Tue, 4 May 2004 09:25:16 -0500 (CDT) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JC3C0660; Tue, 4 May 2004 09:25:17 -0500 Received: from nortelnetworks.com (BLUETICK [47.102.184.235]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRJR32JF; Tue, 4 May 2004 09:25:16 -0500 Message-ID: <4097A7A7.4070004@nortelnetworks.com> Date: Tue, 04 May 2004 14:24:39 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell 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 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Peer State Machine problem 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 Section 5.6 of RFC 3588 indicates that the state machine described therein is closely coupled with the Watchdog Algorithm state machine in RFC 3539. However, the 3588 state machine doesn't explicitly include the behavior of suspending and reopening connections. From this I infer that my implementation must implement a state machine that is synthesized from the sate machines in 3588 and 3539. Most of this is obvious, but there are a couple of points I am unsure of: 1. When re-opening a connection, do I send the CER before or after receiving the three successive DWAs? 2. When I am in the REOPEN state and I receive any message that is not a DWA, 3539 says I should throw it away. Does this include a DWR? If so, are both sides of the connection implementing the same logic? (If so, I think REOPEN->OKAY would never happen for either). From owner-aaa-wg@merit.edu Tue May 4 10:53: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 KAA06298 for ; Tue, 4 May 2004 10:53:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B0A591290; Tue, 4 May 2004 10:53:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C657991292; Tue, 4 May 2004 10:53: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 5730F91290 for ; Tue, 4 May 2004 10:53:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4602E58E7A; Tue, 4 May 2004 10:53:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id E2F6A58E73 for ; Tue, 4 May 2004 10:53:04 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i44EqwC17378; Tue, 4 May 2004 09:52:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 May 2004 09:52:59 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753069F6CE0@zrc2c012.us.nortel.com> From: "Christopher Richards" To: marco.stura@nokia.com Cc: david@mitton.com, aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 4 May 2004 09:52:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C431E7.7D30B70C" 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_01C431E7.7D30B70C Content-Type: text/plain Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C431E7.7D30B70C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter = applications should follow the NASREQ specification when encoding = RADIUS vendor specific AVPs, I think it would be beneficial if some = statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a = DCC message, the rules described in [NASREQ] for formatting the = Diameter AVP MUST be followed. For example, the AVP code used is the = vendor attribute type code, the Vendor-Specific flag MUST be set to 1 = and the Vendor-ID MUST be set to the IANA Vendor identification value. = The Diameter AVP data field contains only the attribute value of the = RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS = VSA AVPs


Hi Chris,

>It's not just for translating AVPs on the fly, = but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that = was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to = completely redefine it.
>From my reading of RFC3588, it says something = along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also = took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS = 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a = Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the = generic RADIUS replacement within Diameter. If you just use the NASREQ = defined AVPs, that practically uses those AVP numbers from 1 through = 255 you're talking about, you should be able to match the 3GPP TS = 29.061 needs.

For those 3gpp vendor-specific attributes defined in = TS 29.061 I think you should follow the rules defined in NASREQ section = 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit = is to be set.

I copied here sect. 9.4 of the NASREQ draft, that = clearly state that attribute code 26 must not appear in Diameter = messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT = appear in a Diameter
   message.  Instead, they are = translated to other Diameter AVPs or
   handled in some special manner. The = rules for the treatment of the
   attributes are discussed in Sections = 9.1, 9.2 and 9.6.


   Attribute = Description       = Defined     Nearest Diameter AVP
   = -----------------------------------------------------------------=
    3 = CHAP-Password          = ;  RFC 2865    CHAP-Auth Group
   26 = Vendor-Specific          = RFC 2865    Vendor Specific AVP
   29 = Termination-Action       RFC = 2865    Authorization-Lifetime
   40 = Acct-Status-Type         RFC = 2866    Accounting-Record-Type
   42 = Acct-Input-Octets        RFC = 2866    Accounting-Input-Octets
   43 = Acct-Output-Octets       RFC = 2866    Accounting-Output-Octets
   47 = Acct-Input-Packets       RFC = 2866    Accounting-Input-Packets
   48 = Acct-Output-Packets      RFC = 2866    Accounting-Output-Packets
   49 = Acct-Terminate-Cause     RFC 2866    = Termination-Cause
   52 = Acct-Input-Gigawords     RFC 2869    = Accounting-Input-Octets
   53 = Acct-Output-Gigawords    RFC 2869    = Accounting-Output-Octets
   80 = Message-Authenticator    RFC 2869    none = - check and discard

------_=_NextPart_001_01C431E7.7D30B70C-- From owner-aaa-wg@merit.edu Tue May 4 12:01:30 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 MAA10226 for ; Tue, 4 May 2004 12:01:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77B5C9129A; Tue, 4 May 2004 12:00:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 471FD9129C; Tue, 4 May 2004 12:00: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 4585B9129A for ; Tue, 4 May 2004 12:00:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D5E358E08; Tue, 4 May 2004 12:00:41 -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 48FFE58D7D for ; Tue, 4 May 2004 12:00:40 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i44G5EX04114; Tue, 4 May 2004 09:05:14 -0700 Date: Tue, 4 May 2004 09:05:14 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Application support in Diameter 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 > It is my opinion that an implementation adding additional mandatory AVPs cannot > be considered conformant to the Diameter Application if it does this. A Diameter > implementation receiving a command with a new mandatory AVP is not required > to process the message in any way. It MAY send an error with error code 5001, > but is not required to. Additionally, if more than one unsupported mandatory AVP > is sent, Section 7 says: > > The Result-Code AVP describes the error that the Diameter node > encountered in its processing. In case there are multiple errors, > the Diameter node MUST report only the first error it encountered > (detected possibly in some implementation dependent order). > > Therefore, it is problematic to add mandatory AVPs to existing implementations > and it is the intent of the Diameter Base Specification to require a new Application > in instances when new mandatory AVPs are required. I believe that John is correct here. We had a very long discussion about this issue before RFC 3588 was approved as an RFC. By requiring a new application Id if new mandatory AVPs are added, Diameter ensures interoperability. Any peer that advertises an application Id can support that application. This is important not only to Diameter clients and servers, but also to intermediaries, since the CER/CEA is built on application advertisements. That said, it *is* possible to add non-mandatory AVPs without changing the Application Id. And I think there may be some confusion about the meaning of "non-mandatory". This simply means that if you don't understand the AVP you can ignore it. It is still possible for other peer to change their behavior based on support of the AVP -- but they can't *require* it. So I believe that in theory, "sub-versioning" based on a non-mandatory AVP is legal within Diameter. Whether this is a good idea is another matter. From owner-aaa-wg@merit.edu Tue May 4 12:17:08 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 MAA10829 for ; Tue, 4 May 2004 12:17:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 84D329129C; Tue, 4 May 2004 12:16:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C1109129D; Tue, 4 May 2004 12:16: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 04F209129C for ; Tue, 4 May 2004 12:16:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E6B8558CAB; Tue, 4 May 2004 12:16:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h007.c000.snv.cp.net [209.228.32.71]) by segue.merit.edu (Postfix) with SMTP id 46D8B58CB3 for ; Tue, 4 May 2004 12:16:55 -0400 (EDT) Received: (cpmta 20228 invoked from network); 4 May 2004 09:16:53 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 4 May 2004 09:16:53 -0700 X-Sent: 4 May 2004 16:16:53 GMT Message-Id: <5.2.1.1.2.20040504104330.03fedc30@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Tue, 04 May 2004 12:16:17 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG In-Reply-To: <409774E4.7010006@alcatel.be> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 5/4/2004 12:48 PM +0200, johan.rh.hermans@alcatel.be wrote: >Mark Jones wrote: > >>I have a comment on the following section (2.2) in nasreq-15: >> >> If accounting is active, every change of authentication or >> authorization SHOULD generate an accounting message. If the NAS >> service is a continuation of the prior user context, then an >> Accounting-Record-Type of INTERIM_RECORD indicating the new session >> attributes and cumulative status would be appropriate. If a new user >> or a significant change in authorization is detected by the NAS, then >> the service may consider it appropriate to send two messages of the >> types STOP_RECORD, and START_RECORD. >> >>In the re-authorization case, I am not comfortable with letting the NAS >>implementor deciding what constitutes a "significant change". The >>re-authorization request is used to trigger events of significant billing >>interest so predictable behavior across vendors is critical. I think >>interoperability would be better served by a more explicit requirement on >>the NAS. Two possible solutions come to mind: Well, in the old stateless days of RADIUS, the server may know almost nothing. In many cases the server doesn't really authenticate or authorize, it delegates that problem by checking a static database. Still, in Diameter, the NAS really is the only one that is required to operationally have the current context of the session, as servers may fail and transition. But this raises some points worth discussing: - Why does a session do re-authentication/re-authorization? a) to reaffirm that the same user is still on the line b) to re-spin the user's keys for better security c) to re-authorize the user's continued service (policy only allows x sized chunks) d) to authorize more service for the user (secondary authorization has been approved) d) to authorize a different service for the same user (service provides multiple types of service) - When does re-authentication/re-authorization happen? a) by Authorization-Lifetime timeout b) by spontaneous Server request (RAR message) c) by spontaneous NAS request (underlying auth mechanism like CHAP or 802.1x) What's the difference between a Re-Auth and a new call? - there's an open connection context on the NAS port resources with state and prior user information and possible encryption keys - there's an open resource context in the Server (and potential stateful proxy servers) These resources have to re-allocated (sessions closed with STR) - We used the same Session-ID in the Re-Auth AAR message. How can we tell that it's not the same call? - different user identification? Is there a requirement for this? maybe - different user credentials? (straw man - these may not be visible at the NAS, and may be purposely different to prevent replay and MtM attacks) - auth fails! - end of story or do we allow retries? ;^) - Server says so!? The only technical addition I think we may need here. Perhaps we need an AVP for the server to say, START_OVER. Note that the Session-Id got re-used in the AAR. It's possible to make a case that if the user presents a different user identity to the NAS, that we should NOT treat this as a re-auth, but a new session call. This would catch the issues of services that cannot detect port cycling. >>EITHER >> >>(1) If the re-authorization results in a change to any of the service >>parameters, the NAS MUST treat this as a new session and send two messages >>(Stop/Start). "any" is too broad a term to leverage a MUST here. A typical auth upgrade scenario is the addition of more parameters. >>OR >> >>(2) The AAA server MUST specify whether the Stop/Start is required at the >>time it requests the re-authorization. If the AAA server does not request a >>Stop/Start at re-authorization, the NAS MUST NOT send any accounting >>messages for this event. Like the other correspondent notes (below), and I have noted previously... Why are you trying to stop my application from sending Accounting messages? Perhaps _I_ need those messages. >>I have a preference for (2) since it eliminates redundant accounting >>messages in those cases where the service provider is not dependent on the >>Stop/Start messages to bill for the service change triggered by >>re-authorization. Billing models are provider dependent. If I have a different policy, I may NEED those messages. So why are you trying to dictate your policies to my NAS implementation code? If a given back-end billing model believes that certain NAS Accounting messages are irrelevant, it can discard them at some stage of the collection and collation processing. It also possible to provide managed NAS behavior. The messages could be optioned off by NAS management, if not needed in a given configuration. This protocol covers a host of services, not just yours. >>Regards >>Mark >> >Then what do we do with current BRAS'es (Redback SMC and Redback SE800 for >example) that already send an Accounting-Update packet when an >reauthorization happens ? I know that's in RADIUS, but DIAMETER should >still be backwards compatible. Your MUST NOT will prevent us from proxying >those events. > >-- >Jo Hermans The only way we are going to achieve consensus on this specification is to stop trying to disallow practices already out there. The protocol should provide a framework that reports changes and events in service. How those services are billed is configuration dependent. How these services MAY be billed is more relevant. The protocol should be flexible enough to ALLOW for predicable and common practice. It should be specific enough that NAS and Server vendors can build interoperable products. Now, for the fans of micro-sub-sessions that STOP/START all the time, the current text allows for that. It seems that Section 9.6 of RFC 3588 even allows that the Session-Id of Accounting messages doesn't have to be the same as the Auth messages. (kind of bizarre, but there it is) So I think the only issue to address is a bit of confusion over how we detect changes in user context (at both the NAS and Server) with respect to an established session (Note that a session is defined around authenticated user call context) as to prevent any injection attacks. Dave. From owner-aaa-wg@merit.edu Tue May 4 15:36: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 PAA24501 for ; Tue, 4 May 2004 15:36:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F09F4912AD; Tue, 4 May 2004 15:35:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDF9C912B0; Tue, 4 May 2004 15:35: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 93C84912AD for ; Tue, 4 May 2004 15:35:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B40258E31; Tue, 4 May 2004 15:35:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 2F34358D82 for ; Tue, 4 May 2004 15:35:55 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 May 2004 15:35:54 -0400 Message-ID: From: Mark Jones To: "'johan.rh.hermans@alcatel.be'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Tue, 4 May 2004 15:35:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > Then what do we do with current BRAS'es (Redback SMC and > Redback SE800 > for example) that already send an Accounting-Update packet when an > reauthorization happens ? I know that's in RADIUS, but > DIAMETER should > still be backwards compatible. So because this behavior is vendor-specific in RADIUS, we must leave it as vendor-specific going forward? > Your MUST NOT will prevent us from proxying those events. Given the backwards compatibility issue, I concede that the MUST NOT is too strict here. However, as nasreq-15 is currently worded, your proxy target would have to deal with those events expressed as Interims or Stop/Start depending on each NAS implementors interpretation of 'significant change'. Mark From owner-aaa-wg@merit.edu Tue May 4 16:56: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 QAA28820 for ; Tue, 4 May 2004 16:56:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 86EEC912C9; Tue, 4 May 2004 16:55:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A3DE912C6; Tue, 4 May 2004 16:55:53 -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 C9AB1912C1 for ; Tue, 4 May 2004 16:55:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9720258F6A; Tue, 4 May 2004 16:55:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 0DDAF58EDF for ; Tue, 4 May 2004 16:55:46 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 May 2004 16:55:45 -0400 Message-ID: From: Mark Jones To: "'David Mitton'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Tue, 4 May 2004 16:55:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > >>(1) If the re-authorization results in a change to any of > the service > >>parameters, the NAS MUST treat this as a new session and send two > >>messages (Stop/Start). > > "any" is too broad a term to leverage a MUST here. Would a SHOULD be acceptable here instead? > A typical auth upgrade > scenario is the addition of more parameters. > Replace is the most common scenario I've encountered in RADIUS up to now but I agree the text should also cover addition and deletion. > Billing models are provider dependent. If I have a > different policy, I > may NEED those messages. So why are you trying to dictate > your policies to > my NAS implementation code? > If a provider NEEDS stop/start messages, it should not be left to the NAS implementor to decide whether the re-authorization change is significant enough to warrant the sending of those messages. > > It also possible to provide managed NAS behavior. The > messages could be > optioned off by NAS management, if not needed in a given > configuration. And this configuration option would control whether Interim or Stop/Start messages were sent on re-authorization. Correct? On a related note, I assume the sending of an Interim for a re-authorization event causes the Acct-Interim-Interval timer to be reset. Would stating this in the draft break any existing implementations? > This protocol covers a host of services, not just yours. That is a strange rebuke for pointing out an ambiguity in a draft and suggesting text. I have no idea what you could have inferred as being _my_ service. Mark From owner-aaa-wg@merit.edu Wed May 5 01:05: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 BAA22846 for ; Wed, 5 May 2004 01:05:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCCAA91208; Wed, 5 May 2004 01:05:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A66B3912C6; Wed, 5 May 2004 01:05: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 6DB2191208 for ; Wed, 5 May 2004 01:05:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51C8C58E68; Wed, 5 May 2004 01:05:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h001.c000.snv.cp.net [209.228.32.65]) by segue.merit.edu (Postfix) with SMTP id 95FE058DD1 for ; Wed, 5 May 2004 01:05:11 -0400 (EDT) Received: (cpmta 23675 invoked from network); 4 May 2004 22:05:10 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.65) with SMTP; 4 May 2004 22:05:10 -0700 X-Sent: 5 May 2004 05:05:10 GMT Message-Id: <5.2.1.1.2.20040505003554.044336f0@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 05 May 2004 00:56:05 -0400 To: Mark Jones From: David Mitton Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Cc: "'aaa-wg@merit.edu'" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk On 5/4/2004 04:55 PM -0400, Mark Jones wrote: > > >>(1) If the re-authorization results in a change to any of > > the service > > >>parameters, the NAS MUST treat this as a new session and send two > > >>messages (Stop/Start). > > > > "any" is too broad a term to leverage a MUST here. > >Would a SHOULD be acceptable here instead? Perhaps, but there does seem to be some abiguity as to what constitutes a new session. > > A typical auth upgrade > > scenario is the addition of more parameters. > > > >Replace is the most common scenario I've encountered in RADIUS up to now but >I agree the text should also cover addition and deletion. > > > Billing models are provider dependent. If I have a > > different policy, I > > may NEED those messages. So why are you trying to dictate > > your policies to > > my NAS implementation code? > > > >If a provider NEEDS stop/start messages, it should not be left to the NAS >implementor to decide whether the re-authorization change is significant >enough to warrant the sending of those messages. Well, these things actually tend to go hand-in-hand. ISPs know how their NAS's work and either code around them or get them changed to suit. The whole situation should be predictable. The provider knows what they're changing, why, and how the NAS implmentation would respond to that. It might be interesting to try to figure out what we're talking about by creating some reasonable specific scenarios. > > > > It also possible to provide managed NAS behavior. The > > messages could be > > optioned off by NAS management, if not needed in a given > > configuration. > >And this configuration option would control whether Interim or Stop/Start >messages were sent on re-authorization. Correct? that's certainly in the realm of possible. >On a related note, I assume the sending of an Interim for a re-authorization >event causes the Acct-Interim-Interval timer to be reset. Would stating >this in the draft break any existing implementations? I doubt it, but the question is worth asking. > > This protocol covers a host of services, not just yours. > >That is a strange rebuke for pointing out an ambiguity in a draft and >suggesting text. I have no idea what you could have inferred as being _my_ >service. I'm sorry, but I personalized the discussion a little, by I'm responding to an abstracted a service with requirements that come from your suggested behaviors. It seems you (and your colleague) may have a specific service in mind. And your collective commentary keeps poking at this text in a consistent direction. Likewise, I don't really have a specific service I provide this minute. But I have done ones in the past that work in a manner consistent with my discussion. That is, are long lasting, with changes in service and emit lots of Vendor specific accounting event messages under optional control, among other things. Probably not the most popular RADIUS service in the world, but I don't think it's model should be outlawed. Dave. From owner-aaa-wg@merit.edu Wed May 5 06:26: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 GAA05088 for ; Wed, 5 May 2004 06:26:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A778691235; Wed, 5 May 2004 06:26:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7101591252; Wed, 5 May 2004 06:26: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 4080B91235 for ; Wed, 5 May 2004 06:26:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2975A58F29; Wed, 5 May 2004 06:26:20 -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 66ACB58F24 for ; Wed, 5 May 2004 06:26:19 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D584A8983D; Wed, 5 May 2004 13:26:02 +0300 (EEST) Message-ID: <4098C075.50008@kolumbus.fi> Date: Wed, 05 May 2004 13:22:45 +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: Christopher Richards Cc: marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs References: <161AA64DA85DFC4BA4D2EB5629B59753069F6CE0@zrc2c012.us.nortel.com> In-Reply-To: <161AA64DA85DFC4BA4D2EB5629B59753069F6CE0@zrc2c012.us.nortel.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 works for me. --Jari Christopher Richards wrote: > Hi Marco, > > Thanks for the clarification. > > Since it is not terribly clear that other Diameter applications should > follow the NASREQ specification when encoding RADIUS vendor specific > AVPs, I think it would be beneficial if some statement was added to DCC > section 8. E.g. > > When including RADIUS vendor specific attributes in a DCC message, the > rules described in [NASREQ] for formatting the Diameter AVP MUST be > followed. For example, the AVP code used is the vendor attribute type > code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST > be set to the IANA Vendor identification value. The Diameter AVP data > field contains only the attribute value of the RADIUS attribute. > > I think it will save confusion in the future. > > Cheers, > Chris. > > > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Tuesday, May 04, 2004 3:53 AM > To: Richards, Christopher [RICH2:2Q40:EXCH] > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > Hi Chris, > > >It's not just for translating AVPs on the fly, but also for how to > >re-use existing RADIUS > >VSA AVPs. > >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, > that I now want to > >use in Diameter. I want avoid having to completely redefine it. > >From my reading of RFC3588, it says something along the lines that all > AVP codes 0 to 255 > >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP > code 26 was included. > >As an example, if you have access to 3GPP TS 29.061, take a look at > the RADIUS VSAs defined >for 3GPP. > > >When I want to put this information into a Diameter AVP, do I set the > >Vendor-ID flag or not? > > as Dave pointed out the NASREQ is intended to be the generic RADIUS > replacement within Diameter. If you just use the NASREQ defined AVPs, > that practically uses those AVP numbers from 1 through 255 you're > talking about, you should be able to match the 3GPP TS 29.061 needs. > > For those 3gpp vendor-specific attributes defined in TS 29.061 I think > you should follow the rules defined in NASREQ section 9.6.2, RADIUS > Interactions. According to the mentioned rules the V bit is to be set. > > I copied here sect. 9.4 of the NASREQ draft, that clearly state that > attribute code 26 must not appear in Diameter messages. > > Regards > Marco > > 9.4 Prohibited RADIUS Attributes > > The following RADIUS attributes MUST NOT appear in a Diameter > message. Instead, they are translated to other Diameter AVPs or > handled in some special manner. The rules for the treatment of the > attributes are discussed in Sections 9.1, 9.2 and 9.6. > > > Attribute Description Defined Nearest Diameter AVP > ----------------------------------------------------------------- > 3 CHAP-Password RFC 2865 CHAP-Auth Group > 26 Vendor-Specific RFC 2865 Vendor Specific AVP > 29 Termination-Action RFC 2865 Authorization-Lifetime > 40 Acct-Status-Type RFC 2866 Accounting-Record-Type > 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets > 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets > 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets > 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets > 49 Acct-Terminate-Cause RFC 2866 Termination-Cause > 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets > 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets > 80 Message-Authenticator RFC 2869 none - check and discard > From owner-aaa-wg@merit.edu Wed May 5 12:14: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 MAA23108 for ; Wed, 5 May 2004 12:14:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 303169120F; Wed, 5 May 2004 12:13:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFEE591211; Wed, 5 May 2004 12:13: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 BB5169120F for ; Wed, 5 May 2004 12:13:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A79EA58F13; Wed, 5 May 2004 12:13:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 5236858F80 for ; Wed, 5 May 2004 12:13:55 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 May 2004 12:13:54 -0400 Message-ID: From: Avi Lior To: "'David Mitton'" , Mark Jones Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Wed, 5 May 2004 12:13:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk David, Mark, I understand that we want to make progress here. Perhaps some of this issues would be best dealt with in 3576 bis -- if we have one. My view and 3588's view of interim records are that they are "typically implemented in order to provide for partial accounting of a user's session in the case of a device reboot or other network problems". That is the rule and not the exception. The problem with the text in NASREQ and it's use of interims is that we are making the exception the rule. IMO it aught to be the other way round. We should be generating Stops - Starts and in certain cases use Interim records. The may in that par should be changed to a SHOULD. With respect to letting the NAS decide (Which I understood was Mark's principal objection). While this has worked in the past it is a huge concern. Especially when we are faced with roaming situations where we don't have direct relationships with the NASes. The home network's responsibility is to generate the Bill and we really can't have some NAS at the Roach Hotel dictate to us. The tail should not wag that dog. While I don't know how to solve this I do know that the existing text is not going to help. With respect to when a new session starts. If we need a guideline (and it would certainly help) then perhaps we can suggest that any change is session attribute should be considered a change in session. Application writers could refine this definition. With respect to getting a different user authenticatign during a re-auth. IMO the only thing you do there is turf the session. You should provide a guideline in the document and perhaps couch it in a SHOULD (although I think it should be a MUST). I know you want to get this thing off you back. Avi > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] > Sent: Wednesday, May 05, 2004 12:56 AM > To: Mark Jones > Cc: 'aaa-wg@merit.edu' > Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go > to the IESG > > > On 5/4/2004 04:55 PM -0400, Mark Jones wrote: > > > >>(1) If the re-authorization results in a change to any of > > > the service > > > >>parameters, the NAS MUST treat this as a new session > and send two > > > >>messages (Stop/Start). > > > > > > "any" is too broad a term to leverage a MUST here. > > > >Would a SHOULD be acceptable here instead? > > Perhaps, but there does seem to be some abiguity as to what > constitutes a > new session. > > > > > A typical auth upgrade > > > scenario is the addition of more parameters. > > > > > > >Replace is the most common scenario I've encountered in RADIUS up to > >now but I agree the text should also cover addition and deletion. > > > > > Billing models are provider dependent. If I have a > > > different policy, I > > > may NEED those messages. So why are you trying to dictate your > > > policies to my NAS implementation code? > > > > > > >If a provider NEEDS stop/start messages, it should not be > left to the > >NAS implementor to decide whether the re-authorization change is > >significant enough to warrant the sending of those messages. > > Well, these things actually tend to go hand-in-hand. ISPs > know how their > NAS's work and either code around them or get them changed to > suit. The > whole situation should be predictable. The provider knows > what they're > changing, why, and how the NAS implmentation would respond to that. > > It might be interesting to try to figure out what we're > talking about by > creating some reasonable specific scenarios. > > > > > > > > It also possible to provide managed NAS behavior. The messages > > > could be optioned off by NAS management, if not needed in a given > > > configuration. > > > >And this configuration option would control whether Interim or > >Stop/Start messages were sent on re-authorization. Correct? > > that's certainly in the realm of possible. > > > >On a related note, I assume the sending of an Interim for a > >re-authorization event causes the Acct-Interim-Interval timer to be > >reset. Would stating this in the draft break any existing > >implementations? > > I doubt it, but the question is worth asking. > > > > > This protocol covers a host of services, not just yours. > > > >That is a strange rebuke for pointing out an ambiguity in a > draft and > >suggesting text. I have no idea what you could have inferred > as being > >_my_ service. > > I'm sorry, but I personalized the discussion a little, by I'm > responding to > an abstracted a service with requirements that come from your > suggested > behaviors. It seems you (and your colleague) may have a > specific service > in mind. And your collective commentary keeps poking at this > text in a > consistent direction. > > Likewise, I don't really have a specific service I provide this > minute. But I have done ones in the past that work in a > manner consistent > with my discussion. > That is, are long lasting, with changes in service and emit > lots of Vendor > specific accounting event messages under optional control, > among other things. Probably not the most popular RADIUS > service in the world, but I don't > think it's model should be outlawed. > > Dave. > > From owner-aaa-wg@merit.edu Wed May 5 12:39: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 MAA24719 for ; Wed, 5 May 2004 12:39:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5237A91213; Wed, 5 May 2004 12:39:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DD0A91216; Wed, 5 May 2004 12:39: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 F3ADF91213 for ; Wed, 5 May 2004 12:39:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9DFC58F2B; Wed, 5 May 2004 12:39:17 -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 0793458E0E for ; Wed, 5 May 2004 12:39:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i45Ghh225503; Wed, 5 May 2004 09:43:43 -0700 Date: Wed, 5 May 2004 09:43:43 -0700 (PDT) From: Bernard Aboba To: david@mitton.com Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG 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 > I understand that we want to make progress here. Perhaps some of this > issues would be best dealt with in 3576 bis -- if we have one. I don't think this is just a 3576bis issue, unfortunately. There is some somewhat vague text in RFC 3580 that appears to require the NAS to make a judgement on whether authorizations have changed sufficiently to justify sending an accounting STOP/Start, but doesn't provide guidance on the Service-Type, whether is is "Authenticate Only" or not. And then we have the NASREQ document. So I think this is a somewhat bigger discussion. > My view and 3588's view of interim records are that they are "typically > implemented in order to provide for partial accounting of a user's session > in the case of a device reboot or other network problems". That is the rule > and not the exception. OK. > The problem with the text in NASREQ and it's use of interims is that we are > making the exception the rule. IMO it aught to be the other way round. We > should be generating Stops - Starts and in certain cases use Interim > records. The may in that par should be changed to a SHOULD. > > With respect to letting the NAS decide (Which I understood was Mark's > principal objection). While this has worked in the past it is a huge > concern. Especially when we are faced with roaming situations where we > don't have direct relationships with the NASes. The home network's > responsibility is to generate the Bill and we really can't have some NAS at > the Roach Hotel dictate to us. The tail should not wag that dog. While I > don't know how to solve this I do know that the existing text is not going > to help. I agree in principle. However, I'm not sure at this point what range of practices are implemented -- and therefore what the "state of the art" is. As David mentioned, we need to be careful about outlawing common practice. > With respect to when a new session starts. If we need a guideline (and it > would certainly help) then perhaps we can suggest that any change is session > attribute should be considered a change in session. Application writers > could refine this definition. The usage of Service-Type="Authenticate Only" seems to indicate that changes in authentication-related attributes (such as keys or EAP Types) do not constitute a change in authorization. However, Paul Funk has made an argument that some implementations may use an Accounting START to confirm that the session in fact started -- and may assume that it did not start if they don't receive it. Some questions: a. Is it possible to send another Accounting START with the same Session-Id? Or must the Session-Id always change for each START? b. Is it useful to make a distinction between Service-Type= "Authenticate Only" and other Service-Types? > With respect to getting a different user authenticatign during a re-auth. > IMO the only thing you do there is turf the session. You should provide a > guideline in the document and perhaps couch it in a SHOULD (although I think > it should be a MUST). > > I know you want to get this thing off you back. We all do. But at the same time, I don't want to make a mess we'll have to clean up later. It seems like we already have a problem on our hands that may be difficult to address (since we have lots of implementations in the field). From owner-aaa-wg@merit.edu Thu May 6 03:45:30 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 DAA24675 for ; Thu, 6 May 2004 03:45:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 675B49121E; Thu, 6 May 2004 03:45:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D975E912C4; Thu, 6 May 2004 03:45: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 833099121E for ; Thu, 6 May 2004 03:45:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 669765900E; Thu, 6 May 2004 03:45:00 -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 86ABD5901F for ; Thu, 6 May 2004 03:44:59 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i467ivH11194 for ; Thu, 6 May 2004 10:44:58 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 10:43:19 +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 i467hJiG003677 for ; Thu, 6 May 2004 10:43:19 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00nT1Z4y; Thu, 06 May 2004 10:43:08 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i467gtH22243 for ; Thu, 6 May 2004 10:42:55 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 10:42:55 +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]: IETF 60 Date: Thu, 6 May 2004 10:42:55 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Thread-Index: AcQyXrpROCerbrzhRU+2hE8G/4RHOQA3scpA From: To: X-OriginalArrivalTime: 06 May 2004 07:42:55.0326 (UTC) FILETIME=[BE60E7E0:01C4333D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, The scheduling for IETF 60 has opened. We are close to finishing off = the current charter items. My feeling is that we may not need to schedule a AAA WG = meeting at IETF 60. However, if anyone has opinions on this, please speak up. thanks, John From owner-aaa-wg@merit.edu Thu May 6 07:32: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 HAA06829 for ; Thu, 6 May 2004 07:32:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 156BB912D3; Thu, 6 May 2004 07:31:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4B46912D5; Thu, 6 May 2004 07:31: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 A8ADF912D3 for ; Thu, 6 May 2004 07:31:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9730558FB1; Thu, 6 May 2004 07:31:51 -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 814D158F93 for ; Thu, 6 May 2004 07:31:50 -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 i46BVm0O009511 for ; Thu, 6 May 2004 13:31:48 +0200 Received: from [138.203.209.107] ([138.203.209.107]) by bemail03.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2004050613314829:2794 ; Thu, 6 May 2004 13:31:48 +0200 Message-ID: <409A2222.3000708@alcatel.be> Date: Thu, 06 May 2004 13:31:46 +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 05/06/2004 13:31:48, Serialize by Router on BEMAIL03/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/06/2004 13:31:48, Serialize complete at 05/06/2004 13:31:48 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 Thu May 6 10:45:00 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 KAA17594 for ; Thu, 6 May 2004 10:45:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 61ED8912E6; Thu, 6 May 2004 10:43:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88D7C912E8; Thu, 6 May 2004 10:43: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 944C4912E6 for ; Thu, 6 May 2004 10:43:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E0BD5903D; Thu, 6 May 2004 10:43:14 -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 9008A5904B for ; Thu, 6 May 2004 10:43:13 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i46Eh9B18961; Thu, 6 May 2004 17:43:09 +0300 (EET DST) X-Scanned: Thu, 6 May 2004 17:42:19 +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 i46EgJbr024193; Thu, 6 May 2004 17:42:19 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00wxbnwu; Thu, 06 May 2004 17:42:18 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 i46Eg8H17287; Thu, 6 May 2004 17:42:08 +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); Thu, 6 May 2004 17:42:08 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 6 May 2004 17:42:07 +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]: Issue eap : Key Name AVP Date: Thu, 6 May 2004 17:42:08 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61223F2@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue eap : Key Name AVP Thread-Index: AcQoeSa3OUiu0JTgSN2t+YDOaBXRLwK/f4Yg From: To: , Cc: X-OriginalArrivalTime: 06 May 2004 14:42:07.0676 (UTC) FILETIME=[4E58EFC0:01C43378] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Ok, does this look ok? - Add a new section: 4.1.4 EAP-Key-Name AVP The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. It contains an opaque key identifier (name) generated by the EAP method. Exactly how this name is used depends on the link layer in question, and is beyond the scope of this document (see [EAPKey] for more discussion). It should be noted that not all link layers use this name, and currently most EAP methods do not generate it. The home Diameter server SHOULD include this AVP in Diameter-EAP-Response only if a (possibly empty) EAP-Key-Name AVP was present in Diameter-EAP-Request. - Add this to IANA considerations: o This document defines one new AVP (attribute) whose AVP Code (Attribute Type) is to be allocated from the Attribute Type namespace defined in [RFC2865] and [RFC3575]. This AVP (EAP-Key-Name) is defined in Section 4.1.4. - Update AVP occurrence tables and ABNFs. BR, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Bernard Aboba > Sent: Thursday, April 22, 2004 5:49 PM > To: Jari Arkko > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue eap : Key Name AVP >=20 >=20 >=20 > > You are right. I guess my question at this point is whether > > Diameter EAP needs to allocate the name AVP from the Diameter > > or RADIUS space. It seems like it should be allocated from > > the RADIUS space, so that translation the "compatible RADIUS > > server" has a standard attribute to use on the RADIUS side. > > > > If you and others agree, I think this results in the following > > modifications of Diameter EAP: > > > > 1. Add a key name AVP section > > 2. Make it appear 0-1 times in both the request and response. > > 3. Explain that the server should return the AVP in response > > if it was present in the request. > > 4. Explain that the contents come from EAP methods (add > > informative reference to EAP keying). > > 5. Use a RADIUS number space for the attribute number. >=20 > Yes, I think this will work. >=20 From owner-aaa-wg@merit.edu Thu May 6 11:01: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 LAA18606 for ; Thu, 6 May 2004 11:01:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15B32912D4; Thu, 6 May 2004 11:01:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB0BC912DA; Thu, 6 May 2004 11:01: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 CD362912D4 for ; Thu, 6 May 2004 11:01:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9A4B59006; Thu, 6 May 2004 11:01:32 -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 4833A59000 for ; Thu, 6 May 2004 11:01:32 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 99A6A8983E; Thu, 6 May 2004 18:01:25 +0300 (EEST) Message-ID: <409A527F.8000304@kolumbus.fi> Date: Thu, 06 May 2004 17:58:07 +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]: Issue eap : Key Name AVP References: <052E0C61B69C3741AFA5FE88ACC775A61223F2@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223F2@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 Pasi.Eronen@nokia.com wrote: > Ok, does this look ok? > > - Add a new section: > > 4.1.4 EAP-Key-Name AVP > > The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. > It contains an opaque key identifier (name) generated by the EAP > method. Exactly how this name is used depends on the link layer in > question, and is beyond the scope of this document (see [EAPKey] for > more discussion). > > It should be noted that not all link layers use this name, and > currently most EAP methods do not generate it. The home Diameter > server SHOULD include this AVP in Diameter-EAP-Response only if a > (possibly empty) EAP-Key-Name AVP was present in > Diameter-EAP-Request. Ok otherwise, but how about s/a (possibly empty)/an empty/? That way NAS implementations don't have to guess whether they should send some actual information in the request. --Jari From owner-aaa-wg@merit.edu Fri May 7 03:47:54 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 DAA03052 for ; Fri, 7 May 2004 03:47:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F04F912FB; Fri, 7 May 2004 03:47:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE483912FD; Fri, 7 May 2004 03:47:41 -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 201EF912FB for ; Fri, 7 May 2004 03:47:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 047DF59095; Fri, 7 May 2004 03:47:40 -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 7E188590B7 for ; Fri, 7 May 2004 03:47:34 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i477lVB03668; Fri, 7 May 2004 10:47:31 +0300 (EET DST) X-Scanned: Fri, 7 May 2004 10:46:46 +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 i477kkNg006659; Fri, 7 May 2004 10:46:46 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00xVswnq; Fri, 07 May 2004 10:46:44 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 i477khH07460; Fri, 7 May 2004 10:46:43 +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); Fri, 7 May 2004 10:46:37 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 7 May 2004 10:46:37 +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_01C43407.6C81A37D" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 7 May 2004 10:46:36 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0537@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcQx55WlKHiESk2ITgWmbjGFAlP6KACHqesA From: To: Cc: , , X-OriginalArrivalTime: 07 May 2004 07:46:37.0239 (UTC) FILETIME=[6D0FE470:01C43407] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C43407.6C81A37D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris, =20 Since it is not terribly clear that other Diameter applications should = follow the NASREQ specification when encoding RADIUS vendor specific = AVPs, I think it would be beneficial if some statement was added to DCC = section 8. E.g. =20 When including RADIUS vendor specific attributes in a DCC message, the = rules described in [NASREQ] for formatting the Diameter AVP MUST be = followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST = be set to the IANA Vendor identification value. The Diameter AVP data = field contains only the attribute value of the RADIUS attribute. =20 I better see this kind of text in section 4.1, perhaps slightly modified = as follow: =20 When service specific documents include RADIUS vendor specific = attributes in a DCC message, the rules described in [NASREQ] = ..........etc. =20 Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco,=20 Thanks for the clarification.=20 Since it is not terribly clear that other Diameter applications should = follow the NASREQ specification when encoding RADIUS vendor specific = AVPs, I think it would be beneficial if some statement was added to DCC = section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the = rules described in [NASREQ] for formatting the Diameter AVP MUST be = followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST = be set to the IANA Vendor identification value. The Diameter AVP data = field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Tuesday, May 04, 2004 3:53 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi=20 Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs=20 Hi Chris,=20 >It's not just for translating AVPs on the fly, but also for how to=20 >re-use existing RADIUS=20 >VSA AVPs.=20 >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, = that I now want to=20 >use in Diameter. I want avoid having to completely redefine it.=20 >From my reading of RFC3588, it says something along the lines that all = AVP codes 0 to 255=20 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP = code 26 was included.=20 >As an example, if you have access to 3GPP TS 29.061, take a look at the = RADIUS VSAs defined >for 3GPP.=20 >When I want to put this information into a Diameter AVP, do I set the=20 >Vendor-ID flag or not?=20 as Dave pointed out the NASREQ is intended to be the generic RADIUS = replacement within Diameter. If you just use the NASREQ defined AVPs, = that practically uses those AVP numbers from 1 through 255 you're = talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think = you should follow the rules defined in NASREQ section 9.6.2, RADIUS = Interactions. According to the mentioned rules the V bit is to be set.=20 I copied here sect. 9.4 of the NASREQ draft, that clearly state that = attribute code 26 must not appear in Diameter messages. Regards=20 Marco=20 9.4 Prohibited RADIUS Attributes=20 The following RADIUS attributes MUST NOT appear in a Diameter=20 message. Instead, they are translated to other Diameter AVPs or=20 handled in some special manner. The rules for the treatment of the=20 attributes are discussed in Sections 9.1, 9.2 and 9.6.=20 Attribute Description Defined Nearest Diameter AVP=20 -----------------------------------------------------------------=20 3 CHAP-Password RFC 2865 CHAP-Auth Group=20 26 Vendor-Specific RFC 2865 Vendor Specific AVP=20 29 Termination-Action RFC 2865 Authorization-Lifetime=20 40 Acct-Status-Type RFC 2866 Accounting-Record-Type=20 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets=20 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets=20 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets=20 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets=20 49 Acct-Terminate-Cause RFC 2866 Termination-Cause=20 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets=20 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets=20 80 Message-Authenticator RFC 2869 none - check and discard=20 ------_=_NextPart_001_01C43407.6C81A37D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi=20 Chris,
 
Since it is not = terribly clear=20 that other Diameter applications should follow the NASREQ specification = when=20 encoding RADIUS vendor specific AVPs, I think it would be beneficial if = some=20 statement was added to DCC section 8. E.g.
 
When including = RADIUS vendor=20 specific attributes in a DCC message, the rules described in [NASREQ] = for=20 formatting the Diameter AVP MUST be followed. For example, the AVP code = used is=20 the vendor attribute type code, the Vendor-Specific flag MUST be set to = 1 and=20 the Vendor-ID MUST be set to the IANA Vendor identification value. The = Diameter=20 AVP data field contains only the attribute value of the RADIUS=20 attribute.
 
I=20 better see this kind of text in section 4.1, perhaps slightly modified = as=20 follow:
 
When=20 service specific documents include RADIUS vendor specific attributes in = a DCC=20 message, the rules described in [NASREQ] = ..........etc.
 
Regards
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004=20 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc:=20 david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi
Subject:=20 RE: [AAA-WG]: Diameter encoding of RADIUS VSA = AVPs

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter=20 applications should follow the NASREQ specification when encoding = RADIUS=20 vendor specific AVPs, I think it would be beneficial if some statement = was=20 added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in = a DCC=20 message, the rules described in [NASREQ] for formatting the Diameter = AVP MUST=20 be followed. For example, the AVP code used is the vendor attribute = type code,=20 the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be = set to the=20 IANA Vendor identification value. The Diameter AVP data field contains = only=20 the attribute value of the RADIUS attribute.

I think it will save confusion in the future. =

Cheers,
Chris. =


-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Tuesday, May 04, 2004 3:53 AM =
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc:=20 david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi =
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA = AVPs=20


Hi Chris,

>It's not just for translating AVPs on the fly, = but also=20 for how to
>re-use existing RADIUS =
>VSA AVPs.
>I currently have = a RADIUS VSA=20 AVP - a VSA that was defined for RADIUS, that I now want to =
>use in Diameter. I want avoid having to completely = redefine=20 it.
>From my reading of RFC3588, it says = something=20 along the lines that all AVP codes 0 to 255
>are=20 reserved for RADIUS AVPs. From this I also took that RADIUS AVP code = 26 was=20 included.
>As an example, if you have = access to=20 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.=20

>When I want to put this information into a = Diameter AVP,=20 do I set the
>Vendor-ID flag or = not?

as Dave pointed out the NASREQ is intended to be the = generic=20 RADIUS replacement within Diameter. If you just use the NASREQ defined = AVPs,=20 that practically uses those AVP numbers from 1 through 255 you're = talking=20 about, you should be able to match the 3GPP TS 29.061 = needs.

For those 3gpp vendor-specific attributes defined in = TS 29.061=20 I think you should follow the rules defined in NASREQ section 9.6.2, = RADIUS=20 Interactions. According to the mentioned rules the V bit is to be set. =

I copied here sect. 9.4 of the NASREQ draft, that = clearly=20 state that attribute code 26 must not appear in Diameter = messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST = NOT appear=20 in a Diameter
   message.  = Instead,=20 they are translated to other Diameter AVPs or
   handled in some special manner. The rules for = the=20 treatment of the
   attributes are = discussed=20 in Sections 9.1, 9.2 and 9.6.


   Attribute=20 Description      =20 Defined     Nearest Diameter AVP
  =20 = ----------------------------------------------------------------- =
    3=20 = CHAP-Password          =  =20 RFC 2865    CHAP-Auth Group
   26=20 Vendor-Specific          = RFC=20 2865    Vendor Specific AVP
   29 = Termination-Action      =20 RFC 2865    Authorization-Lifetime
   40=20 Acct-Status-Type         RFC=20 2866    Accounting-Record-Type
   42=20 Acct-Input-Octets        RFC=20 2866    Accounting-Input-Octets
   43 = Acct-Output-Octets      =20 RFC 2866    Accounting-Output-Octets
   47 = Acct-Input-Packets      =20 RFC 2866    Accounting-Input-Packets
   48 = Acct-Output-Packets      RFC=20 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     = RFC=20 2866    Termination-Cause
  =20 52 Acct-Input-Gigawords     RFC = 2869   =20 Accounting-Input-Octets
   53=20 Acct-Output-Gigawords    RFC 2869   =20 Accounting-Output-Octets
   80=20 Message-Authenticator    RFC 2869    = none -=20 check and discard

------_=_NextPart_001_01C43407.6C81A37D-- From owner-aaa-wg@merit.edu Fri May 7 11:15:46 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 LAA00142 for ; Fri, 7 May 2004 11:15:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 52D3291326; Fri, 7 May 2004 11:15:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE17C91327; Fri, 7 May 2004 11:15: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 E4C9891326 for ; Fri, 7 May 2004 11:15:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B9FC558FC6; Fri, 7 May 2004 11:15:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by segue.merit.edu (Postfix) with ESMTP id 0D82258F7B for ; Fri, 7 May 2004 11:15:08 -0400 (EDT) Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i47FF2C1018655; Fri, 7 May 2004 08:15:03 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.217.139]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 7 May 2004 08:21:58 -0700 From: "Joseph Salowey" To: , , Cc: Subject: RE: [AAA-WG]: Issue eap : Key Name AVP Date: Fri, 7 May 2004 08:15:23 -0700 Message-ID: <003001c43446$1fb72d70$0300000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61223F2@esebe023.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-OriginalArrivalTime: 07 May 2004 15:21:58.0653 (UTC) FILETIME=[09E4D2D0:01C43447] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Looks fine to me. owner-aaa-wg@merit.edu wrote: > Ok, does this look ok? > > - Add a new section: > > 4.1.4 EAP-Key-Name AVP > > The EAP-Key-Name AVP (AVP Code TBD-BY-IANA) is of type OctetString. > It contains an opaque key identifier (name) generated by the EAP > method. Exactly how this name is used depends on the link layer in > question, and is beyond the scope of this document (see [EAPKey] > for more discussion). > > It should be noted that not all link layers use this name, and > currently most EAP methods do not generate it. The home Diameter > server SHOULD include this AVP in Diameter-EAP-Response only if a > (possibly empty) EAP-Key-Name AVP was present in > Diameter-EAP-Request. > > - Add this to IANA considerations: > > o This document defines one new AVP (attribute) whose AVP Code > (Attribute Type) is to be allocated from the Attribute Type > namespace defined in [RFC2865] and [RFC3575]. This AVP > (EAP-Key-Name) is defined in Section 4.1.4. > > - Update AVP occurrence tables and ABNFs. > > BR, > Pasi > >> -----Original Message----- >> From: owner-aaa-wg@merit.edu >> [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> ext Bernard Aboba >> Sent: Thursday, April 22, 2004 5:49 PM >> To: Jari Arkko >> Cc: aaa-wg@merit.edu >> Subject: Re: [AAA-WG]: Issue eap : Key Name AVP >> >> >> >>> You are right. I guess my question at this point is whether Diameter >>> EAP needs to allocate the name AVP from the Diameter or RADIUS >>> space. It seems like it should be allocated from the RADIUS space, >>> so that translation the "compatible RADIUS server" has a standard >>> attribute to use on the RADIUS side. >>> >>> If you and others agree, I think this results in the following >>> modifications of Diameter EAP: >>> >>> 1. Add a key name AVP section >>> 2. Make it appear 0-1 times in both the request and response. 3. >>> Explain that the server should return the AVP in response >>> if it was present in the request. >>> 4. Explain that the contents come from EAP methods (add >>> informative reference to EAP keying). >>> 5. Use a RADIUS number space for the attribute number. >> >> Yes, I think this will work. From owner-aaa-wg@merit.edu Fri May 7 14:46:41 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 OAA11816 for ; Fri, 7 May 2004 14:46:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2597691234; Fri, 7 May 2004 14:46:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED80E91236; Fri, 7 May 2004 14:46: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 F3B8091234 for ; Fri, 7 May 2004 14:46:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB1C358D34; Fri, 7 May 2004 14:46:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 9168558D15 for ; Fri, 7 May 2004 14:46:23 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 7 May 2004 14:46:18 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Application support in Diameter Date: Fri, 7 May 2004 14:46:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Been reading these threads and I have a thought: It maybe a good idea if we had a document to guide future Application Writers on how to extend Diameter. Using RADIUS as a historical example, I suggest that it would be better to have this text sooner rather than later. Thoughts? Avi From owner-aaa-wg@merit.edu Fri May 7 15:52: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 PAA16602 for ; Fri, 7 May 2004 15:52:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A66D912F0; Fri, 7 May 2004 15:51:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7AFC912F2; Fri, 7 May 2004 15:51: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 4E5EE912F0 for ; Fri, 7 May 2004 15:51:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1AFF558D9D; Fri, 7 May 2004 15:51:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id C234F58B4C for ; Fri, 7 May 2004 15:51:41 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i47JpB306811; Fri, 7 May 2004 14:51:12 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 May 2004 14:51:12 -0500 Message-ID: <161AA64DA85DFC4BA4D2EB5629B5975306B7C1E5@zrc2c012.us.nortel.com> From: "Christopher Richards" To: marco.stura@nokia.com Cc: david@mitton.com, aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 7 May 2004 14:51:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4346C.A4A805A6" 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_01C4346C.A4A805A6 Content-Type: text/plain Marco, That sounds good. Thanks. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Friday, May 07, 2004 2:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified as follow: When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C4346C.A4A805A6 Content-Type: text/html Message
Marco,
 
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,
 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs


Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.

I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.


   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard

------_=_NextPart_001_01C4346C.A4A805A6-- From owner-aaa-wg@merit.edu Mon May 10 08:52: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 IAA00834 for ; Mon, 10 May 2004 08:52:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0FFC91205; Mon, 10 May 2004 08:52:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EB7791207; Mon, 10 May 2004 08:52: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 909B291205 for ; Mon, 10 May 2004 08:52:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A88AE591B9; Mon, 10 May 2004 08:52:31 -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 DBA3A591AC for ; Mon, 10 May 2004 08:52:30 -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 i4ACqFk00531; Mon, 10 May 2004 15:52:15 +0300 (EET DST) X-Scanned: Mon, 10 May 2004 15:51:05 +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 i4ACp53G029006; Mon, 10 May 2004 15:51:05 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00x5x0Ae; Mon, 10 May 2004 15:51:02 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 i4ACp1H19899; Mon, 10 May 2004 15:51:01 +0300 (EET DST) Received: from nokia.com ([172.21.40.155]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 10 May 2004 15:50:54 +0300 Message-ID: <409F7AAE.6080307@nokia.com> Date: Mon, 10 May 2004 15:50:54 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en, es-es MIME-Version: 1.0 To: AAA mailing list Cc: Mari Carmen belinchon , Miguel-Angel Pallares , "ext Carolina Canales (ML/EEM)" , Pete McCann , Rajaniemi Jaakko Matti , Tammi Kalle Tapani Subject: [AAA-WG]: Diameter SIP app - Open issues list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 May 2004 12:50:54.0935 (UTC) FILETIME=[6EBC7670:01C4368D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Regarding the Diameter SIP application, I have created a list of open issues at: http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/ I have just populated a few open issues that I was aware of. I haven't populated issues that are already included in the current working version, such us the discussion we had a few days ago about the Diameter server delegating authentication to the SIP server (absence of password to verify credentials) If you are aware of other open issues, plese speak up and we can document them. Regards, Miguel -- Miguel A. Garcia tel:+358-50-4804586 Nokia Research Center Helsinki, Finland From owner-aaa-wg@merit.edu Mon May 10 15:09: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 PAA25653 for ; Mon, 10 May 2004 15:09:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 757B291211; Mon, 10 May 2004 15:09:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D12F91213; Mon, 10 May 2004 15:09: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 3514E91211 for ; Mon, 10 May 2004 15:09:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1B28D591D4; Mon, 10 May 2004 15:09:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id B39AA59179 for ; Mon, 10 May 2004 15:09:16 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 May 2004 15:09:11 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , david@mitton.com Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Mon, 10 May 2004 15:09:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry for taking so long to respond. > > With respect to when a new session starts. If we need a guideline > > (and it would certainly help) then perhaps we can suggest that any > > change is session attribute should be considered a change > in session. > > Application writers could refine this definition. > > The usage of Service-Type="Authenticate Only" seems to > indicate that changes in authentication-related attributes > (such as keys or EAP Types) do not constitute a change in > authorization. Yes. Okay so what happens if its "Authenticate only" and non-authentication-related attributes are received? Is the specfication clear about this (a point I brought up before) > However, Paul Funk has made an argument that some > implementations may use an Accounting START to confirm that > the session in fact started > -- and may assume that it did not start if they don't receive it. So the call flow is: Acct Start Acct-Session Id = X Interim Interim Acct Start Acct-Session Id = X > Some questions: > > a. Is it possible to send another Accounting START with the > same Session-Id? Or must the Session-Id always change for each START? Do you mean Accounting Session-Id or Session-Id? If you meant Acct-Session Id then it should not change. Because the second Accounting Start will be detected as a duplicate start record in the accounting stream. Providing the accounting session id is not modified and same NAI etc.... Not sure if that is universal but I checked with our folks and that's what we do. If you change the Session Id I think you would have to generate an Accounting Stop to close the old session id. > b. Is it useful to make a distinction between Service-Type= > "Authenticate Only" and other Service-Types? From a purists point of view Authentication Only should only be about authentication and not anything do to about authorization. So I would like to see that. But obviously we should not break things. From owner-aaa-wg@merit.edu Mon May 10 15:25: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 PAA27336 for ; Mon, 10 May 2004 15:25:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B7129120F; Mon, 10 May 2004 15:25:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00F9B91213; Mon, 10 May 2004 15: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 010FD9120F for ; Mon, 10 May 2004 15:24:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEE1859207; Mon, 10 May 2004 15:24:58 -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 0F474591FE for ; Mon, 10 May 2004 15:24:58 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4AJSeE01296; Mon, 10 May 2004 12:28:40 -0700 Date: Mon, 10 May 2004 12:28:40 -0700 (PDT) From: Bernard Aboba To: Avi Lior Cc: david@mitton.com, "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG 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 usage of Service-Type="Authenticate Only" seems to > > indicate that changes in authentication-related attributes > > (such as keys or EAP Types) do not constitute a change in > > authorization. > > Yes. > > Okay so what happens if its "Authenticate only" and > non-authentication-related attributes are received? Is the specfication > clear about this (a point I brought up before) RFC 3580 is not clear about this, certainly. I'm not sure that RFC 2865 is either. Do you have a proposal? > > However, Paul Funk has made an argument that some > > implementations may use an Accounting START to confirm that > > the session in fact started > > -- and may assume that it did not start if they don't receive it. > > So the call flow is: > > Acct Start Acct-Session Id = X > Interim > Interim > > Acct Start Acct-Session Id = X Yes, I think this makes sense. > > Some questions: > > > > a. Is it possible to send another Accounting START with the > > same Session-Id? Or must the Session-Id always change for each START? > > Do you mean Accounting Session-Id or Session-Id? > If you meant Acct-Session Id then it should not change. Because the second > Accounting Start will be detected as a duplicate start record in the > accounting stream. Providing the accounting session id is not modified and > same NAI etc.... Not sure if that is universal but I checked with our folks > and that's what we do. This makes sense, I think. > If you change the Session Id I think you would have to generate an > Accounting Stop to close the old session id. Yes. > > b. Is it useful to make a distinction between Service-Type= > > "Authenticate Only" and other Service-Types? > > From a purists point of view Authentication Only should only be about > authentication and not anything do to about authorization. So I would like > to see that. But obviously we should not break things. I believe that current usage of "Authenticate Only" is consistent with that, although usage is not universal. From owner-aaa-wg@merit.edu Tue May 11 11:21: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 LAA03130 for ; Tue, 11 May 2004 11:21:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 892999124F; Tue, 11 May 2004 11:21:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58AE791252; Tue, 11 May 2004 11:21: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 2A50F9124F for ; Tue, 11 May 2004 11:21:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A5D859075; Tue, 11 May 2004 11:21:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from proradius03 (m018e36d0.tmodns.net [208.54.142.1]) by segue.merit.edu (Postfix) with ESMTP id 94F0158D40 for ; Tue, 11 May 2004 11:21:14 -0400 (EDT) Received: from mark ([10.254.119.121]) by proradius03 (8.11.6+Sun/8.11.6) with ESMTP id i4BF5lo06502 for ; Tue, 11 May 2004 08:05:48 -0700 (PDT) From: "Mark Peterson" To: Subject: RE: [AAA-WG]: Date: Tue, 11 May 2004 10:21:47 -0500 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk I no longer want to be this email list, please take me off. Thank you, Mark Peterson -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Bernard Aboba Sent: Monday, May 10, 2004 2:29 PM To: Avi Lior Cc: david@mitton.com; 'aaa-wg@merit.edu' Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG > > The usage of Service-Type="Authenticate Only" seems to > > indicate that changes in authentication-related attributes > > (such as keys or EAP Types) do not constitute a change in > > authorization. > > Yes. > > Okay so what happens if its "Authenticate only" and > non-authentication-related attributes are received? Is the specfication > clear about this (a point I brought up before) RFC 3580 is not clear about this, certainly. I'm not sure that RFC 2865 is either. Do you have a proposal? > > However, Paul Funk has made an argument that some > > implementations may use an Accounting START to confirm that > > the session in fact started > > -- and may assume that it did not start if they don't receive it. > > So the call flow is: > > Acct Start Acct-Session Id = X > Interim > Interim > > Acct Start Acct-Session Id = X Yes, I think this makes sense. > > Some questions: > > > > a. Is it possible to send another Accounting START with the > > same Session-Id? Or must the Session-Id always change for each START? > > Do you mean Accounting Session-Id or Session-Id? > If you meant Acct-Session Id then it should not change. Because the second > Accounting Start will be detected as a duplicate start record in the > accounting stream. Providing the accounting session id is not modified and > same NAI etc.... Not sure if that is universal but I checked with our folks > and that's what we do. This makes sense, I think. > If you change the Session Id I think you would have to generate an > Accounting Stop to close the old session id. Yes. > > b. Is it useful to make a distinction between Service-Type= > > "Authenticate Only" and other Service-Types? > > From a purists point of view Authentication Only should only be about > authentication and not anything do to about authorization. So I would like > to see that. But obviously we should not break things. I believe that current usage of "Authenticate Only" is consistent with that, although usage is not universal. From owner-aaa-wg@merit.edu Tue May 11 15:30:46 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 PAA19715 for ; Tue, 11 May 2004 15:30:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46CFD91272; Tue, 11 May 2004 15:27:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5EAC9126D; Tue, 11 May 2004 15:27: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 46CA291273 for ; Tue, 11 May 2004 15:26:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3623859038; Tue, 11 May 2004 15:26:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id 791CD59051 for ; Tue, 11 May 2004 15:26:48 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4BJQeUN011704 for ; Tue, 11 May 2004 21:26:40 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4BJQYKY010382 for ; Tue, 11 May 2004 21:26:34 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2653.19) id ; Tue, 11 May 2004 21:26:35 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D290551C286@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: aaa-wg@merit.edu Subject: [AAA-WG]: DCCA Server State Machine Date: Tue, 11 May 2004 21:26:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I'd like to propose the following minor corrections to the CC server state machine defined in DCCA draft 04. Page 52, 3. transition The action "debit units" certainly applies if requested-action AVP was set to DIRECT_DEBITING. It certainly won't for any other value (BALANCE_CHECK, PRICE_ENQUIRY, REFUND_ACCOUNT). At least this would not be the primary intention. "Debit units" should be either indicated as conditional action (does not seem to be very good style) or the transitions (from Idle to Idle) should be specified specific to requested-action AVP, such as Event CC event received and successfully processed, requested action DIRECT_DEBITING. Action Send CC event answer, debit units Event CC event received and successfully processed, requested action BALANCE_CHECK or PRICE_ENQUIRY. Action Send CC event answer Event CC event received and successfully processed, requested action REFUND_ACCOUNT. Action Send CC event answer, refund account Page 52, 5. transition Modify action "Send CC answer" to "Send CC update Answer" just to align with other transition descriptions. Page 52, 6. transition Page 53, 1. transition The action "stop Tcc" might be added. However, taking a look at client state machines, it seems that in uncuccessful cases the stop of timers (i.e. Tx) is generally not considered. Page 53, 2. transition The action "Stop Tcc" should be removed since the timer is already expired (=event). Regards Jens From owner-aaa-wg@merit.edu Wed May 12 02:22: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 CAA19887 for ; Wed, 12 May 2004 02:22:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 809B191231; Wed, 12 May 2004 02:22:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4439125D; Wed, 12 May 2004 02:22: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 1596691231 for ; Wed, 12 May 2004 02:22:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03159590B8; Wed, 12 May 2004 02:22:43 -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 2EC175908E for ; Wed, 12 May 2004 02:22:42 -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 i4C6MZk04664; Wed, 12 May 2004 09:22:35 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 09:21:32 +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 i4C6LWwm011860; Wed, 12 May 2004 09:21:32 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00m6yJ8i; Wed, 12 May 2004 09:21: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 i4C6LVH02060; Wed, 12 May 2004 09:21:31 +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); Wed, 12 May 2004 09:21:31 +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]: DCCA Server State Machine Date: Wed, 12 May 2004 09:21:29 +0300 Message-ID: Thread-Topic: [AAA-WG]: DCCA Server State Machine Thread-Index: AcQ3jqcEmvrFRkGcRZ61TBu/b8k//QAWm1qA From: To: , X-OriginalArrivalTime: 12 May 2004 06:21:31.0672 (UTC) FILETIME=[5DF8F180:01C437E9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jens, > I'd like to propose the following minor corrections to the CC=20 > server state machine defined in DCCA draft 04. The draft is currently being evaluated by the Area Director - Working Group Last Call ended already. Right now, I think we are only accepting issues that address bugs in the specification. Could you be a bit more = specific about the problems your suggestion is addressing? thanks, John > Page 52, 3. transition >=20 > The action "debit units" certainly applies if=20 > requested-action AVP was set to DIRECT_DEBITING. It certainly=20 > won't for any other value (BALANCE_CHECK, PRICE_ENQUIRY,=20 > REFUND_ACCOUNT). At least this would not be the primary intention. > "Debit units" should be either indicated as conditional=20 > action (does not seem to be very good style) or the=20 > transitions (from Idle to Idle) should be specified specific=20 > to requested-action AVP, such as=20 >=20 > Event =20 > CC event received and successfully processed, > requested action DIRECT_DEBITING. > Action > Send CC event answer, =20 > debit units =20 >=20 > Event =20 > CC event received and successfully processed, > requested action BALANCE_CHECK or PRICE_ENQUIRY. > Action > Send CC event answer >=20 > Event =20 > CC event received and successfully processed, > requested action REFUND_ACCOUNT. > Action > Send CC event answer, =20 > refund account >=20 >=20 > Page 52, 5. transition >=20 > Modify action "Send CC answer" to "Send CC update Answer"=20 > just to align with other transition descriptions. >=20 > Page 52, 6. transition > Page 53, 1. transition >=20 > The action "stop Tcc" might be added. However, taking a look=20 > at client state machines, it seems that in uncuccessful cases=20 > the stop of timers (i.e. Tx) is generally not considered.=20 >=20 > Page 53, 2. transition > =20 > The action "Stop Tcc" should be removed since the timer is=20 > already expired (=3Devent). >=20 >=20 > Regards Jens >=20 From owner-aaa-wg@merit.edu Wed May 12 04:59: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 EAA18659 for ; Wed, 12 May 2004 04:59:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85C809125D; Wed, 12 May 2004 04:59:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 533D991268; Wed, 12 May 2004 04:59: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 4D8359125D for ; Wed, 12 May 2004 04:59:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 365B859136; Wed, 12 May 2004 04:59:38 -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 1AF1B5912D for ; Wed, 12 May 2004 04:59:37 -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 i4C8xZB05216 for ; Wed, 12 May 2004 11:59:35 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 11:58:50 +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 i4C8wo1Y017513 for ; Wed, 12 May 2004 11:58:50 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 005REpkM; Wed, 12 May 2004 11:58:18 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 i4C8jXH03830 for ; Wed, 12 May 2004 11:45:33 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 11:45:31 +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]: Wrapping up Diameter EAP... Date: Wed, 12 May 2004 11:45:31 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> Thread-Topic: Wrapping up Diameter EAP... Thread-Index: AcQ3/XtBe9iMYOQvTwSGEy+4ehxptA== From: To: X-OriginalArrivalTime: 12 May 2004 08:45:31.0292 (UTC) FILETIME=[7B9655C0:01C437FD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, I've posted an intermediate version of draft-ietf-aaa-eap-06.a at http://www.cs.hut.fi/~peronen/eap/diameter_eap.html=20 together with a HTML diff from version -05. This is supposed to resolve all remaining open issues, but=20 I would encourage everyone to check if they are OK with the changes.=20 If I don't get any complaints, I'll post this as -06 some time next week and ask the WG chairs to send it to the IESG. Best regards, Pasi From owner-aaa-wg@merit.edu Wed May 12 09:08: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 JAA00215 for ; Wed, 12 May 2004 09:08:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8F72B9126A; Wed, 12 May 2004 09:08:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60F7C9126C; Wed, 12 May 2004 09:08:07 -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 E3CC89126A for ; Wed, 12 May 2004 09:08:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C75D9590CB; Wed, 12 May 2004 09:08:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id 15E2259042 for ; Wed, 12 May 2004 09:08:05 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4CD81UN018265; Wed, 12 May 2004 15:08:02 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4CD7sKY022263; Wed, 12 May 2004 15:07:56 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2653.19) id ; Wed, 12 May 2004 15:07:54 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D290551C28B@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: AW: [AAA-WG]: DCCA Server State Machine Date: Wed, 12 May 2004 15:07:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi John, sorry, that I missed the end of WG last call. It is not my intention to = annoy anyone. My point is that the server state machine is not correct = and I would like to see it modified. A real implementation will usually = take the following into account, anyway. My major points - in other words - are: Page 52, 3. transition =20 Idle CC event request Send Idle =20 received and successfully CC event =20 processed. answer, =20 debit units =20 This says that any event request sent to the server will lead to the = debit of units. However, if the event request was made for either balance check, price = enquiry or refund account, the credit control server will *not* = decrease subscriber's account balance. Page 53, 2. transition Open Session supervision timer Tcc Stop Tcc, Idle =20 expired release =20 reserved =20 units =20 The event says that Tcc is expired. Hence Tcc does not have be stopped = anymore. The action "Stop Tcc" is not applicable. Regards Jens > -----Urspr=FCngliche Nachricht----- > Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Gesendet: Mittwoch, 12. Mai 2004 08:21 > An: jens.schendel@siemens.com; aaa-wg@merit.edu > Betreff: RE: [AAA-WG]: DCCA Server State Machine=20 >=20 >=20 > Hi Jens, >=20 > > I'd like to propose the following minor corrections to the CC=20 > > server state machine defined in DCCA draft 04. >=20 > The draft is currently being evaluated by the Area Director - Working > Group Last Call ended already. Right now, I think we are=20 > only accepting > issues that address bugs in the specification. Could you be a=20 > bit more specific > about the problems your suggestion is addressing? >=20 > thanks, > John >=20 > > Page 52, 3. transition > >=20 > > The action "debit units" certainly applies if=20 > > requested-action AVP was set to DIRECT_DEBITING. It certainly=20 > > won't for any other value (BALANCE_CHECK, PRICE_ENQUIRY,=20 > > REFUND_ACCOUNT). At least this would not be the primary intention. > > "Debit units" should be either indicated as conditional=20 > > action (does not seem to be very good style) or the=20 > > transitions (from Idle to Idle) should be specified specific=20 > > to requested-action AVP, such as=20 > >=20 > > Event =20 > > CC event received and successfully processed, > > requested action DIRECT_DEBITING. > > Action > > Send CC event answer, =20 > > debit units =20 > >=20 > > Event =20 > > CC event received and successfully processed, > > requested action BALANCE_CHECK or PRICE_ENQUIRY. > > Action > > Send CC event answer > >=20 > > Event =20 > > CC event received and successfully processed, > > requested action REFUND_ACCOUNT. > > Action > > Send CC event answer, =20 > > refund account > >=20 > >=20 > > Page 52, 5. transition > >=20 > > Modify action "Send CC answer" to "Send CC update Answer"=20 > > just to align with other transition descriptions. > >=20 > > Page 52, 6. transition > > Page 53, 1. transition > >=20 > > The action "stop Tcc" might be added. However, taking a look=20 > > at client state machines, it seems that in uncuccessful cases=20 > > the stop of timers (i.e. Tx) is generally not considered.=20 > >=20 > > Page 53, 2. transition > > =20 > > The action "Stop Tcc" should be removed since the timer is=20 > > already expired (=3Devent). > >=20 > >=20 > > Regards Jens > >=20 >=20 From owner-aaa-wg@merit.edu Wed May 12 09:23: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 JAA01236 for ; Wed, 12 May 2004 09:23:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A60A9126D; Wed, 12 May 2004 09:23:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BF489126E; Wed, 12 May 2004 09:23:00 -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 1017A9126D for ; Wed, 12 May 2004 09:22:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0A7D590F5; Wed, 12 May 2004 09:22:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id B13BB590F4 for ; Wed, 12 May 2004 09:22:58 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4CDMpr13969 for ; Wed, 12 May 2004 08:22:51 -0500 (CDT) Received: from zrc2c012.us.nortel.com ([47.103.120.52]) by zrc2c011.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JCQAH8T9; Wed, 12 May 2004 08:22:52 -0500 Received: from nortelnetworks.com (archt2nx.us.nortel.com [47.102.185.73]) by zrc2c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id JRJR33HQ; Wed, 12 May 2004 08:22:51 -0500 Message-ID: <40A22527.3040904@nortelnetworks.com> Date: Wed, 12 May 2004 13:22:47 +0000 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Joe Harvell 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 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Peer State Machine problem 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 Section 5.6 of RFC 3588 indicates that the state machine described therein is closely coupled with the Watchdog Algorithm state machine in RFC 3539. However, the 3588 state machine doesn't explicitly include the behavior of suspending and reopening connections. From this I infer that my implementation must implement a state machine that is synthesized from the sate machines in 3588 and 3539. Most of this is obvious, but there are a couple of points I am unsure of: 1. When re-opening a connection, do I send the CER before or after receiving the three successive DWAs? 2. When I am in the REOPEN state and I receive any message that is not a DWA, 3539 says I should throw it away. Does this include a DWR? If so, are both sides of the connection implementing the same logic? (If so, I think REOPEN->OKAY would never happen for either). From owner-aaa-wg@merit.edu Wed May 12 10:41:47 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 KAA11012 for ; Wed, 12 May 2004 10:41:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9FCDC91271; Wed, 12 May 2004 10:41:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 672C691273; Wed, 12 May 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 2902091271 for ; Wed, 12 May 2004 10:41:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E409F59145; Wed, 12 May 2004 10:41: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 2B1EC5916E for ; Wed, 12 May 2004 10:41:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4CEjHU25513; Wed, 12 May 2004 07:45:17 -0700 Date: Wed, 12 May 2004 07:45:17 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk A question: RFC 3579 requires that a RADIUS client be able to differentiate one EAP session from another. As we've been discussing in EAP WG, this may be tricky in the case where an EAP authentication is restarted via an EAPOL-Start message. I don't see any text in this draft equivalent to RFC 3579, Section 2.6.1 that describe how Diameter handles this problem. I suspect that Diameter should be able to do better than RADIUS, but guidance on how the server should behave would be helpful. On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > Hi, > > I've posted an intermediate version of draft-ietf-aaa-eap-06.a > at http://www.cs.hut.fi/~peronen/eap/diameter_eap.html > together with a HTML diff from version -05. > > This is supposed to resolve all remaining open issues, but > I would encourage everyone to check if they are OK with > the changes. > > If I don't get any complaints, I'll post this as -06 some time > next week and ask the WG chairs to send it to the IESG. > > Best regards, > Pasi > From owner-aaa-wg@merit.edu Wed May 12 10:50:47 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 KAA12332 for ; Wed, 12 May 2004 10:50:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F28591275; Wed, 12 May 2004 10:50:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 068E591276; Wed, 12 May 2004 10:50: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 E4AB491275 for ; Wed, 12 May 2004 10:50:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D125159062; Wed, 12 May 2004 10:50:32 -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 3A3FA58F37 for ; Wed, 12 May 2004 10:50:32 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 383FC89846; Wed, 12 May 2004 17:50:15 +0300 (EEST) Message-ID: <40A238DA.4050809@kolumbus.fi> Date: Wed, 12 May 2004 17:46:50 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@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 Yes. How about making the same statement as in RFC 3579, but add Session-Id AVP in there as well? --Jari Bernard Aboba wrote: > A question: > > RFC 3579 requires that a RADIUS client be able to differentiate one EAP > session from another. As we've been discussing in EAP WG, this may be > tricky in the case where an EAP authentication is restarted via an > EAPOL-Start message. > > I don't see any text in this draft equivalent to RFC 3579, Section 2.6.1 > that describe how Diameter handles this problem. I suspect that Diameter > should be able to do better than RADIUS, but guidance on how the server > should behave would be helpful. > > On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > > >>Hi, >> >>I've posted an intermediate version of draft-ietf-aaa-eap-06.a >>at http://www.cs.hut.fi/~peronen/eap/diameter_eap.html >>together with a HTML diff from version -05. >> >>This is supposed to resolve all remaining open issues, but >>I would encourage everyone to check if they are OK with >>the changes. >> >>If I don't get any complaints, I'll post this as -06 some time >>next week and ask the WG chairs to send it to the IESG. >> >>Best regards, >>Pasi >> > > From owner-aaa-wg@merit.edu Wed May 12 11:10: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 LAA14964 for ; Wed, 12 May 2004 11:10:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9FB3491276; Wed, 12 May 2004 11:09:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6513391277; Wed, 12 May 2004 11:09: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 79A7F91276 for ; Wed, 12 May 2004 11:09:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6478059139; Wed, 12 May 2004 11:09: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 2D12F5910C for ; Wed, 12 May 2004 11:09:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4CFDgc27103; Wed, 12 May 2004 08:13:43 -0700 Date: Wed, 12 May 2004 08:13:42 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <40A238DA.4050809@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> <40A238DA.4050809@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes. How about making the same statement as in RFC 3579, > but add Session-Id AVP in there as well? In addition, I think you'd need to be clear that the Session-Id AVP would need to change if the session were restarted, and that the Diameter server should consider it a different session as a result. I think the same thing would also apply to a reauthentication, no? From owner-aaa-wg@merit.edu Wed May 12 11:36: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 LAA18137 for ; Wed, 12 May 2004 11:36:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18ED891279; Wed, 12 May 2004 11:36:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D67F59127A; Wed, 12 May 2004 11:36:12 -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 C691D91279 for ; Wed, 12 May 2004 11:36:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B4C7D590F2; Wed, 12 May 2004 11:36: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 7612B590EF for ; Wed, 12 May 2004 11:36:11 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2E31D8984A; Wed, 12 May 2004 18:36:10 +0300 (EEST) Message-ID: <40A24399.1070908@kolumbus.fi> Date: Wed, 12 May 2004 18:32:41 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> <40A238DA.4050809@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: >>Yes. How about making the same statement as in RFC 3579, >>but add Session-Id AVP in there as well? > > > In addition, I think you'd need to be clear that the Session-Id AVP would > need to change if the session were restarted, and that the Diameter server > should consider it a different session as a result. Yes. > I think the same thing would also apply to a reauthentication, no? Hmm... I suppose it would have to, otherwise it would be hard to distinguish an aborted and continued reauthentication from each other? Though I don't even know if EAP lower layers would support something like an aborted reauthentication... In any case, I was under the impression that in reauthentication, Diameter would require the same session-id. But I might remember it wrong. --Jari From owner-aaa-wg@merit.edu Wed May 12 11:37: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 LAA18284 for ; Wed, 12 May 2004 11:37:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F6289127A; Wed, 12 May 2004 11:37:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4506A9127B; Wed, 12 May 2004 11:37: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 3B3809127A for ; Wed, 12 May 2004 11:37:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1134E59139; Wed, 12 May 2004 11:37:05 -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 C1914590FC for ; Wed, 12 May 2004 11:37:04 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 177428984A; Wed, 12 May 2004 18:37:04 +0300 (EEST) Message-ID: <40A243D3.4030505@kolumbus.fi> Date: Wed, 12 May 2004 18:33:39 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> <40A238DA.4050809@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: >>Yes. How about making the same statement as in RFC 3579, >>but add Session-Id AVP in there as well? > > > In addition, I think you'd need to be clear that the Session-Id AVP would > need to change if the session were restarted, and that the Diameter server > should consider it a different session as a result. > > I think the same thing would also apply to a reauthentication, no? Also, we could invent a completely new AVP that fixes the issue for both Diameter *and* RADIUS. --Jari From owner-aaa-wg@merit.edu Wed May 12 12:13:46 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 MAA22352 for ; Wed, 12 May 2004 12:13:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 249629127E; Wed, 12 May 2004 12:13:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E428C9127F; Wed, 12 May 2004 12:13: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 89AA09127E for ; Wed, 12 May 2004 12:13:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 71A6659136; Wed, 12 May 2004 12:13:27 -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 7B208590E9 for ; Wed, 12 May 2004 12:13:26 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4CGDLgH024679; Thu, 13 May 2004 01:13:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4CGDLeE013894; Thu, 13 May 2004 01:13:21 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id BAA13892 ; Thu, 13 May 2004 01:13:21 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id BAA05247; Thu, 13 May 2004 01:13:20 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id BAA11766; Thu, 13 May 2004 01:13:19 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4CGDJEU012870; Thu, 13 May 2004 01:13:19 +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 <0HXL00D89ZQ49G@tsbpo1.po.toshiba.co.jp>; Thu, 13 May 2004 01:13:18 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BNwMl-0007Xc-00; Wed, 12 May 2004 09:13:55 -0700 Date: Wed, 12 May 2004 09:13:55 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Message-id: <20040512161355.GE25541@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AA8@esebe023.ntc.nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, May 12, 2004 at 07:45:17AM -0700, Bernard Aboba wrote: > A question: > > RFC 3579 requires that a RADIUS client be able to differentiate one EAP > session from another. As we've been discussing in EAP WG, this may be > tricky in the case where an EAP authentication is restarted via an > EAPOL-Start message. > > I don't see any text in this draft equivalent to RFC 3579, Section 2.6.1 > that describe how Diameter handles this problem. I suspect that Diameter > should be able to do better than RADIUS, but guidance on how the server > should behave would be helpful. Hmm, what is the exact definition of EAP session? In section 4.1 of draft-ietf-eap-rfc2284bis-09.txt: "Since the Identifier space is unique to each session, authenticators are not restricted to only 256 simultaneous authentication conversations. Similarly, with re-authentication, an EAP conversation might continue over a long period of time, and is not limited to only 256 roundtrips." This text seems to indicate that an EAP session can span over multiple rounds of re-authentication, and I don't think session identification attributes do not have to change when reset or re-authentication occurs. Yoshihiro Ohba > > On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > > > Hi, > > > > I've posted an intermediate version of draft-ietf-aaa-eap-06.a > > at http://www.cs.hut.fi/~peronen/eap/diameter_eap.html > > together with a HTML diff from version -05. > > > > This is supposed to resolve all remaining open issues, but > > I would encourage everyone to check if they are OK with > > the changes. > > > > If I don't get any complaints, I'll post this as -06 some time > > next week and ask the WG chairs to send it to the IESG. > > > > Best regards, > > Pasi > > From owner-aaa-wg@merit.edu Wed May 12 12:41: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 MAA25201 for ; Wed, 12 May 2004 12:41:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42E119127C; Wed, 12 May 2004 12:41:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 106679127D; Wed, 12 May 2004 12:41:12 -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 EC73D9127C for ; Wed, 12 May 2004 12:41:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D3DD65915F; Wed, 12 May 2004 12:41:10 -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 086AB58DBA for ; Wed, 12 May 2004 12:41:10 -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 i4CGf1k18976; Wed, 12 May 2004 19:41:01 +0300 (EET DST) X-Scanned: Wed, 12 May 2004 19:40:28 +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 i4CGeSZ2029603; Wed, 12 May 2004 19:40:28 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00SkMK9x; Wed, 12 May 2004 19:40:26 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4CGeQH19928; Wed, 12 May 2004 19:40:26 +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); Wed, 12 May 2004 19:40:25 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 12 May 2004 19:40:26 +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]: Wrapping up Diameter EAP... Date: Wed, 12 May 2004 19:40:25 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ4NwNnuQC2uuk5SPKUdqxLQRgLtAAB/mbQ From: To: , Cc: X-OriginalArrivalTime: 12 May 2004 16:40:26.0347 (UTC) FILETIME=[D3F6ABB0:01C4383F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable I took a look at the state machines, and what seems to be missing=20 is a way to pass the "eapRestart" signal to the AAA server... John Vollbrecht suggested that this could be solved by adding an=20 attribute signalling that this is the first EAP packet of an EAP conversation. Maybe named something like EAP-Restart or EAP-Start? If we assign the type code from 0..255 range, it would work for RADIUS=20 as well... (This way we could keep the Session-Id same; I think it's supposed to stay the same over reauthentications..) Best regards, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, May 12, 2004 6:34 PM > To: Bernard Aboba > Cc: Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... >=20 >=20 > Bernard Aboba wrote: > >>Yes. How about making the same statement as in RFC 3579, > >>but add Session-Id AVP in there as well? > >=20 > >=20 > > In addition, I think you'd need to be clear that the=20 > Session-Id AVP would > > need to change if the session were restarted, and that the=20 > Diameter server > > should consider it a different session as a result. > >=20 > > I think the same thing would also apply to a reauthentication, no? >=20 > Also, we could invent a completely new AVP that fixes the issue > for both Diameter *and* RADIUS. >=20 > --Jari >=20 From owner-aaa-wg@merit.edu Wed May 12 12:49: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 MAA25948 for ; Wed, 12 May 2004 12:49:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E93CD91232; Wed, 12 May 2004 12:49:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4EC49127D; Wed, 12 May 2004 12:49:41 -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 B911291232 for ; Wed, 12 May 2004 12:49:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B36759140; Wed, 12 May 2004 12:49:40 -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 6C76E590F4 for ; Wed, 12 May 2004 12:49:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4CGrLo00574; Wed, 12 May 2004 09:53:21 -0700 Date: Wed, 12 May 2004 09:53:21 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Question: Does the RADIUS State attribute serve some of the same function? For example, continuing EAP conversations may contain a State attribute. On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > > I took a look at the state machines, and what seems to be missing > is a way to pass the "eapRestart" signal to the AAA server... > > John Vollbrecht suggested that this could be solved by adding an > attribute signalling that this is the first EAP packet of an EAP > conversation. Maybe named something like EAP-Restart or EAP-Start? > If we assign the type code from 0..255 range, it would work for RADIUS > as well... > > (This way we could keep the Session-Id same; I think it's supposed > to stay the same over reauthentications..) > > Best regards, > Pasi From owner-aaa-wg@merit.edu Wed May 12 13:28: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 NAA28148 for ; Wed, 12 May 2004 13:28:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 91DE69127D; Wed, 12 May 2004 13:28:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 616A29127F; Wed, 12 May 2004 13:28:41 -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 518899127D for ; Wed, 12 May 2004 13:28:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39F0859169; Wed, 12 May 2004 13:28:40 -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 C1BB75915D for ; Wed, 12 May 2004 13:28:39 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0CA218984A; Wed, 12 May 2004 20:28:38 +0300 (EEST) Message-ID: <40A25DF9.2050404@kolumbus.fi> Date: Wed, 12 May 2004 20:25:13 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@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 Good question. I suppose it can be used to implement this. Maybe the only missing thing is that RFC 3579 doesn't say it should be used this way? Note that State would work for Diameter EAP too, I think. --Jari Bernard Aboba wrote: > Question: Does the RADIUS State attribute serve some of the same > function? > > For example, continuing EAP conversations may contain a State attribute. > > On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > > >>I took a look at the state machines, and what seems to be missing >>is a way to pass the "eapRestart" signal to the AAA server... >> >>John Vollbrecht suggested that this could be solved by adding an >>attribute signalling that this is the first EAP packet of an EAP >>conversation. Maybe named something like EAP-Restart or EAP-Start? >>If we assign the type code from 0..255 range, it would work for RADIUS >>as well... >> >>(This way we could keep the Session-Id same; I think it's supposed >>to stay the same over reauthentications..) >> >>Best regards, >>Pasi > > From owner-aaa-wg@merit.edu Wed May 12 13:58:01 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 NAA00082 for ; Wed, 12 May 2004 13:58:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEE3191233; Wed, 12 May 2004 13:57:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B682C9127F; Wed, 12 May 2004 13:57: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 AC76C91233 for ; Wed, 12 May 2004 13:57:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8A1325912F; Wed, 12 May 2004 13:57:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h032.c000.snv.cp.net [209.228.34.190]) by segue.merit.edu (Postfix) with SMTP id E073859173 for ; Wed, 12 May 2004 13:57:43 -0400 (EDT) Received: (cpmta 8377 invoked from network); 12 May 2004 10:57:42 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.34.190) with SMTP; 12 May 2004 10:57:42 -0700 X-Sent: 12 May 2004 17:57:42 GMT Message-Id: <5.2.1.1.2.20040512135532.04548e80@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Wed, 12 May 2004 13:57:19 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <40A25DF9.2050404@kolumbus.fi> References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@esebe023.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Note that a State attribute comes from the Server, and a client only reflects it. Dave. On 5/12/2004 08:25 PM +0300, Jari Arkko wrote: >Good question. I suppose it can be used to implement this. >Maybe the only missing thing is that RFC 3579 doesn't say >it should be used this way? Note that State would work for >Diameter EAP too, I think. > >--Jari > >Bernard Aboba wrote: >>Question: Does the RADIUS State attribute serve some of the same >>function? >>For example, continuing EAP conversations may contain a State attribute. >>On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: >> >>>I took a look at the state machines, and what seems to be missing >>>is a way to pass the "eapRestart" signal to the AAA server... >>> >>>John Vollbrecht suggested that this could be solved by adding an >>>attribute signalling that this is the first EAP packet of an EAP >>>conversation. Maybe named something like EAP-Restart or EAP-Start? >>>If we assign the type code from 0..255 range, it would work for RADIUS >>>as well... >>> >>>(This way we could keep the Session-Id same; I think it's supposed >>>to stay the same over reauthentications..) >>> >>>Best regards, >>>Pasi > From owner-aaa-wg@merit.edu Wed May 12 16:13: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 QAA08269 for ; Wed, 12 May 2004 16:13:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECE0091289; Wed, 12 May 2004 16:12:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B83279128A; Wed, 12 May 2004 16:12: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 9C37891289 for ; Wed, 12 May 2004 16:12:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CE4D590F5; Wed, 12 May 2004 16:12:48 -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 EB17958FD7 for ; Wed, 12 May 2004 16:12:47 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 76B968984E; Wed, 12 May 2004 23:12:46 +0300 (EEST) Message-ID: <40A28471.6060001@kolumbus.fi> Date: Wed, 12 May 2004 23:09:21 +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: David Mitton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6010C3AAB@esebe023.ntc.nokia.com> <5.2.1.1.2.20040512135532.04548e80@getmail.mitton.com> In-Reply-To: <5.2.1.1.2.20040512135532.04548e80@getmail.mitton.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 David Mitton wrote: > Note that a State attribute comes from the Server, and a client only > reflects it. Yes. But if client does not include the State attribute in its new Access Request, its an indication to the server that a new EAP run has started. However, in order for this to work, the server has to use the State attribute, and it has to understand what the lack of the State attribute means. --Jari > Dave. > > On 5/12/2004 08:25 PM +0300, Jari Arkko wrote: > >> Good question. I suppose it can be used to implement this. >> Maybe the only missing thing is that RFC 3579 doesn't say >> it should be used this way? Note that State would work for >> Diameter EAP too, I think. >> >> --Jari >> >> Bernard Aboba wrote: >> >>> Question: Does the RADIUS State attribute serve some of the same >>> function? >>> For example, continuing EAP conversations may contain a State attribute. >>> On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: >>> >>>> I took a look at the state machines, and what seems to be missing >>>> is a way to pass the "eapRestart" signal to the AAA server... >>>> >>>> John Vollbrecht suggested that this could be solved by adding an >>>> attribute signalling that this is the first EAP packet of an EAP >>>> conversation. Maybe named something like EAP-Restart or EAP-Start? >>>> If we assign the type code from 0..255 range, it would work for RADIUS >>>> as well... >>>> >>>> (This way we could keep the Session-Id same; I think it's supposed >>>> to stay the same over reauthentications..) >>>> >>>> Best regards, >>>> Pasi >> >> > > > From owner-aaa-wg@merit.edu Wed May 12 16:30: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 QAA09246 for ; Wed, 12 May 2004 16:30:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55B379128A; Wed, 12 May 2004 16:30:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EF819128B; Wed, 12 May 2004 16:30: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 EAFAB9128A for ; Wed, 12 May 2004 16:30:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D24F2590B6; Wed, 12 May 2004 16:30:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 81ACC58FA2 for ; Wed, 12 May 2004 16:30:25 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 12 May 2004 16:30:20 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , Avi Lior Cc: david@mitton.com, "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter Nasreq Draft 15 ready to go to the IESG Date: Wed, 12 May 2004 16:30:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > > > The usage of Service-Type="Authenticate Only" seems to > indicate that > > > changes in authentication-related attributes (such as keys or EAP > > > Types) do not constitute a change in authorization. > > > > Yes. > > > > Okay so what happens if its "Authenticate only" and > > non-authentication-related attributes are received? Is the > > specfication clear about this (a point I brought up before) > > RFC 3580 is not clear about this, certainly. I'm not sure > that RFC 2865 is either. Do you have a proposal? Well, as I see it there are three options: A) Leave it unspecified. That is if there are service effecting attributes then So be it. B) Ignore any service effecting attributes. But this is bad since the home network will think the new attributes have been accepted. C) Make the specification tight. NAS must reject any messages that are not authentication related. C) Is what we probably should have done. But probably people would complain. In hide sight it may have been better to have two new commands: one for re-authenticate and one for re-authorize. Also related to this. Not sure what is being done. When we reauthenticate what happens when the identity does not match the original identity? Not sure this was addressed. > > > However, Paul Funk has made an argument that some implementations > > > may use an Accounting START to confirm that the session in fact > > > started > > > -- and may assume that it did not start if they don't receive it. > > > > So the call flow is: > > > > Acct Start Acct-Session Id = X > > Interim > > Interim > > > > Acct Start Acct-Session Id = X > > Yes, I think this makes sense. > > > > Some questions: > > > > > > a. Is it possible to send another Accounting START with the same > > > Session-Id? Or must the Session-Id always change for each START? > > > > Do you mean Accounting Session-Id or Session-Id? > > If you meant Acct-Session Id then it should not change. Because the > > second Accounting Start will be detected as a duplicate > start record > > in the accounting stream. Providing the accounting session > id is not > > modified and same NAI etc.... Not sure if that is universal but I > > checked with our folks and that's what we do. > > This makes sense, I think. > > > If you change the Session Id I think you would have to generate an > > Accounting Stop to close the old session id. > > Yes. > > > > b. Is it useful to make a distinction between Service-Type= > > > "Authenticate Only" and other Service-Types? > > > > From a purists point of view Authentication Only should > only be about > > authentication and not anything do to about authorization. > So I would > > like to see that. But obviously we should not break things. > > I believe that current usage of "Authenticate Only" is > consistent with that, although usage is not universal. > From owner-aaa-wg@merit.edu Thu May 13 03:16: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 DAA23709 for ; Thu, 13 May 2004 03:16:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35A2391270; Thu, 13 May 2004 03:15:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 032ED91273; Thu, 13 May 2004 03:15: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 AE84991270 for ; Thu, 13 May 2004 03:15:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 99C3059062; Thu, 13 May 2004 03:15:45 -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 1805359042 for ; Thu, 13 May 2004 03:15:45 -0400 (EDT) Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4D7FhAh024466 for ; Thu, 13 May 2004 09:15:44 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Thu, 13 May 2004 09:15:44 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 13 May 2004 09:15:51 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'Schendel Jens ICM Berlin'" , "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Server State Machine Date: Thu, 13 May 2004 09:15:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 13 May 2004 07:15:44.0009 (UTC) FILETIME=[1AEDEF90:01C438BA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Jens, If we change this like this: > Page 52, 3. transition > > > Idle CC event request Send Idle > received and successfully CC event > processed. answer, > debit units TO: Idle CC event request Send Idle received and successfully CC event processed. answer Do you think that it covers your concerns, since the action "successfully processed" covers all different events and processing of them accordingly? and then change this one: > Open Session supervision timer Tcc Stop Tcc, Idle > expired release > reserved > units TO: Open Session supervision timer Tcc release Idle expired reserved units Is this ok? regards.............Harri > -----Original Message----- > From: owner-aaa-wg@merit.edu > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Schendel Jens ICM Berlin > Sent: 12. toukokuuta 2004 16:08 > To: 'john.loughney@nokia.com'; aaa-wg@merit.edu > Subject: AW: [AAA-WG]: DCCA Server State Machine > > > Hi John, > > sorry, that I missed the end of WG last call. It is not my > intention to annoy anyone. My point is that the server state > machine is not correct and I would like to see it modified. A > real implementation will usually take the following into > account, anyway. > > My major points - in other words - are: > > Page 52, 3. transition > > > Idle CC event request Send Idle > received and successfully CC event > processed. answer, > debit units > > This says that any event request sent to the server will lead > to the debit of units. > However, if the event request was made for either balance > check, price enquiry or refund account, the credit control > server will *not* decrease subscriber's account balance. > > Page 53, 2. transition > > Open Session supervision timer Tcc Stop Tcc, Idle > expired release > reserved > units > > The event says that Tcc is expired. Hence Tcc does not have > be stopped anymore. The action "Stop Tcc" is not applicable. > > Regards Jens > > From owner-aaa-wg@merit.edu Thu May 13 08:57: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 IAA09545 for ; Thu, 13 May 2004 08:57:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F30AE91278; Thu, 13 May 2004 08:56:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BA8869127B; Thu, 13 May 2004 08:56: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 923BB91278 for ; Thu, 13 May 2004 08:56:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EEEE591E8; Thu, 13 May 2004 08:56:48 -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 637675919F for ; Thu, 13 May 2004 08:56:47 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4DCufB25260; Thu, 13 May 2004 15:56:41 +0300 (EET DST) X-Scanned: Thu, 13 May 2004 15:55: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 i4DCtRRM000953; Thu, 13 May 2004 15:55:27 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00a506YF; Thu, 13 May 2004 15:55:26 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 i4DCtPH04561; Thu, 13 May 2004 15:55: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, 13 May 2004 15:55:25 +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]: when it's okay to proxy Date: Thu, 13 May 2004 15:55:25 +0300 Message-ID: Thread-Topic: [AAA-WG]: when it's okay to proxy Thread-Index: AcQsVcDGvkKDDCoBQiyyLWoHHtzRyAMk47Yw From: To: , X-OriginalArrivalTime: 13 May 2004 12:55:25.0639 (UTC) FILETIME=[8F53DD70:01C438E9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Joe, > "For the originator of a Diameter message, "Encr" (Encryption) mans = that=20 > if a message containing that AVP is to be sent via a Diameter Agent=20 > (proxy, redirect or relay) then the message MUST NOT be sent=20 > unless..." >=20 > What puzzles me about this is that if a peer is discovered but not=20 > configured, then there is no way to know if it is a proxy. Relays and = > Redirect Agents can always be identified because they advertise the=20 > Relay application id. But proxies look the same as servers=20 > and clients. >=20 > Even for a peer that is known by static configuration, is it expected=20 > that it be idenified as a proxy by configuration? Or is there some = way=20 > to discover that it is a proxy that I am missing? It seems that there is no discovery mechanism for proxies, manual = configuration is the only way. Would it make sense for Proxies to advertise = themselves as such via the Application Identifiers? John From owner-aaa-wg@merit.edu Thu May 13 09:18:23 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 JAA10778 for ; Thu, 13 May 2004 09:18:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CDCC91284; Thu, 13 May 2004 09:17:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4255791285; Thu, 13 May 2004 09:17:00 -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 AD75D91284 for ; Thu, 13 May 2004 09:16:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 982B059117; Thu, 13 May 2004 09:16:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ns2.bln1.siemens.de (ns2.bln1.siemens.de [194.138.127.35]) by segue.merit.edu (Postfix) with ESMTP id A56B859195 for ; Thu, 13 May 2004 09:16:56 -0400 (EDT) Received: from ns-srv-2.bln1.siemens.de (stbf7654 [194.138.127.67]) by ns2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4DDGaUN027941; Thu, 13 May 2004 15:16:36 +0200 (MEST) Received: from blnss10a.bln1.siemens.de (blnss10a.bln1.siemens.de [194.138.127.102]) by ns-srv-2.bln1.siemens.de (8.12.10/8.12.10/MTA) with ESMTP id i4DDGTKY009883; Thu, 13 May 2004 15:16:30 +0200 (MEST) Received: by blnss10a.bln1.siemens.de with Internet Mail Service (5.5.2653.19) id ; Thu, 13 May 2004 15:16:30 +0200 Message-ID: <445C57B81208C24EAD99F2944DBB9D290551C29A@blnss10a.bln1.siemens.de> From: Schendel Jens ICM Berlin To: "'Harri Hakala (JO/LMF)'" , "'john.loughney@nokia.com'" Cc: aaa-wg@merit.edu Subject: AW: [AAA-WG]: DCCA Server State Machine Date: Thu, 13 May 2004 15:16:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Harri, thanks for your suggestions I fully agree with. > If we change this like this: > > Page 52, 3. transition > > > > > > Idle CC event request Send Idle > > received and successfully CC event > > processed. answer, > > debit units > TO: > Idle CC event request Send Idle > received and successfully CC event > processed. answer > > Do you think that it covers your concerns, since the action > "successfully processed" > covers all different events and processing of them accordingly? Letting the event specific action open is the plain approach that works. > > and then change this one: > > Open Session supervision timer Tcc Stop Tcc, Idle > > expired release > > reserved > > units > TO: > Open Session supervision timer Tcc release Idle > expired reserved > units > Is this ok? Yes, just the deletion. Regards Jens From owner-aaa-wg@merit.edu Fri May 14 00:50: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 AAA10754 for ; Fri, 14 May 2004 00:50:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FE7791240; Fri, 14 May 2004 00:50:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2181E91290; Fri, 14 May 2004 00:50: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 ED50B91240 for ; Fri, 14 May 2004 00:50:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4EFF5918B; Fri, 14 May 2004 00:50:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id 9511A59216 for ; Fri, 14 May 2004 00:50:36 -0400 (EDT) Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 13 May 2004 20:55:21 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i4E4oXSu010981; Thu, 13 May 2004 21:50:33 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.193]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 13 May 2004 21:57:33 -0700 From: "Joseph Salowey" To: "'Jari Arkko'" , "'David Mitton'" Cc: Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Thu, 13 May 2004 21:50:58 -0700 Message-ID: <007d01c4396f$0d979ed0$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-reply-to: <40A28471.6060001@kolumbus.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 May 2004 04:57:33.0399 (UTC) FILETIME=[F7C0FE70:01C4396F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit owner-aaa-wg@merit.edu wrote: > David Mitton wrote: >> Note that a State attribute comes from the Server, and a client only >> reflects it. > > Yes. But if client does not include the State attribute in > its new Access Request, its an indication to the server that a new > EAP run has started. > > However, in order for this to work, the server has to use the > State attribute, and it has to understand what the lack of the State > attribute means. > [Joe] Currently the state attribute is not required so not all server implementations may include it. Perhaps when EAP is used they should. > --Jari > >> Dave. >> >> On 5/12/2004 08:25 PM +0300, Jari Arkko wrote: >> >>> Good question. I suppose it can be used to implement this. Maybe the >>> only missing thing is that RFC 3579 doesn't say it should be used >>> this way? Note that State would work for Diameter EAP too, I think. >>> >>> --Jari >>> >>> Bernard Aboba wrote: >>> >>>> Question: Does the RADIUS State attribute serve some of the same >>>> function? For example, continuing EAP conversations may contain a >>>> State attribute. On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: >>>> >>>>> I took a look at the state machines, and what seems to be missing >>>>> is a way to pass the "eapRestart" signal to the AAA server... >>>>> >>>>> John Vollbrecht suggested that this could be solved by adding an >>>>> attribute signalling that this is the first EAP packet of an EAP >>>>> conversation. Maybe named something like EAP-Restart or EAP-Start? >>>>> If we assign the type code from 0..255 range, it would work for >>>>> RADIUS as well... >>>>> >>>>> (This way we could keep the Session-Id same; I think it's supposed >>>>> to stay the same over reauthentications..) >>>>> >>>>> Best regards, >>>>> Pasi From owner-aaa-wg@merit.edu Fri May 14 03:42: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 DAA03986 for ; Fri, 14 May 2004 03:42:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98E4291290; Fri, 14 May 2004 03:41:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6627791291; Fri, 14 May 2004 03:41: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 2BD0191290 for ; Fri, 14 May 2004 03:41:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17C595914A; Fri, 14 May 2004 03:41:57 -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 222DF5929A for ; Fri, 14 May 2004 03:41:56 -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 i4E7fsk26851 for ; Fri, 14 May 2004 10:41:54 +0300 (EET DST) X-Scanned: Fri, 14 May 2004 10:40:59 +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 i4E7exkl003816 for ; Fri, 14 May 2004 10:40:59 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00CaazqU; Fri, 14 May 2004 10:40:58 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 i4E7evH25956 for ; Fri, 14 May 2004 10:40:57 +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); Fri, 14 May 2004 10:40:53 +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]: Wrapping up Diameter EAP... Date: Fri, 14 May 2004 10:40:53 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122408@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ5bxO6/ETLTbQERm6wcPtN7+OSmgAFn6Kg From: To: X-OriginalArrivalTime: 14 May 2004 07:40:53.0864 (UTC) FILETIME=[C9494680:01C43986] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hmm, a question: FC 3579 distinguishes between sessions using the following attributes: NAS-Identifier, NAS-IPv6-Address, NAS-IPv4-Address, User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info. Is it enough to use the Session-Id AVP to get the same effect=20 in Diameter? In addition to Session-Id, we may still need the State attribute to distinguish multiple EAP sessions within a single Diameter session, if we assume that e.g. reauthentication can keep the same Diameter Session-Id. Cheers, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Joseph Salowey > Sent: Friday, May 14, 2004 7:51 AM > To: 'Jari Arkko'; 'David Mitton' > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... >=20 >=20 >=20 >=20 > owner-aaa-wg@merit.edu wrote: > > David Mitton wrote: > >> Note that a State attribute comes from the Server, and a=20 > client only > >> reflects it. > >=20 > > Yes. But if client does not include the State attribute in > > its new Access Request, its an indication to the server that a new > > EAP run has started.=20 > >=20 > > However, in order for this to work, the server has to use the > > State attribute, and it has to understand what the lack of the State > > attribute means.=20 > >=20 >=20 > [Joe] Currently the state attribute is not required so not all server > implementations may include it. Perhaps when EAP is used=20 > they should. =20 >=20 > > --Jari > >=20 > >> Dave. > >>=20 > >> On 5/12/2004 08:25 PM +0300, Jari Arkko wrote: > >>=20 > >>> Good question. I suppose it can be used to implement=20 > this. Maybe the > >>> only missing thing is that RFC 3579 doesn't say it should be used > >>> this way? Note that State would work for Diameter EAP=20 > too, I think. > >>>=20 > >>> --Jari > >>>=20 > >>> Bernard Aboba wrote: > >>>=20 > >>>> Question: Does the RADIUS State attribute serve some of the same > >>>> function? For example, continuing EAP conversations may contain a > >>>> State attribute. On Wed, 12 May 2004 Pasi.Eronen@nokia.com wrote: > >>>>=20 > >>>>> I took a look at the state machines, and what seems to=20 > be missing > >>>>> is a way to pass the "eapRestart" signal to the AAA server... > >>>>>=20 > >>>>> John Vollbrecht suggested that this could be solved by adding an > >>>>> attribute signalling that this is the first EAP packet of an EAP > >>>>> conversation. Maybe named something like EAP-Restart or=20 > EAP-Start? > >>>>> If we assign the type code from 0..255 range, it would work for > >>>>> RADIUS as well...=20 > >>>>>=20 > >>>>> (This way we could keep the Session-Id same; I think=20 > it's supposed > >>>>> to stay the same over reauthentications..) > >>>>>=20 > >>>>> Best regards, > >>>>> Pasi >=20 >=20 From owner-aaa-wg@merit.edu Fri May 14 04:07:21 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 EAA05595 for ; Fri, 14 May 2004 04:07:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B455891291; Fri, 14 May 2004 04:07:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DD6791295; Fri, 14 May 2004 04:07: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 41ABC91291 for ; Fri, 14 May 2004 04:07:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F8BA59280; Fri, 14 May 2004 04:07:05 -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 7EE4D5927C for ; Fri, 14 May 2004 04:07:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4E8AeQ09295; Fri, 14 May 2004 01:10:40 -0700 Date: Fri, 14 May 2004 01:10:40 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122408@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122408@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > In addition to Session-Id, we may still need the State attribute > to distinguish multiple EAP sessions within a single Diameter session, > if we assume that e.g. reauthentication can keep the same Diameter > Session-Id. Yes. I think in practice that the State attribute is needed to avoid strange behavior such as for the case we have been discussing on the EAP WG mailing list (EAPOL restart). From owner-aaa-wg@merit.edu Fri May 14 11:26: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 LAA27633 for ; Fri, 14 May 2004 11:26:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A05C7912A0; Fri, 14 May 2004 11:26:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 619A091245; Fri, 14 May 2004 11:26: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 477FC91242 for ; Fri, 14 May 2004 11:26:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28DDA592C9; Fri, 14 May 2004 11:26:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from sj-iport-2.cisco.com (sj-iport-2-in.cisco.com [171.71.176.71]) by segue.merit.edu (Postfix) with ESMTP id D14CF592B3 for ; Fri, 14 May 2004 11:26:00 -0400 (EDT) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 14 May 2004 07:30:50 +0000 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i4EFPvW9012845; Fri, 14 May 2004 08:25:58 -0700 (PDT) Received: from jsaloweyw2k01 ([10.82.224.193]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 May 2004 08:32:57 -0700 From: "Joseph Salowey" To: "'Bernard Aboba'" , Cc: Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Fri, 14 May 2004 08:26:23 -0700 Message-ID: <009f01c439c7$d19a4500$0200000a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.5709 In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 May 2004 15:32:58.0051 (UTC) FILETIME=[BBD13930:01C439C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable So is it possible that session-Id could refer to something other than = the current authentication transaction, or will it be unambiguous? I worry a little about overloading session-id since there can be many = pieces of state each of which can be identified as a separate session. =20 Owner-aaa-wg@merit.edu wrote: >> In addition to Session-Id, we may still need the State attribute to >> distinguish multiple EAP sessions within a single Diameter session, >> if we assume that e.g. reauthentication can keep the same Diameter >> Session-Id. >=20 > Yes. I think in practice that the State attribute is needed > to avoid strange behavior such as for the case we have been > discussing on the EAP WG mailing list (EAPOL restart). From owner-aaa-wg@merit.edu Fri May 14 11:46:58 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 LAA28621 for ; Fri, 14 May 2004 11:46:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1353F91242; Fri, 14 May 2004 11:46:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2E4291245; Fri, 14 May 2004 11:46: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 BEE9C91242 for ; Fri, 14 May 2004 11:46:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 913D05920C; Fri, 14 May 2004 11:46: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 092515910D for ; Fri, 14 May 2004 11:46:43 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id D028989875; Fri, 14 May 2004 18:46:25 +0300 (EEST) Message-ID: <40A4E903.6090307@kolumbus.fi> Date: Fri, 14 May 2004 18:42:59 +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: Joseph Salowey Cc: "'Bernard Aboba'" , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... References: <009f01c439c7$d19a4500$0200000a@amer.cisco.com> In-Reply-To: <009f01c439c7$d19a4500$0200000a@amer.cisco.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 I'm starting think that the use of State attribute is the right approach, as it handles the issue for both AAA protocols, and does not overload the Session-Id for yet another purpose. Otherwise I believe the same attributes as listed in RFC 3579 can be used. Joseph Salowey wrote: > So is it possible that session-Id could refer to something other than the > current authentication transaction, or will it be unambiguous? > > I worry a little about overloading session-id since there can be many pieces > of state each of which can be identified as a separate session. > > Owner-aaa-wg@merit.edu wrote: > >>>In addition to Session-Id, we may still need the State attribute to >>>distinguish multiple EAP sessions within a single Diameter session, >>>if we assume that e.g. reauthentication can keep the same Diameter >>>Session-Id. >> >>Yes. I think in practice that the State attribute is needed >>to avoid strange behavior such as for the case we have been >>discussing on the EAP WG mailing list (EAPOL restart). > > > From owner-aaa-wg@merit.edu Fri May 14 15:04: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 PAA14756 for ; Fri, 14 May 2004 15:04:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 131B9912AA; Fri, 14 May 2004 15:02:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9448B912CC; Fri, 14 May 2004 15:02: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 36489912AA for ; Fri, 14 May 2004 15:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0A8259239; Fri, 14 May 2004 15:02:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227]) by segue.merit.edu (Postfix) with ESMTP id 6174059254 for ; Fri, 14 May 2004 15:02:15 -0400 (EDT) Received: from pit.databus.com (localhost [127.0.0.1]) by pit.databus.com (8.12.11/8.12.11) with ESMTP id i4EJ1FPV046944; Fri, 14 May 2004 15:01:15 -0400 (EDT) (envelope-from barney@pit.databus.com) Received: (from barney@localhost) by pit.databus.com (8.12.11/8.12.11/Submit) id i4EJ1F94046943; Fri, 14 May 2004 15:01:15 -0400 (EDT) (envelope-from barney) Date: Fri, 14 May 2004 15:01:15 -0400 From: Barney Wolff To: Joseph Salowey Cc: "'Bernard Aboba'" , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... Message-ID: <20040514190115.GA46000@pit.databus.com> References: <009f01c439c7$d19a4500$0200000a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009f01c439c7$d19a4500$0200000a@amer.cisco.com> User-Agent: Mutt/1.5.6i X-Scanned-By: MIMEDefang 2.39 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, May 14, 2004 at 08:26:23AM -0700, Joseph Salowey wrote: > So is it possible that session-Id could refer to something other than the > current authentication transaction, or will it be unambiguous? As a server owner, how much do you trust the client's implementation to always get it right? Call me paranoid, but I would certainly add on whatever I could to the id to ensure uniqueness. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. From owner-aaa-wg@merit.edu Mon May 17 07:24:21 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 HAA14188 for ; Mon, 17 May 2004 07:24:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69CA791230; Mon, 17 May 2004 07:24:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3569C91231; Mon, 17 May 2004 07:24: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 2D6DB91230 for ; Mon, 17 May 2004 07:24:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 154ED59401; Mon, 17 May 2004 07:24:05 -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 BC1E5593C9 for ; Mon, 17 May 2004 07:23:59 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HBNwH04215 for ; Mon, 17 May 2004 14:23:58 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 14:22:13 +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 i4HBMDdF004702 for ; Mon, 17 May 2004 14:22:13 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00JBorQl; Mon, 17 May 2004 14:22:12 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 i4HBM7H02416 for ; Mon, 17 May 2004 14:22:07 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 14:21:57 +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]: Wrapping up Diameter EAP... Date: Mon, 17 May 2004 14:21:58 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3AB7@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ5yraXJHhCtOqPQU6f5NnNBzWRmwCNeglQ From: To: , X-OriginalArrivalTime: 17 May 2004 11:21:58.0029 (UTC) FILETIME=[2A957BD0:01C43C01] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: >=20 > I'm starting think that the use of State attribute > is the right approach, as it handles the issue for > both AAA protocols, and does not overload the > Session-Id for yet another purpose. Otherwise I > believe the same attributes as listed in RFC 3579 > can be used. I agree that using State attribute sounds like a good idea, but I thought Session-Id could replace the rest of the attributes listed in RFC 3579? Or do we want to list them all in Diameter EAP as well? BR, Pasi From owner-aaa-wg@merit.edu Mon May 17 10:56:08 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 KAA26806 for ; Mon, 17 May 2004 10:56:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABA4191229; Mon, 17 May 2004 10:55:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7D61891243; Mon, 17 May 2004 10:55:55 -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 3E8C691229 for ; Mon, 17 May 2004 10:55:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2B93F5941C; Mon, 17 May 2004 10:55:54 -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 4E61E5906C for ; Mon, 17 May 2004 10:55:53 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4HEthgH000780; Mon, 17 May 2004 23:55:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4HEthIx021566; Mon, 17 May 2004 23:55:43 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA21563 ; Mon, 17 May 2004 23:55:43 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA07669; Mon, 17 May 2004 23:55:42 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id XAA16429; Mon, 17 May 2004 23:55:41 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4HEtfEU009032; Mon, 17 May 2004 23:55: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 <0HXV00B2G5GQ9Q@tsbpo1.po.toshiba.co.jp>; Mon, 17 May 2004 23:55:40 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BPjVg-0004Eh-00; Mon, 17 May 2004 07:54:32 -0700 Date: Mon, 17 May 2004 07:54:31 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: To: Bernard Aboba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Message-id: <20040517145431.GE8507@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A6122408@esebe023.ntc.nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, May 14, 2004 at 01:10:40AM -0700, Bernard Aboba wrote: > > In addition to Session-Id, we may still need the State attribute > > to distinguish multiple EAP sessions within a single Diameter session, > > if we assume that e.g. reauthentication can keep the same Diameter > > Session-Id. > > Yes. I think in practice that the State attribute is needed to avoid > strange behavior such as for the case we have been discussing on the EAP > WG mailing list (EAPOL restart). I have a couple of issues when the State attribute/AVP is used for handling the reset operation: - What the Diameter EAP client (i.e., the NAS) should do when EAP is reset while it has an outstanding DER? (a) Can the Diameter EAP client immediately send a new DER used for restarting EAP conversation without waiting for a DEA for the outstanding DER, or (b) Should the Diameter EAP client wait for a DEA for the outstanding DER before sending a new DER used for restarting EAP conversation? - In the case of a), it might be possible that the Diameter EAP client receives a DEA for the previously outstanding DER after it has sent a new DER used for restarting EAP conversation. How can the Diameter EAP client distinguish between the DEA for the previously outstanding DER and the DEA for the new DER? Regards, Yoshihiro Ohba From owner-aaa-wg@merit.edu Mon May 17 11:28:29 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 LAA28330 for ; Mon, 17 May 2004 11:28:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75B3391244; Mon, 17 May 2004 11:28:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 493FC91247; Mon, 17 May 2004 11:28: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 3D64591244 for ; Mon, 17 May 2004 11:28:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2D6105942B; Mon, 17 May 2004 11:28:13 -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 48E6B59428 for ; Mon, 17 May 2004 11:28:12 -0400 (EDT) Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HFSAH26907; Mon, 17 May 2004 18:28:11 +0300 (EET DST) X-Scanned: Mon, 17 May 2004 18:27:56 +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 i4HFRuhC032565; Mon, 17 May 2004 18:27:56 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003a0g45; Mon, 17 May 2004 18:27:55 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4HFRoH03822; Mon, 17 May 2004 18:27:50 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 17 May 2004 18:27:49 +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="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Mon, 17 May 2004 18:27:49 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612240B@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ8Hz63saAouG5YTqGLL3KbLO6cNAAAHe5Q From: To: , X-OriginalArrivalTime: 17 May 2004 15:27:49.0664 (UTC) FILETIME=[833E5A00:01C43C23] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Yoshihiro Ohba wrote : >=20 > I have a couple of issues when the State attribute/AVP is used for > handling the reset operation: >=20 > - What the Diameter EAP client (i.e., the NAS) should do when EAP is > reset while it has an outstanding DER? (a) Can the Diameter EAP > client immediately send a new DER used for restarting EAP conversation > without waiting for a DEA for the outstanding DER, or (b) Should the > Diameter EAP client wait for a DEA for the outstanding DER before > sending a new DER used for restarting EAP conversation? This seems to be related to the question when the NAS should pick a new Session-Id... I think that at least (a) with a new=20 Session-Id would be one reasonable choice. But is (a) with the same Session-Id ok? The state machine in RFC3588 doesn't seem to consider multi-round authentication at all, so it's not very clear... > - In the case of a), it might be possible that the Diameter EAP client > receives a DEA for the previously outstanding DER after it has sent a > new DER used for restarting EAP conversation. How can the Diameter > EAP client distinguish between the DEA for the previously outstanding > DER and the DEA for the new DER? Even if the same Session-Id was used, the "Hop-by-hop Identifier"=20 in the Diameter header can match responses to requests. Best regards, Pasi From owner-aaa-wg@merit.edu Mon May 17 13:03:29 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 NAA05313 for ; Mon, 17 May 2004 13:03:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8754791232; Mon, 17 May 2004 13:02:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B12C91249; Mon, 17 May 2004 13:02: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 07F0E91232 for ; Mon, 17 May 2004 13:02:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD8F0591DB; Mon, 17 May 2004 13:02:18 -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 D4BE058C8D for ; Mon, 17 May 2004 13:02:17 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4HH2GgH015259; Tue, 18 May 2004 02:02:16 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4HH2Gge005890; Tue, 18 May 2004 02:02:16 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA05889 ; Tue, 18 May 2004 02:02:16 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA18455; Tue, 18 May 2004 02:02:16 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id CAA25242; Tue, 18 May 2004 02:02:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4HH2FEU017478; Tue, 18 May 2004 02:02:15 +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 <0HXV00G34BBNT6@tsbpo1.po.toshiba.co.jp>; Tue, 18 May 2004 02:02:14 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BPlUF-0004gr-00; Mon, 17 May 2004 10:01:11 -0700 Date: Mon, 17 May 2004 10:01:11 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: <052E0C61B69C3741AFA5FE88ACC775A612240B@esebe023.ntc.nokia.com> To: Pasi.Eronen@nokia.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Message-id: <20040517170111.GG8507@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A612240B@esebe023.ntc.nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, May 17, 2004 at 06:27:49PM +0300, Pasi.Eronen@nokia.com wrote: > Yoshihiro Ohba wrote : > > > > I have a couple of issues when the State attribute/AVP is used for > > handling the reset operation: > > > > - What the Diameter EAP client (i.e., the NAS) should do when EAP is > > reset while it has an outstanding DER? (a) Can the Diameter EAP > > client immediately send a new DER used for restarting EAP conversation > > without waiting for a DEA for the outstanding DER, or (b) Should the > > Diameter EAP client wait for a DEA for the outstanding DER before > > sending a new DER used for restarting EAP conversation? > > This seems to be related to the question when the NAS should > pick a new Session-Id... I think that at least (a) with a new > Session-Id would be one reasonable choice. With using a new Session-Id how the EAP server can choose which EAP session to restart (I guess a State AVP should be included in the DER that is used for restarting the EAP conversation for this purpose)? > > But is (a) with the same Session-Id ok? The state machine > in RFC3588 doesn't seem to consider multi-round authentication > at all, so it's not very clear... That is true even during the normal EAP conversation. For example, Open Diameter implementation came up with modifying the Diameter session state machine to deal with multi-round authentication (we realized this after RFC3588 has been issued). > > > - In the case of a), it might be possible that the Diameter EAP client > > receives a DEA for the previously outstanding DER after it has sent a > > new DER used for restarting EAP conversation. How can the Diameter > > EAP client distinguish between the DEA for the previously outstanding > > DER and the DEA for the new DER? > > Even if the same Session-Id was used, the "Hop-by-hop Identifier" > in the Diameter header can match responses to requests. OK. Yoshihiro Ohba > > Best regards, > Pasi From owner-aaa-wg@merit.edu Tue May 18 03:24: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 DAA20593 for ; Tue, 18 May 2004 03:24:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CA089125C; Tue, 18 May 2004 03:24:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 662549125D; Tue, 18 May 2004 03:24: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 582649125C for ; Tue, 18 May 2004 03:24:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 402BC5943B; Tue, 18 May 2004 03:24: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 4FEF659428 for ; Tue, 18 May 2004 03:24:00 -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 i4I7Nde20487; Tue, 18 May 2004 10:23:39 +0300 (EET DST) X-Scanned: Tue, 18 May 2004 10:22:06 +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 i4I7M6kx012826; Tue, 18 May 2004 10:22:06 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00IabQ0U; Tue, 18 May 2004 10:22:05 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 i4I7LvH11381; Tue, 18 May 2004 10:21:57 +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); Tue, 18 May 2004 10:21: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, 18 May 2004 10:21:55 +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="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Tue, 18 May 2004 10:21:55 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ8MOT27VwMM17tQaGlNbmRLmZaUwAdURJA From: To: Cc: X-OriginalArrivalTime: 18 May 2004 07:21:55.0159 (UTC) FILETIME=[CC37AE70:01C43CA8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Yoshihiro Ohba wrote: >>> - What the Diameter EAP client (i.e., the NAS) should do=20 >>> when EAP is reset while it has an outstanding DER? (a) Can=20 >>> the Diameter EAP client immediately send a new DER used for=20 >>> restarting EAP conversation without waiting for a DEA for the=20 >>> outstanding DER, or (b) Should the Diameter EAP client wait for=20 >>> a DEA for the outstanding DER before sending a new DER used for=20 >>> restarting EAP conversation? >>=20 >> This seems to be related to the question when the NAS should >> pick a new Session-Id... I think that at least (a) with a new=20 >> Session-Id would be one reasonable choice. >=20 > With using a new Session-Id how the EAP server can choose which=20 > EAP session to restart (I guess a State AVP should be included=20 > in the DER that is used for restarting the EAP conversation for=20 > this purpose)? Does the EAP server even need to know which EAP session to restart? =20 It does not seem to need any information from the old EAP session, and the state allocated it will eventually time out and get freed. I'm quite sure that the State AVP should not be included, because after all we've been talking about using the _lack_ of a State AVP=20 to signal a restarted EAP session... Best regards, Pasi From owner-aaa-wg@merit.edu Tue May 18 07:48: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 HAA07036 for ; Tue, 18 May 2004 07:48:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2513E91261; Tue, 18 May 2004 07:48:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E09ED91263; Tue, 18 May 2004 07:48:05 -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 99ED691261 for ; Tue, 18 May 2004 07:48:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 80ADE593B7; Tue, 18 May 2004 07:48:04 -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 93D7F591BA for ; Tue, 18 May 2004 07:48:03 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4IBm2gH000838; Tue, 18 May 2004 20:48:02 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4IBm2g3005425; Tue, 18 May 2004 20:48:02 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id WAA05424 ; Tue, 18 May 2004 20:48:01 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id UAA24837; Tue, 18 May 2004 20:48:01 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id UAA00096; Tue, 18 May 2004 20:48:00 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4IBm0EU017426; Tue, 18 May 2004 20:48:00 +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 <0HXW005IGRFWMW@tsbpo1.po.toshiba.co.jp>; Tue, 18 May 2004 20:47:59 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BQ33m-0006xm-00; Tue, 18 May 2004 04:47:02 -0700 Date: Tue, 18 May 2004 04:47:02 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> To: Pasi.Eronen@nokia.com Cc: yohba@tari.toshiba.com, aaa-wg@merit.edu Message-id: <20040518114702.GP8507@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, May 18, 2004 at 10:21:55AM +0300, Pasi.Eronen@nokia.com wrote: > Yoshihiro Ohba wrote: > > >>> - What the Diameter EAP client (i.e., the NAS) should do > >>> when EAP is reset while it has an outstanding DER? (a) Can > >>> the Diameter EAP client immediately send a new DER used for > >>> restarting EAP conversation without waiting for a DEA for the > >>> outstanding DER, or (b) Should the Diameter EAP client wait for > >>> a DEA for the outstanding DER before sending a new DER used for > >>> restarting EAP conversation? > >> > >> This seems to be related to the question when the NAS should > >> pick a new Session-Id... I think that at least (a) with a new > >> Session-Id would be one reasonable choice. > > > > With using a new Session-Id how the EAP server can choose which > > EAP session to restart (I guess a State AVP should be included > > in the DER that is used for restarting the EAP conversation for > > this purpose)? > > Does the EAP server even need to know which EAP session to restart? > It does not seem to need any information from the old EAP session, > and the state allocated it will eventually time out and get freed. > I'm quite sure that the State AVP should not be included, because > after all we've been talking about using the _lack_ of a State AVP > to signal a restarted EAP session... Now I see what you suggest and I think that is good. Then a State AVP is not needed for distinguishing a restarted EAP session from a continuing EAP session, and thus the AVP does not need to be carried even for a continueing EAP session, right? A State AVP might be used for some other purposes but I don't care about it. BTW, in the suggested scheme, a Diameter EAP client implementation may send a STR to quickly terminate the old EAP session while sending a DER for a new (restarted) EAP session, instead of waiting for the old EAP session to time out and get freed. Yoshihiro Ohba > > Best regards, > Pasi From owner-aaa-wg@merit.edu Tue May 18 08:22: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 IAA08667 for ; Tue, 18 May 2004 08:22:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DDE1591265; Tue, 18 May 2004 08:22:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A58391264; Tue, 18 May 2004 08:22:16 -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 5E9A69123B for ; Tue, 18 May 2004 08:22:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 38B7D59447; Tue, 18 May 2004 08:22:15 -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 5628B58FA8 for ; Tue, 18 May 2004 08:22:14 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1B09A8984C; Tue, 18 May 2004 15:21:56 +0300 (EEST) Message-ID: <40A9FF0D.8080803@kolumbus.fi> Date: Tue, 18 May 2004 15:18:21 +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: Yoshihiro Ohba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> In-Reply-To: <20040518114702.GP8507@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > On Tue, May 18, 2004 at 10:21:55AM +0300, Pasi.Eronen@nokia.com wrote: > >>Yoshihiro Ohba wrote: >> >> >>>>>- What the Diameter EAP client (i.e., the NAS) should do >>>>>when EAP is reset while it has an outstanding DER? (a) Can >>>>>the Diameter EAP client immediately send a new DER used for >>>>>restarting EAP conversation without waiting for a DEA for the >>>>>outstanding DER, or (b) Should the Diameter EAP client wait for >>>>>a DEA for the outstanding DER before sending a new DER used for >>>>>restarting EAP conversation? >>>> >>>>This seems to be related to the question when the NAS should >>>>pick a new Session-Id... I think that at least (a) with a new >>>>Session-Id would be one reasonable choice. >>> >>>With using a new Session-Id how the EAP server can choose which >>>EAP session to restart (I guess a State AVP should be included >>>in the DER that is used for restarting the EAP conversation for >>>this purpose)? >> >>Does the EAP server even need to know which EAP session to restart? >>It does not seem to need any information from the old EAP session, >>and the state allocated it will eventually time out and get freed. >>I'm quite sure that the State AVP should not be included, because >>after all we've been talking about using the _lack_ of a State AVP >>to signal a restarted EAP session... > > > Now I see what you suggest and I think that is good. Then a State AVP > is not needed for distinguishing a restarted EAP session from a > continuing EAP session, and thus the AVP does not need to be carried > even for a continueing EAP session, right? A State AVP might be used > for some other purposes but I don't care about it. > > BTW, in the suggested scheme, a Diameter EAP client implementation may > send a STR to quickly terminate the old EAP session while sending a > DER for a new (restarted) EAP session, instead of waiting for the old > EAP session to time out and get freed. Sure. But if we want this to work with RADIUS too, I'm not sure we have other alternatives than signaling with the presence or lack of the State AVP. --Jari From owner-aaa-wg@merit.edu Tue May 18 08:59:30 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 IAA11760 for ; Tue, 18 May 2004 08:59:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27C3291228; Tue, 18 May 2004 08:59:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E37869123B; Tue, 18 May 2004 08:59: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 7A11891228 for ; Tue, 18 May 2004 08:59:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6266059044; Tue, 18 May 2004 08:59:14 -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 55A665911A for ; Tue, 18 May 2004 08:59:13 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4ICx8gH006512; Tue, 18 May 2004 21:59:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4ICx8fc003403; Tue, 18 May 2004 21:59:08 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id XAA03402 ; Tue, 18 May 2004 21:59:08 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id VAA03664; Tue, 18 May 2004 21:59:08 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id VAA23936; Tue, 18 May 2004 21:59:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4ICx6EU003508; Tue, 18 May 2004 21:59:06 +0900 (JST) Received: from steelhead (iVPN01-140.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HXW00703UQF3Y@tsbpo1.po.toshiba.co.jp>; Tue, 18 May 2004 21:59:05 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BQ4BB-0007DL-00; Tue, 18 May 2004 05:58:45 -0700 Date: Tue, 18 May 2004 05:58:44 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: <40A9FF0D.8080803@kolumbus.fi> To: Jari Arkko Cc: Yoshihiro Ohba , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Message-id: <20040518125844.GR8507@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, May 18, 2004 at 03:18:21PM +0300, Jari Arkko wrote: > Yoshihiro Ohba wrote: > > On Tue, May 18, 2004 at 10:21:55AM +0300, Pasi.Eronen@nokia.com wrote: > > > >>Yoshihiro Ohba wrote: > >> > >> > >>>>>- What the Diameter EAP client (i.e., the NAS) should do > >>>>>when EAP is reset while it has an outstanding DER? (a) Can > >>>>>the Diameter EAP client immediately send a new DER used for > >>>>>restarting EAP conversation without waiting for a DEA for the > >>>>>outstanding DER, or (b) Should the Diameter EAP client wait for > >>>>>a DEA for the outstanding DER before sending a new DER used for > >>>>>restarting EAP conversation? > >>>> > >>>>This seems to be related to the question when the NAS should > >>>>pick a new Session-Id... I think that at least (a) with a new > >>>>Session-Id would be one reasonable choice. > >>> > >>>With using a new Session-Id how the EAP server can choose which > >>>EAP session to restart (I guess a State AVP should be included > >>>in the DER that is used for restarting the EAP conversation for > >>>this purpose)? > >> > >>Does the EAP server even need to know which EAP session to restart? > >>It does not seem to need any information from the old EAP session, > >>and the state allocated it will eventually time out and get freed. > >>I'm quite sure that the State AVP should not be included, because > >>after all we've been talking about using the _lack_ of a State AVP > >>to signal a restarted EAP session... > > > > > > Now I see what you suggest and I think that is good. Then a State AVP > > is not needed for distinguishing a restarted EAP session from a > > continuing EAP session, and thus the AVP does not need to be carried > > even for a continueing EAP session, right? A State AVP might be used > > for some other purposes but I don't care about it. > > > > BTW, in the suggested scheme, a Diameter EAP client implementation may > > send a STR to quickly terminate the old EAP session while sending a > > DER for a new (restarted) EAP session, instead of waiting for the old > > EAP session to time out and get freed. > > Sure. But if we want this to work with RADIUS too, I'm not sure we > have other alternatives than signaling with the presence or lack of > the State AVP. I don't think we need to define the same method for RADIUS and Diameter to support EAP restart. Diameter can be smarter as it has Session-Id and is able to terminate a session. Yoshihiro Ohba > > --Jari From owner-aaa-wg@merit.edu Tue May 18 10:04: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 KAA15661 for ; Tue, 18 May 2004 10:04:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9CF6C91264; Tue, 18 May 2004 10:04:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70D0D91268; Tue, 18 May 2004 10:04: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 7B16591264 for ; Tue, 18 May 2004 10:03:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58C4B593BF; Tue, 18 May 2004 10:03:59 -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 DB77E59240 for ; Tue, 18 May 2004 10:03:58 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0D37289878; Tue, 18 May 2004 17:03:57 +0300 (EEST) Message-ID: <40AA16F6.2010403@kolumbus.fi> Date: Tue, 18 May 2004 17:00:22 +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: Yoshihiro Ohba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> <20040518125844.GR8507@steelhead> In-Reply-To: <20040518125844.GR8507@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > I don't think we need to define the same method for RADIUS and > Diameter to support EAP restart. Diameter can be smarter as it has > Session-Id and is able to terminate a session. Ok. That's reasonable. But are you saying 1) We don't need Diameter and RADIUS to interoperate upon EAP restart. or 2) If we use Session-Id to support EAP restart in Diameter, we can make that work also through a D-R gateway so that it works even in RADIUS, which has to use State attribute? I'd be happy with alt 2, but has someone looked at the details, and can we make it work? I would rather not have alt 1 myself. --Jari From owner-aaa-wg@merit.edu Tue May 18 11:08: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 LAA21770 for ; Tue, 18 May 2004 11:08:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AAEB91263; Tue, 18 May 2004 11:07:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC57991268; Tue, 18 May 2004 11:07: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 7508191263 for ; Tue, 18 May 2004 11:07:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E9CF59447; Tue, 18 May 2004 11:07:51 -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 7EF4159436 for ; Tue, 18 May 2004 11:07:50 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4IF7fgH002304; Wed, 19 May 2004 00:07:41 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4IF7eB5024119; Wed, 19 May 2004 00:07:40 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id AAA24118 ; Wed, 19 May 2004 00:07:40 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp id AAA00668; Wed, 19 May 2004 00:07:40 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id AAA09191; Wed, 19 May 2004 00:07:40 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4IF7dEU010276; Wed, 19 May 2004 00:07:39 +0900 (JST) Received: from steelhead (iVPN01-127.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HXX00DZT0OOW9@tsbpo1.po.toshiba.co.jp>; Wed, 19 May 2004 00:07:38 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BQ6Ba-0007lh-00; Tue, 18 May 2004 08:07:18 -0700 Date: Tue, 18 May 2004 08:07:17 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-reply-to: <40AA16F6.2010403@kolumbus.fi> To: Jari Arkko Cc: Yoshihiro Ohba , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Message-id: <20040518150717.GB29343@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> <20040518125844.GR8507@steelhead> <40AA16F6.2010403@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, May 18, 2004 at 05:00:22PM +0300, Jari Arkko wrote: > Yoshihiro Ohba wrote: > > > I don't think we need to define the same method for RADIUS and > > Diameter to support EAP restart. Diameter can be smarter as it has > > Session-Id and is able to terminate a session. > > Ok. That's reasonable. But are you saying > > 1) We don't need Diameter and RADIUS to interoperate upon EAP restart. > > or > > 2) If we use Session-Id to support EAP restart in Diameter, we can > make that work also through a D-R gateway so that it works even in > RADIUS, which has to use State attribute? > > I'd be happy with alt 2, but has someone looked at the details, > and can we make it work? I also support alt 2. I think translation between RADIUS and Diameter can be done in the following way (assuming that a State AVP is always carried in RADIUS Access-Answer and Access-Accept messages when an EAP-Message attribute is carried): - Translation from DER to RADIUS Access-Request: If the translation agent receives a DER with a new Session-Id, then it generates a RADIUS Access-Request without a State attribute. The RADIUS server will treat the request as a signal to restart the EAP session if the NAS and session identification attributes corresponds to an existing EAP session. If the translation agent receives a DER with an existing Session-Id, then it generates a RADIUS Access-Request with a State attribute that was contained in the message that was previously sent by the RADIUS server. - Translation from RADIUS Access-Request to DER: If the translation agent receives a RADIUS Access-Request without a State attribute, then it creates a new Diameter session and generates a DER with a new Session-Id. If the translation agent receives a RADIUS Access-Request with a State attribute as well as the NAS and session identification attributes corresponding to an existing EAP session, then it generates a DER with the corresponding Session-Id. But I am pretty sure Pasi will come up with better text. :) Yoshihiro Ohba > > I would rather not have alt 1 myself. > > --Jari From owner-aaa-wg@merit.edu Tue May 18 13:07:29 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 NAA27979 for ; Tue, 18 May 2004 13:07:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 874F791268; Tue, 18 May 2004 13:04:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 156D39123E; Tue, 18 May 2004 13:04: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 C19CE91268 for ; Tue, 18 May 2004 13:03:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B81F58FBF; Tue, 18 May 2004 13:03:26 -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 DC8BF59188 for ; Tue, 18 May 2004 13:03:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4IH6Lc25710; Tue, 18 May 2004 10:06:21 -0700 Date: Tue, 18 May 2004 10:06:20 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Yoshihiro Ohba , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP.. In-Reply-To: <40AA16F6.2010403@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> <20040518125844.GR8507@steelhead> <40AA16F6.2010403@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > 2) If we use Session-Id to support EAP restart in Diameter, we can > make that work also through a D-R gateway so that it works even in > RADIUS, which has to use State attribute? I think it is ok for the Diameter NAS to send *both* State and Session-Id, no? Doesn't NASREQ require the Diameter client to respond with State if it's included in the Diameter Answer? If the Diameter client doesn't respond with State, I think this would break both Diameter EAP and NASREQ NASen for compatiblity with a RADIUS server, no? From owner-aaa-wg@merit.edu Tue May 18 16:01:41 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 QAA11033 for ; Tue, 18 May 2004 16:01:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA41391271; Tue, 18 May 2004 16:01:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85C3A91272; Tue, 18 May 2004 16:01: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 2894791271 for ; Tue, 18 May 2004 16:01:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1339559066; Tue, 18 May 2004 16:01:21 -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 DDAC8590C3 for ; Tue, 18 May 2004 16:01:19 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i4IK17gH026826; Wed, 19 May 2004 05:01:07 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i4IK17iF008168; Wed, 19 May 2004 05:01:07 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id FAA08167 ; Wed, 19 May 2004 05:01:07 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id FAA18610; Wed, 19 May 2004 05:01:06 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id FAA03110; Wed, 19 May 2004 05:01:06 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i4IK15EU013518; Wed, 19 May 2004 05:01: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 <0HXX001RPE9PVA@tsbpo1.po.toshiba.co.jp>; Wed, 19 May 2004 05:01:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1BQAlL-0000KZ-00; Tue, 18 May 2004 13:00:31 -0700 Date: Tue, 18 May 2004 13:00:31 -0700 From: Yoshihiro Ohba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP.. In-reply-to: To: Bernard Aboba Cc: Jari Arkko , Yoshihiro Ohba , Pasi.Eronen@nokia.com, aaa-wg@merit.edu Message-id: <20040518200031.GX8507@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6i References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> <20040518125844.GR8507@steelhead> <40AA16F6.2010403@kolumbus.fi> Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, May 18, 2004 at 10:06:20AM -0700, Bernard Aboba wrote: > > 2) If we use Session-Id to support EAP restart in Diameter, we can > > make that work also through a D-R gateway so that it works even in > > RADIUS, which has to use State attribute? > > I think it is ok for the Diameter NAS to send *both* State and Session-Id, > no? > > Doesn't NASREQ require the Diameter client to respond with State if it's > included in the Diameter Answer? > > If the Diameter client doesn't respond with State, I think this would > break both Diameter EAP and NASREQ NASen for compatiblity with a RADIUS > server, no? I think inclusion of a State AVP in DER/DEA is needed only when there is a RADIUS server or proxy on the signaling path, but in this case the State AVP is used only for restarting EAP session, but not for some other purposes. On the other hand, when all AAA nodes on the path is Diameter nodes, the State AVP is not needed and the AVP could be used for some other purposes. (So Diameter only network could provide more flexibility.) Regards, Yoshihiro Ohba From owner-aaa-wg@merit.edu Thu May 20 04:03: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 EAA04005 for ; Thu, 20 May 2004 04:03:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5238F912AC; Thu, 20 May 2004 04:02:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D7DC912AD; Thu, 20 May 2004 04:02:53 -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 079B1912AC for ; Thu, 20 May 2004 04:02:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7E31592A0; Thu, 20 May 2004 04:02:51 -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 41746594E2 for ; Thu, 20 May 2004 04:02:51 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id F12C289865; Thu, 20 May 2004 11:02:43 +0300 (EEST) Message-ID: <40AC654B.1070806@kolumbus.fi> Date: Thu, 20 May 2004 10:59:07 +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: Yoshihiro Ohba Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu, Bernard Aboba Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A612240C@esebe023.ntc.nokia.com> <20040518114702.GP8507@steelhead> <40A9FF0D.8080803@kolumbus.fi> <20040518125844.GR8507@steelhead> <40AA16F6.2010403@kolumbus.fi> <20040518150717.GB29343@steelhead> In-Reply-To: <20040518150717.GB29343@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: > I also support alt 2. I think translation between RADIUS and Diameter > can be done in the following way (assuming that a State AVP is always > carried in RADIUS Access-Answer and Access-Accept messages when an > EAP-Message attribute is carried): We can say that this is necessary for the translation and restart to work, and point out that currently RFC 3579 does not require State to be used. > - Translation from DER to RADIUS Access-Request: > > If the translation agent receives a DER with a new Session-Id, then it > generates a RADIUS Access-Request without a State attribute. The > RADIUS server will treat the request as a signal to restart the EAP > session if the NAS and session identification attributes corresponds > to an existing EAP session. > > If the translation agent receives a DER with an existing Session-Id, > then it generates a RADIUS Access-Request with a State attribute that > was contained in the message that was previously sent by the RADIUS > server. > > - Translation from RADIUS Access-Request to DER: > > If the translation agent receives a RADIUS Access-Request without a > State attribute, then it creates a new Diameter session and > generates a DER with a new Session-Id. > > If the translation agent receives a RADIUS Access-Request with a State > attribute as well as the NAS and session identification attributes > corresponding to an existing EAP session, then it generates a DER with > the corresponding Session-Id. This works for me. --Jari From owner-aaa-wg@merit.edu Thu May 20 10:40: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 KAA21045 for ; Thu, 20 May 2004 10:40:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6483491203; Thu, 20 May 2004 10:40:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 383E791205; Thu, 20 May 2004 10:40: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 365C591203 for ; Thu, 20 May 2004 10:40:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F9CD5950A; Thu, 20 May 2004 10:40:14 -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 86B9D594F6 for ; Thu, 20 May 2004 10:40:13 -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 i4KEe7J08131 for ; Thu, 20 May 2004 10:40:07 -0400 (EDT) Date: Thu, 20 May 2004 10:40:07 -0400 (EDT) Message-Id: <200405201440.i4KEe7J08131@zrtps06s.nortelnetworks.com> Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 May 2004 10:40:07 -0400 Received: from nortelnetworks.com ([47.102.185.233] RDNS failed) by zrc2hxm2.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 20 May 2004 09:39:52 -0500 From: Joe Harvell To: aaa-wg@merit.edu Sender: owner-aaa-wg@merit.edu Precedence: bulk Microsoft Mail Internet Headers Version 2.0 Message-ID: <40ACC336.7020105@nortelnetworks.com> Date: Thu, 20 May 2004 14:39:50 +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: test Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: harvell@nortelnetworks.com X-OriginalArrivalTime: 20 May 2004 14:39:52.0504 (UTC) FILETIME=[4F8FD380:01C43E78] I was expecting this post to fail. Sorry for the inconvenience if it actually went through. From administrator@educationadmin.org Sun May 23 06:05:24 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08488 for ; Sun, 23 May 2004 06:05:24 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BRprA-0003Qp-1K for aaa-archive@ietf.org; Sun, 23 May 2004 06:05:24 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BRpqH-0003Af-00 for aaa-archive@ietf.org; Sun, 23 May 2004 06:04:30 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BRppc-0002uD-00 for aaa-archive@ietf.org; Sun, 23 May 2004 06:03:48 -0400 Received: from [209.120.176.8] (helo=kljjn-xy6ur8w93) by mx2.foretec.com with esmtp (Exim 4.24) id 1BRppf-0003av-Gv for aaa-archive@ietf.org; Sun, 23 May 2004 06:03:51 -0400 From: "Admin" Subject: ADV: Attention All School Staff: Teachers, Students and Faculty Members: To: aaa-archive@ietf.org Content-Type: multipart/alternative; boundary="=_NextPart_2rfkindysadvnqw3nerasdf" MIME-Version: 1.0 Reply-To: administrator@educationadmin.org Date: Sun, 23 May 2004 05:00:20 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2616 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=12.3 required=5.0 tests=ADVERT_CODE, FORGED_MUA_OUTLOOK,FORGED_OUTLOOK_HTML,FRONTPAGE,HTML_40_50, HTML_MESSAGE,LARGE_HEX,MIME_BOUND_NEXTPART,MIME_BOUND_RKFINDY, MIME_HTML_ONLY,MIME_HTML_ONLY_MULTI,NORMAL_HTTP_TO_IP autolearn=no version=2.60 X-Spam-Report: * 2.8 MIME_BOUND_RKFINDY Spam tool pattern in MIME boundary (rfkindy) * 1.6 ADVERT_CODE Subject: starts with advertising tag * 1.6 LARGE_HEX BODY: Contains a large block of hexadecimal code * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 1.6 FRONTPAGE BODY: Frontpage used to create the message * 0.2 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL * 1.1 FORGED_OUTLOOK_HTML Outlook can't send HTML message only * 0.2 MIME_BOUND_NEXTPART Spam tool pattern in MIME boundary * 1.1 MIME_HTML_ONLY_MULTI Multipart message only has text/html MIME parts * 1.6 FORGED_MUA_OUTLOOK Forged mail pretending to be from MS Outlook This is a multi-part message in MIME format --=_NextPart_2rfkindysadvnqw3nerasdf Content-Type: text/html Content-Transfer-Encoding: 7bit Attention All Staff

Attention All School Staff: Teachers, Students and Faculty Members:

You Must Respond By 5 P.M. Tuesday, May 25, 2004.

Through a special arrangement, Avtech Direct is offering a limited
allotment of BRAND NEW, top of-the-line, name-brand desktop computers
at more than 50% off MSRP to all Teachers, Students,Faculty and Staff,
who respond to this message before 5 P.M., Tuesday, May 25, 2004.

All desktop are brand-new, packed in their original boxes, and come
with a full manufacturer's warranty plus a 100% satisfaction guarantee.

These professional grade Desktops are fully equipped with 2004
next generation technology, making these the best performing
computers money can buy.

Avtech Direct is offering these feature rich, top performing
Desktop Computers with the latest Intel technology at an amazing price
to all who call:

1-800-884-9510 by 5 P.M. Tuesday, May 25, 2004
The fast and powerful AT-2400 series Desktop features:

        * Intel 2.0Ghz Processor for amazing speed and performance
        * 128MB DDR RAM, --- Upgradeable to 1024
        * 20 GB UDMA Hard Drive, --- Upgradeable to 80 GB
        * 52X CD-Rom Drive, --- Upgradeable to DVD/CDRW
        * 1.44 Floppy disk drive
        * Next Generation Technology
        * ATI Premium video and sound
        * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0
        * Soft Touch Keyboard and scroll mouse
        * Internet Ready
        * Network Ready
        * 1 Year parts and labor warranty
        * Priority customer service and tech support

MSRP $699 .................................................................... Your Cost $297

    How to qualify:

        1. You must be a Teacher, Student, Faculty or Staff Member:
        2. All desktop computers will be available on a first come first serve basis.
        3. You must call 1-800-884-9510 by 5 P.M. Tuesday, May 25, 2004
            and we will hold the desktops you request on will call.
        4. You are not obligated in any way.
        5. 100% Satisfaction Guaranteed.


Call Avtech Direct
1-800-884-9510 before 5 P.M. Tuesday, May 25, 2004

 

 

Avtech Direct
22647 Ventura Blvd., Suite 374
Woodland Hills, CA 91364
 



Avtech Direct · 22647 Ventura Blvd. #104 · Woodland Hills, CA 91364

--=_NextPart_2rfkindysadvnqw3nerasdf-- From owner-aaa-wg@merit.edu Mon May 24 07:25: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 HAA27980 for ; Mon, 24 May 2004 07:25:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 008339123E; Mon, 24 May 2004 07:25:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B833C9123C; Mon, 24 May 2004 07:25: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 7481391241 for ; Mon, 24 May 2004 07:25:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5847459265; Mon, 24 May 2004 07:25:26 -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 1F98D59544 for ; Mon, 24 May 2004 07:25:25 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4OBP0o12140; Mon, 24 May 2004 14:25:00 +0300 (EET DST) X-Scanned: Mon, 24 May 2004 14:24:24 +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 i4OBOOXY027391; Mon, 24 May 2004 14:24:24 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00tnDPUb; Mon, 24 May 2004 14:24:22 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 i4OBOKH14637; Mon, 24 May 2004 14:24:20 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 14:24:03 +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]: DCC draft 05: summary of changes Date: Mon, 24 May 2004 14:24:03 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0563@esebe016.ntc.nokia.com> Thread-Topic: DCC draft 05: summary of changes Thread-Index: AcRBgZ5tAA1BmVkKRyqC0x7aado/LA== From: To: Cc: , , , X-OriginalArrivalTime: 24 May 2004 11:24:03.0787 (UTC) FILETIME=[9E6EE1B0:01C44181] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi AAA folks, we published the DCC draft 05 sometime ago but we actually didn't send = the summary of changes, what the AD requested, to the working group. The summary of main changes is given below. If no one objects, the = document=20 should be ready for IESG review. Regards Marco 1- Some of the abbreviations used along the document was expanded (e.g. = SIP --> Session Initiation Protocol). 2- Consistent use of AAA Server and home AAA Diameter Server terminology = along the document: AAA Server to indicate generically the AAA server (RADIUS/Diameter AAA server) and Home AAA = Diameter Server. 3- RADIUS Interworking section reworked according to DCC issue 33. = RADIUS related text in section 2 moved to the interworking section. 4- Added reference in section 2 to the RFC 3588 section 2.8 where the = roles of Diameter agents are defined. 5- Added reference in section 3 to the RFC 3588 section 3.2 where the = ABNF of the command is defined. 6- Section 4.1: added rules how to include RADIUS vendor specific = attributes in service specific documents as discussed in=20 aaa mailing-list = (http://www.merit.edu/mail.archives/aaa-wg/msg00537.html). When service specific documents include RADIUS vendor specific = attributes that could be used as input in the rating=20 process, the rules described in [NASREQ] for formatting the = Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the = Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The = Diameter AVP data field contains only the attribute=20 value of the RADIUS attribute. 7- Clarified in section 5.1 the applicability of the basic tariff time = change mechanism for time based services as discussed in the mailing list = (http://www.merit.edu/mail.archives/aaa-wg/msg00414.html). 8- Added in section 5.1.1 better explanation of rating-group and = service-identifier as well as graphical representation of the relation between service-identifiers, rating-groups, credit pools = and credit-control (sub-)session, as requested by AD review. 9- Rewrite of second paragraph in section 5.5 to clarify server = initiated re-authorization at different granularirty, as requested by AD review. 10- Section 5.7: rewrite of sixth paragraph to clarify the reason of Tx = definition. Requested by AD review. 11- Section 7: added following sentence to clarify why stop Tx action is = not mentioned when moving to Idle state. The Tx timer, which is used to control the waiting time in the = Credit control client in the PENDING state, is stopped when exiting the Pending state. The stopping of the Tx timer = is omitted in the state machine when the new state is=20 Idle since moving to Idle state implies the clearing of the = session and all the variables associated to it. 12- Section 7: Diameter DCC server state machine clarified for one-time = event (http://www.merit.edu/mail.archives/aaa-wg/msg00575.html). More can be found from the below extract of the conversation we = (authors) had with the AD. > > > > > One thing I did notice in various ABNF specifications=20 > in sect 8 > > > > > is that you use curly and sqaure brackets seemingly at will. > > > > > Not sure if that is correct... you may want to check. > > > > > It occurs quite a number of times. > > > > >=20 > > > OK, I think I now see that it comes from the base diameter=20 > > spec when=20 > > > <..> fixed AVP spec positions > > > {..} are required AVP specs > > > [..] are optional AVP specs > > >=20 > > > So.. probably this is known/obvious for people who do AAA=20 > > > every day. For > > > the not so AAA-adicted, it might be good to repeat that=20 > sort of info > > > somehwere in the beginning of the doc, or maybe to add a=20 > > > reference about > > > this that it is additional ABNF notation on top of that=20 > in RFC3588? > >=20 > > OK, we will add a note that ABNF notation can be found from the > > RFC3588. > >=20 > great and thanks >=20 >=20 > > > b. On page 23/24 (possibly at other places too), I see=20 > > > several terms used > > > like these: > > > - home Diameter AAA server > > > - home AAA server > > > - home AAA > > > - Diameter AAA server > > > - Diameter home AAA (sect 5.7 and sect 6.5) > > > - AAA server (sect 6.5) > > > - ... > > > Do they all mean the same server? Maybe not. > > > But are ther 4 different types? > > > Pls try to be very consistent when using those terms. > >=20 > > You are right. We'll use AAA server to indicate generically=20 > AAA servers > > (may be RADIUS/DIAMETER AAA) and home Diameter AAA server. > > We'll update consistently the doc. > >=20 > great >=20 > > > c.Sect 5.5 2nd para. > > > (sub-)session level, credit pool level granularity,=20 > > service-identifier > > > level granularity or rating-group granularity. To=20 > > request credit re- > > > authorization at credit pool granularity the server=20 > > includes in the > > > RAR message the G-S-U-Pool-Identifier AVP indicating=20 > > the affected > > > How are sub-sessions and various other "levels"=20 > > defined/identified/known? > > > Maybe I missed that in the doc... Mmm.. you refe to sect=20 > > 5.1.1 but some > > > of the explanation may be in sect 5.1 > > > Mmm.. I see that that sect 5.1.1 is also the section that=20 > > made my eyes glaze=20 > > > over and wonder if all that compelxity is needed. > >=20 > > This level of granularities refer to the sect. 5.1.1. The=20 > server knows > > what is running in the client because it authorized the=20 > credit. What=20 > > service (service-id) or what group of services (rating-group) or > > what pool (pool-id) is authorized it is then known. > > The server may want to request credit re-authorization at different=20 > > level: for the whole pool, just for one service or just for one > > rating-group. > >=20 > > Do you recommend a slight rewrite the 2nd paragraph with a=20 > better explanation and > > perhaps add the definition of those levels in the=20 > terminology section? > >=20 > Probably will help. >=20 >=20 > > > e. Page 36 talks about "AAA server or agent" I guess server=20 > > and agent are > > > meant to be synonyms here? Are they? Why are we=20 > > confiusing people here? > >=20 > > Server and agent are not synonyms in this chapter. There can be > > transport level connection between Clinet and Relay/Proxy agent and > > between Relay/Proxy agent and Server (can be also beteween relay and > > proxy agents), I doesn't need to be direct connection between Client > > and Server. The section 2.5 in RFC3588 clarifies how transport > > connection are set between clients, relays, proxies and servers. > >=20 > So is a "server" never an "agent"? > And is an agent always a "proxy agent" or a "relay agent" ?? > I think that is what I am reading in 3588 sections 2.5 and 2.8. > Maybe a reference to that would help. As you can see I was confused... > probably because I am not a daily reader of AAA or RADIUS text :-( >=20 > > > f. Page 36/37 talks about "increased risk of premature=20 > > failover" and about > > > "congestive collapse". Maybe those risks should be=20 > spelled out in > > > security considerations? In any event it seems quite=20 > > hidden to me the > > > way it is described in a long piece of text. > >=20 > > These are considerations about setting too low value for the=20 > > Tw timer,=20 > > probably copied from RFC 3539, to motivate the introduction=20 > of the Tx > > timer. Perhaps we could rephrase and add a reference to the=20 > RFC 3539. > > What about this? > > =20 > > The AAA transport profile [AAATRANS] defines the application=20 > > layer watchdog algorithm that enables failover from a peer that=20 > > has failed and is controlled by the timer Twinit. The=20 > recommended=20 > > default value for Twinit is 30 seconds. Twinit may be set as low=20 > > as 6 seconds, however, according to [AAATRANS] setting too low=20 > > value for Twinit is likely to result in an increased probability=20 > > of duplicates, as well as an increase in spurious failover and=20 > > failback attempts. Since the Diameter base protocol is common to=20 > > several different types of AAA applications that may be run in=20 > > the same service element, tuning the timer Twinit to a=20 > lower value=20 > > in order to satisfy the requirements of real-time=20 > > applications, such=20 > > as the Diameter Credit Control application, will certainly=20 > > materialize=20 > > the above mentioned problems. For prepaid services, however, the=20 > > end user expects an answer from the network in a=20 > > reasonable time, thus=20 > > the Diameter credit control client shall react faster than the=20 > > underlying base protocol. Therefore this specification=20 > > defines the timer Tx that is used by the credit-control=20 > client (as=20 > > defined in section 13) to supervise the communication with=20 > > the credit- > > control server. When the timer Tx elapses the=20 > > credit-control client=20 > > takes an action to the end user according to the Credit-Control- > > Failure-Handling AVP. > >=20 > That is probably goodness. My main concern was that there was/is no=20 > wording in the security considerations section that points=20 > out this "risk" > COuld be a one or two-liner with a ref to this section. >=20 > > > g. Have the state-diagrams been checked rigorously? > > > For example, page 46. the 3rd and 4th cases, should the=20 > > also not be a > > > Stop Tx action? Also for 7th, 8th, 9th and 10th case on=20 > > that page? > > > I wondered about such things at other places in the=20 > > state diagrams too. > >=20 > > Tx is stopped when exiting the Pending state. Actually we purposely > > omitted the stop Tx action when the new state is Idle because the > > whole session is cleared. Therefore all the states associated with > > the session are cleared too. > >=20 > Maybe that should be a generic piece of text at the beginning of the > section on state diagrams? Then I would have understood. >=20 > > There has been two WGLCs for the draft and in addition to the > > failure handling & state machine have been widely discussed=20 > > on the mailing list, so we think that state-diagrams are=20 > rather good=20 > > shape. > >=20 > OK... as long as you are happy. As I said, I did not walk through them > all in detail. So I am trusting you and the WG. >=20 > > > h. User-Equipment-Info-Type AVP is defined as Unsigned32.=20 > > > I wonder if the type would not better be Enumerated > >=20 > > It seems that we have forgot to update AVP type, when we=20 > > updated the AVP. It should be Enumerated.=20 > >=20 > OK >=20 >=20 > > > k. Section 8.28 in the examples, pls do NOT use "provider.com" and > > > "vendor.com". RFC2606 prescribes to use names like=20 > > > "provider.example.com" > > > and "vendor.example.net" or some such. > > >=20 > >=20 > > We'll update accordingly. > >=20 > good >=20 > > > l. Section 8.46=20 > > > Is it SIP URL in this case, while it is SIP URI in sect 8.38? > >=20 > > Should be SIP URI, we'll correct it. > >=20 > OK >=20 > > > m. I am confused by the AVPs defined in Sect 8.49 and 8.50 > > > 8.49 defines various types. Is the formatting of those values > > > indeed such that they are UTF-8 ? I have not checked.=20 > > May I assume > > > that someone DID check/verify? > >=20 > > Probably you are right. A better data type should be OctetString. > > Should UTF-8 format be needed it can be encoded in an=20 > OctetString AVP. > >=20 > Well, if the AVP is supposed to transport "human readable" material, > then we (IETF) DOES want UTF-8.=20 > If not, then OctetString is probably better. > It is just that I could not quickly see that all possible formats > would be (easily) representable in UTF-8. >=20 > > > n. I assume Bernard (or some RADIUS/DIAMETER expert has=20 > > > checked sect 11 > >=20 > > The comments from WG chairs are covered in the DCC issue 33: > > http://www.merit.edu/mail.archives/aaa-wg/msg00448.html > >=20 > > We'll change the doc. accordingly. > >=20 > good >=20 > > > o. In the IANA considerations you state many times "this=20 > > specification > > > assigns xxx".=20 > > > - first, I suspect that IANA should officially do the=20 > assignment. > > > so it would have been better to say something aka: > > > "Iana has assigned xxx" If you want a specific=20 > value, you can=20 > > > ask IANA to use value xxx. > > > - second, I suspect that IANA needs to add the values to=20 > > the registries > > > on their web pages. You do never tell IANA that they=20 > > indeed need to do > > > that=20 > >=20 > > We can change the language. In practice, we know that IANA=20 > > is overloaded. >=20 > Yeah... I rmember that for the rfc3588 thing. So I can see=20 > why you do this. >=20 > > In setting-up the Diameter IANA registry, I had to write=20 > the complete > > registry for IANA. Life will be more complicated as=20 > several Diameter > > applications will go to RFC shortly, so I thought it=20 > prudent to start > > staking out the values. Do you think this is aproblem. =20 > >=20 > The "propblem" is that if you put in real numbers in an I-D, then some > implementers may start using those numbers before they are actually > approved and assigned. We recently had a serious conflict=20 > because of that > in the RSVP space. So that is my serious concern. >=20 > > I could modify the text: > >=20 > > "this specification assigns xxx".=20 > > to: > >=20 > > "this specification requests that IANA assigns xxx".=20 > > =20 >=20 > I'd probably do it like in tghis format: >=20 > "IANA has assigned xxx for such and such" > [IANA pls fill in xxx (suggested value 123) and remove=20 > this note] >=20 > The "xxx" then also occurs at other places in the document. > Mmm... yep elaborative... but such is our process. > Not sure what is wise. Are we currently absolutely sure that=20 > the values > you used are correct and do not conflict with any other such values in > other IDs or RFCs?? Are we absolutely sure nobody will make us change=20 > things during IETF Last Call and IESG review? >=20 >=20 > > > p. Security considerations. > > > You claim that DIAMBASE not only tells/assume that IPsec=20 > > or TLS are used. > > > But DIAMBASE in fact REQUIRES (MUST language) the=20 > > implementation of IPsec > > > and even explains how to do it (which is important).=20 > > Same for TLS. > > > > > > Second section uses lower case must/shall where I think=20 > > uppercase MUST/SHALL > > > would be appropriate. I also suspect that the last=20 > > sentence of 2nd > > > para may worry/bother security ADs. > > >=20 > > > 3rd para: "economical consequences" ?? DO you mean=20 > "financial" ?? > > >=20 > > > last 2 paragraphs in sect 14 seem weak to me. WOnder=20 > > what sec ADs have to say > > > > >=20 > > We will update section according to your comments. > > Two last paragraphs deal with security threat, which are common to > > all Diameter application and not only to this application, since > > Diameter do not provide application level security. > > =20 > > > sect 14.1 talks about "agent"... is that same as "server"? > > > It also talks about "Diameter Routing Table" ... has=20 > > that term been explained? > > > Last para in sect 14.1 points to an informative reference? > > >=20 > > > I would recommend to have one of the secuirty ADs take a=20 > > > look at this. > > >=20 > >=20 > > "agent" is not same as server, it can be Diameter relay or proxy > > agent.=20 > >=20 > Same concern as above. Add a ref to the proper place in 3588 >=20 > > Diameter routing table has been explained in the RFC3588,=20 > section 2.7. > > We can add reference to that section. > >=20 > Would be good I think >=20 > > Diameter EAP handles this problem much more widely, but we do not > > want to copy all that text here and because the Diameter EAP is also > > work in progress status, we should point to an informative=20 > reference, > > Does this cause problems? > >=20 > Is that draft-ietf-aaa-eap-05.txt ?? > What is the status? > So maybe indeed an informative ref anbd say that that work is=20 > looking at=20 > a more wider solution. >=20 > > > q. I wonder if references to documents that are cited in=20 > > sections 8.x should > > > not all be normative. For example, [RAD802.1X] is=20 > > normative (correctly > > > in my view), but [SIP] is informative (incorrectly in my=20 > > view). [IPv4] > > > and [IPv6Addr] seem normative to me too? > >=20 > > OK, we will do re-checking. > >=20 > >=20 > > We'll also check and updates all the below nits you pointed out. > >=20 > Great, >=20 > Bert > > > --------- > > >=20 > > > Following are mainly nits/admin things: > > >=20 > > > 1. Results if idnits script. Just check, not all of it=20 > means error. > > > But non-ASCII characters is not good. The long lines=20 > > > can/will probably > > > be hadnled by RFC-Editor. But if you can fix it, so much=20 > > > the better. > > > This idnits tool is available at:=20 > > > http://ietf.levkowetz.com/tools/idnits/ > > > $ idnits > > idnits 1.26, (21 Apr 2004) > > >=20 > > > The document seems to use RFC 2026 boilerplate... > > > The document seems to lack an RFC 2026 Section 10.4(C)=20 > > > Permission Grants Notice > > > -- however, there's a paragraph with a matching=20 > > > beginning. Boilerplate error? > > > There are 298 instances of too long lines in the document, > > > -- the longest one being 1 character in excess of 72. > > > Line 1447 contains non-ascii character in position 37. > > > Line 3852 contains non-ascii character in position 49. > > > Line 5336 contains non-ascii character in position 39. > > > Line 5353 contains non-ascii character in position 51. > > > There are 4 instances of lines with non-ascii characters=20 > > > in the document. > > >=20 > > > Warnings: > > > The document seems to lack an RFC 2026 Section 10.4(B)=20 > > > IPR Disclosure Invitation > > > There are 178 instances of lines with hyphenated line=20 > > > breaks in the document. > > >=20 > > > Line 2285 has weird spacing: '...quested to en...' > > > Line 2295 has weird spacing: '...mporary end ...' > > > Line 4755 has weird spacing: '...session for s...' > > >=20 > > > 2.In the abstract, pls expand the SIP acronym > > >=20 > > > 3.In the body of the document, pls expand the acronyms when=20 > > > used for the > > > first time > > >=20 > > > 4.One but last para of sect 1 states: > > > To fulfill these requirements, it is necessary to facilitate > > > communication between the network element providing the=20 > > > service (e.g. > > > NAS, SIP Proxy, Application Server etc.) and a=20 > > > credit-control server. > > > That seems to say that this doc does much more than what we=20 > > > see in the abstract > > >=20 > > > 5.Last para of sect 1.2, 2nd line: s/intermediates/intermediate/ > > >=20 > > > 6.Sect 1.3 talks about a value of "4" for Auth-Application-Id. > > > Is that already assigned? If not we should list in IANA=20 > > > considerations sect. > > > Aha, I see it is in IANA considerations. So it should=20 > > > really be a TBA instead > > > of pre-assuming it will get value 4 assigned by IANA. > > >=20 > > > Same question in sect 3.1 and possibly at some more places > > >=20 > > > 7.Seect 3. Where are those code points for CCR and CCA defined? > > > In this doc? Then we need IANA considereations. In=20 > fact, maybe the > > > doc should say TBA-by-IANA instead if this is the case, because > > > I see it in IANA considerations. > > >=20 > > > 8.Bottom page13 and top of page14. Is this another form of=20 > > > (implicit) subtyping? > > >=20 > > > 9.Sect 5.1 4 para 2 but last line > > > s/the closing the/closing the/ > > >=20 > > > 10.When I see things like on page 18: > > > Where multiple G-S-U-Pool-Reference AVPs with the same=20 > > > G-S-U-Pool- > > > Identifier are provided within a=20 > > > Multiple-Services-Credit-Control AVP > > > Then I wonder if a ptr to where those AVPs are defined=20 > > woul not be > > > useful/helpful. > > > Same for things like: > > > RECOMMENDED that Diameter credit-control clients=20 > > > maintain a PENDING-U > > > message queue and restarts the Tx timer every time a=20 > > CCR[Update] > > >=20 > > > 11.Let me also point out that the notaion CCR[Update] in the text > > > cam make people think that [Update] is a citation. I bet=20 > > > the RFC-Editor > > > will not be happy with that. It occurs several times. > > >=20 > > > 12.Top of page 20=20 > > > the concerned service. Additional service event=20 > > > information to be > > > rated MAY be sent as service specific AVPs or MAY be=20 > > > sent within the > > > Service-Parameter-Info AVP at command level. > > > So is it the server or the client who "MAY" send this? > > > And why is the Upper case MAY?=20 > > >=20 > > > 13.Somewhat towrds the bottom of page 20 (3rd pare from=20 > > bottom) I see: > > > There MUST be maximum one instance of the same unit type=20 > > > in one Answer > > > message. However, in case multiple quotas are conveyed=20 > > > to the credit > > > control client in the Multiple-Services-Credit-Control=20 > > > AVPs, it is > > > possible to carry two instances of the same unit type=20 > > > associated to a > > > service-identifier/rating-group for instance when a=20 > > > tariff time change > > > is expected. > > > Is that good english? Is the last one really a sentence? > > > I have a hard time understanding what it says > > >=20 > > > 14.Top of page 21: > > > Two different approaches are defined for the first=20 > > > interrogation to > > > suit properly in all the possible architectures. The=20 > > > first approach > > > Again... is that a sentence? And if so what does it mean? > > >=20 > > > 15. 2nd line page 23 > > > s/contribute/co-operate/ ?? > > >=20 > > > 16. Page 24, 1st para, one but last line. > > > Talks about setting a value to 1 (for an=20 > "intermediate request". > > > and referes to sect 8.2 > > > But sect 82. does not talk about "intermediate" requests.=20 > > > I guess that > > > the UPDATE-REQUESTS are intermendiate... but that is not=20 > > > immediately clear. > > >=20 > > > 17.Sect 5.5 talks about value 4 for RAR messages. See my=20 > > > earlier comment > > > on that value. > > >=20 > > > 18. Sect 5.6 talks about "top-up". I probably can guess what=20 > > > it means. But maybe > > > it is better to explain it. > > >=20 > > > 19.first para sect 5.6.2, last word: s/follow/follows/ > > >=20 > > > 20.Page 36 talks about "timer Twinit". Might want to explain=20 > > > what it is. > > > Possibly also for timers Tx and Tcc > > >=20 > > > 21. Page 52 2nd case. I think under action column, you want=20 > > > to s/=3D!/!=3D/ ?? > > >=20 > > > 22. Table on page 54/55.. WOuld it not be good to explain=20 > > > what codes M, P, V > > > and Y mean? > > >=20 > > > 23. Page 65 towards bottom > > > s/has been occurred/has occurred/ > > > =20 > > > 24. Sect 8.32 > > > s/enumerated/Enumerated/ > > >=20 > > > 25. Sect 8.33=20 > > > Validity-Time in seconds. But since when? Since the AVP=20 > > > is received by the > > > Client?=20 > > >=20 > > > 26. Top of page 85 > > > s/kind threat/kind of threat/ > > >=20 > > > Bert From owner-aaa-wg@merit.edu Mon May 24 09:57:08 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 JAA06867 for ; Mon, 24 May 2004 09:57:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 327D791247; Mon, 24 May 2004 09:56:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC18A91249; Mon, 24 May 2004 09:56:55 -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 BFAD991247 for ; Mon, 24 May 2004 09:56:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A774B594A8; Mon, 24 May 2004 09:56:54 -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 A8CF959617 for ; Mon, 24 May 2004 09:56:53 -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 i4ODumE19961; Mon, 24 May 2004 16:56:48 +0300 (EET DST) X-Scanned: Mon, 24 May 2004 16:56:23 +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 i4ODuNQF005600; Mon, 24 May 2004 16:56:23 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00N9af4u; Mon, 24 May 2004 16:56:21 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 i4ODuKH26211; Mon, 24 May 2004 16:56:20 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 24 May 2004 16:56:17 +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="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Mon, 24 May 2004 16:56:17 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6122415@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcQ86l3b7CzIInfwTz6PUgyZzgv26QEp2jFg From: To: , Cc: X-OriginalArrivalTime: 24 May 2004 13:56:17.0416 (UTC) FILETIME=[E2801080:01C44196] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, NASREQ already specifies the State AVP and, more importantly, uses the State attribute to keep track of=20 Diameter Session-Id on the RADIUS side. This latter feature seems to actually help us: when a translation agent receives a RADIUS Access-Request without=20 a State attribute, it already picks a new Session-Id. (BTW, the former feature seems to require that the translation agent stores the State AVP sent by the Diameter server (if any) locally, since the RADIUS Access-Response can contain only zero or one State attributes. But this is not specific to EAP.) Given this, I think the translation functionality already present in NASREQ is sufficient for the job, and we only have=20 to clarify how Diameter NASes should behave. Perhaps something=20 like this? If a Diameter NAS is in the middle of a multi-round authentication exchange, and it detects that the EAP session between the client and the NAS has been terminated for some reason, it MUST select a new Diameter Session-Id for any subsequent EAP sessions. Best regards, Pasi=20 > -----Original Message----- > From:t Yoshihiro Ohba > Sent: Tuesday, May 18, 2004 6:07 PM > To: Jari Arkko > Cc: Yoshihiro Ohba; Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... >=20 >=20 > On Tue, May 18, 2004 at 05:00:22PM +0300, Jari Arkko wrote: > > Yoshihiro Ohba wrote: > >=20 > > > I don't think we need to define the same method for RADIUS and > > > Diameter to support EAP restart. Diameter can be smarter=20 > as it has > > > Session-Id and is able to terminate a session. > >=20 > > Ok. That's reasonable. But are you saying > >=20 > > 1) We don't need Diameter and RADIUS to interoperate upon=20 > > EAP restart. > >=20 > > or > >=20 > > 2) If we use Session-Id to support EAP restart in Diameter, > > we can make that work also through a D-R gateway so that it > > works even in RADIUS, which has to use State attribute? > >=20 > > I'd be happy with alt 2, but has someone looked at the details, > > and can we make it work? >=20 > I also support alt 2. I think translation between RADIUS and > Diameter can be done in the following way (assuming that a > State AVP is always carried in RADIUS Access-Answer and > Access-Accept messages when an EAP-Message attribute is > carried): >=20 > - Translation from DER to RADIUS Access-Request: >=20 > If the translation agent receives a DER with a new Session-Id, > then it generates a RADIUS Access-Request without a State > attribute. The RADIUS server will treat the request as a > signal to restart the EAP session if the NAS and session > identification attributes corresponds to an existing EAP > session. >=20 > If the translation agent receives a DER with an existing > Session-Id, then it generates a RADIUS Access-Request with a > State attribute that was contained in the message that was > previously sent by the RADIUS server. >=20 > - Translation from RADIUS Access-Request to DER: >=20 > If the translation agent receives a RADIUS Access-Request > without a State attribute, then it creates a new Diameter > session and generates a DER with a new Session-Id. >=20 > If the translation agent receives a RADIUS Access-Request with > a State attribute as well as the NAS and session > identification attributes corresponding to an existing EAP > session, then it generates a DER with the corresponding > Session-Id. >=20 > But I am pretty sure Pasi will come up with better text. :) >=20 > Yoshihiro Ohba From owner-aaa-wg@merit.edu Mon May 24 11:49: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 LAA15747 for ; Mon, 24 May 2004 11:49:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E35719124E; Mon, 24 May 2004 11:49:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2C0491252; Mon, 24 May 2004 11:49: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 C171891250 for ; Mon, 24 May 2004 11:49:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54C9A594AF; Mon, 24 May 2004 11:49:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 5FBA459544 for ; Mon, 24 May 2004 11:49:13 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4OFmoL29340; Mon, 24 May 2004 16:48:50 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 16:48:50 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20DB4BADD@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "Christopher Richards" , marco.stura@nokia.com Cc: david@mitton.com, aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 24 May 2004 16:48:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C441A6.9A0969C2" 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_01C441A6.9A0969C2 Content-Type: text/plain Hi all, So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ? That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ? Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ? Regards...Mark -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: 07 May 2004 20:51 To: marco.stura@nokia.com Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Marco, That sounds good. Thanks. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: Friday, May 07, 2004 2:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified as follow: When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C441A6.9A0969C2 Content-Type: text/html Message
Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?
 
That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?
 
Regards...Mark
 
 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Marco,
 
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,
 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs


Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.

I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.


   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard

------_=_NextPart_001_01C441A6.9A0969C2-- From owner-aaa-wg@merit.edu Mon May 24 12:51: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 MAA18824 for ; Mon, 24 May 2004 12:51:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 746E091252; Mon, 24 May 2004 12:51:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 41FCD91253; Mon, 24 May 2004 12:51: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 CCE5891252 for ; Mon, 24 May 2004 12:51:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC92258F37; Mon, 24 May 2004 12:51:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h002.c000.snv.cp.net [209.228.32.66]) by segue.merit.edu (Postfix) with SMTP id 4385C594A2 for ; Mon, 24 May 2004 12:51:30 -0400 (EDT) Received: (cpmta 10116 invoked from network); 24 May 2004 09:51:28 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 24 May 2004 09:51:28 -0700 X-Sent: 24 May 2004 16:51:28 GMT Message-Id: <5.2.1.1.2.20040524124326.044ba690@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 24 May 2004 12:49:52 -0400 To: "Mark Watson" , "Christopher Richards" , marco.stura@nokia.com From: David Mitton Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Cc: aaa-wg@merit.edu, jari.arkko@kolumbus.fi In-Reply-To: <588B15E2E2B1D41180B800508BF934F20DB4BADD@bmdhd6.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.

 
That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?
 
Regards...Mark
 
 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Marco,
 
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Chris,
 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.

I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard
From owner-aaa-wg@merit.edu Mon May 24 13:05:00 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 NAA19438 for ; Mon, 24 May 2004 13:05:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8841191254; Mon, 24 May 2004 13:04:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4383091255; Mon, 24 May 2004 13:04: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 C4E4591254 for ; Mon, 24 May 2004 13:04:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADBF959544; Mon, 24 May 2004 13:04:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id 69EB8594BE for ; Mon, 24 May 2004 13:04:44 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4OH4VL17792; Mon, 24 May 2004 18:04:31 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 18:04:31 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20DB4BDEB@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'David Mitton'" , "Christopher Richards" , "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'jari.arkko@kolumbus.fi'" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 24 May 2004 18:04:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C441B1.2AF5F338" 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_01C441B1.2AF5F338 Content-Type: text/plain Hi David, I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor). On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved. Comments ? Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application. Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention. ...Mark -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: 24 May 2004 17:50 To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 04:48 PM +0100, Mark Watson wrote: Hi all, So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ? I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base. Any exceptions would have to be justified and dealt with when the specification was reviewed. The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications. RADIUS interfacing is another one of these. Dave. That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ? Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ? Regards...Mark -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: 07 May 2004 20:51 To: marco.stura@nokia.com Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Marco, That sounds good. Thanks. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Friday, May 07, 2004 2:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified as follow: When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com ] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C441B1.2AF5F338 Content-Type: text/html Message
Hi David,
 
I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor).
 
On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved.
 
Comments ?
 
Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application. Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention.
 
...Mark
-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.


That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?
 
Regards...Mark
 
 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Marco,

 
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Chris,

 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:

 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.

 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.

For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.

I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard
------_=_NextPart_001_01C441B1.2AF5F338-- From owner-aaa-wg@merit.edu Mon May 24 14:24: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 OAA21906 for ; Mon, 24 May 2004 14:24:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6391291255; Mon, 24 May 2004 14:23:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 295C791256; Mon, 24 May 2004 14:23: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 1915191255 for ; Mon, 24 May 2004 14:23:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2E3759612; Mon, 24 May 2004 14:23: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 63B9059632 for ; Mon, 24 May 2004 14:23:54 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 438C889897; Mon, 24 May 2004 21:23:37 +0300 (EEST) Message-ID: <40B23CC8.8090100@kolumbus.fi> Date: Mon, 24 May 2004 21:19:52 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6122415@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6122415@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 Pasi.Eronen@nokia.com wrote: > Hi, > > NASREQ already specifies the State AVP and, more > importantly, uses the State attribute to keep track of > Diameter Session-Id on the RADIUS side. > > This latter feature seems to actually help us: when a > translation agent receives a RADIUS Access-Request without > a State attribute, it already picks a new Session-Id. > > (BTW, the former feature seems to require that the translation > agent stores the State AVP sent by the Diameter server (if any) > locally, since the RADIUS Access-Response can contain only zero > or one State attributes. But this is not specific to EAP.) > > Given this, I think the translation functionality already > present in NASREQ is sufficient for the job, and we only have > to clarify how Diameter NASes should behave. Perhaps something > like this? > > If a Diameter NAS is in the middle of a multi-round > authentication exchange, and it detects that the EAP session > between the client and the NAS has been terminated for some > reason, it MUST select a new Diameter Session-Id for any > subsequent EAP sessions. Ok. But I wonder if it would be useful to write down also the thinking behind this, i.e., the use of the State attribute in RADIUS to do the restart. "This is necessary because ...". --Jari From owner-aaa-wg@merit.edu Mon May 24 14:29: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 OAA22005 for ; Mon, 24 May 2004 14:29:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A915691256; Mon, 24 May 2004 14:29:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C5FD91258; Mon, 24 May 2004 14:29:16 -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 BEA4A91256 for ; Mon, 24 May 2004 14:29:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A76B859651; Mon, 24 May 2004 14:29: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 7A3B259638 for ; Mon, 24 May 2004 14:29:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4OIVYr15870; Mon, 24 May 2004 11:31:34 -0700 Date: Mon, 24 May 2004 11:31:34 -0700 (PDT) From: Bernard Aboba To: Mark Watson Cc: "'David Mitton'" , Christopher Richards , "'marco.stura@nokia.com'" , "'aaa-wg@merit.edu'" , "'jari.arkko@kolumbus.fi'" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs In-Reply-To: <588B15E2E2B1D41180B800508BF934F20DB4BDEB@bmdhd6.europe.nortel.com> Message-ID: References: <588B15E2E2B1D41180B800508BF934F20DB4BDEB@bmdhd6.europe.nortel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Certain aspects of RADIUS/Diameter gateway interaction are valid for *all* Diameter applications. Others are specific to a given application. Perhaps it would make sense to more clearly label the universal aspects within the NASREQ specification, and maybe even note that it "updates RFC 3588" in those respects. On Mon, 24 May 2004, Mark Watson wrote: > Hi David, > > I am not so much thinking of applications which directly interact with > RADIUS as cases where new applications are defined and have a requirement to > carry some information for which a RADIUS VSA sub-attribute has already been > defined (perhaps by a standardisation organisation, rather than a specific > vendor). > > On the basis that re-use is better than re-invention, it would be nice if > such applications could re-use the RADIUS VSA sub-attribute definition, even > if there is no actual RADIUS interaction involved. > > Comments ? > > Another way to put my question would be, is it wise for a Diameter > implementation to assume that AVP x with Vendor-ID y always corresponds to > the same AVP, independent of the application. Or would it be wiser to assume > that the meaning of (AVP x, Vendor y) is application-dependent ? The current > specification situation suggests the latter, but I am not sure that is the > intention. > > ...Mark > > -----Original Message----- > From: David Mitton [mailto:david@mitton.com] > Sent: 24 May 2004 17:50 > To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; > marco.stura@nokia.com > Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > On 5/24/2004 04:48 PM +0100, Mark Watson wrote: > > > Hi all, > > So, this rule will apply to NASREQ and DCC, but other applications are free > to do whatever they like ? > > > I would think, (subject to any dissent from the group) that any Diameter > application that interacts with RADIUS, would adhere to the specifications > in Diameter-NASreq as it's base. Any exceptions would have to be justified > and dealt with when the specification was reviewed. > > The Diameter Base (RFC3588) specification would be too unwieldy to cover all > issues, and parts out certain problems to other specifications. RADIUS > interfacing is another one of these. > > Dave. > > > > > That is, the AVP code codespace when the Vendor-specific flag is set to 1 is > application-specific. The same code may mean different things in different > applications. This is unlike the AVP code codespace when the Vendor-specific > flag is 0, right ? > > Would it be better to (also) have a rule for all applications, or at least > an 'opt out' rule such as 'unless otherwise specified in a specific > application....' ? > > Regards...Mark > > > > > -----Original Message----- > > > From: Richards, Christopher [RICH2:2Q40:EXCH] > > > Sent: 07 May 2004 20:51 > > > To: marco.stura@nokia.com > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > Marco, > > > > > > That sounds good. Thanks. > > > > Cheers, > > > Chris. > > > > Shasta Wireless Development > > > Nortel Networks > > > > Telephone: > > > +1 972 684 3281 > > > ESN 444 3281 > > > -----Original Message----- > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com > ] > > > Sent: Friday, May 07, 2004 2:47 AM > > > To: Richards, Christopher [RICH2:2Q40:EXCH] > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > Hi Chris, > > > > > > Since it is not terribly clear that other Diameter applications should > follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I > think it would be beneficial if some statement was added to DCC section 8. > E.g. > > > > > > When including RADIUS vendor specific attributes in a DCC message, the rules > described in [NASREQ] for formatting the Diameter AVP MUST be followed. For > example, the AVP code used is the vendor attribute type code, the > Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the > IANA Vendor identification value. The Diameter AVP data field contains only > the attribute value of the RADIUS attribute. > > > > > > I better see this kind of text in section 4.1, perhaps slightly modified as > follow: > > > > > > When service specific documents include RADIUS vendor specific attributes in > a DCC message, the rules described in [NASREQ] ..........etc. > > > > > > Regards > > > Marco > > > -----Original Message----- > > > From: ext Christopher Richards [mailto:crich@nortelnetworks.com > ] > > > Sent: 04 May, 2004 17:53 > > > To: Stura Marco (Nokia-NET/Helsinki) > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > Hi Marco, > > > > Thanks for the clarification. > > > > Since it is not terribly clear that other Diameter applications should > follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I > think it would be beneficial if some statement was added to DCC section 8. > E.g. > > > > When including RADIUS vendor specific attributes in a DCC message, the rules > described in [NASREQ] for formatting the Diameter AVP MUST be followed. For > example, the AVP code used is the vendor attribute type code, the > Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the > IANA Vendor identification value. The Diameter AVP data field contains only > the attribute value of the RADIUS attribute. > > > > I think it will save confusion in the future. > > > > Cheers, > > > Chris. > > > > -----Original Message----- > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com > ] > > > Sent: Tuesday, May 04, 2004 3:53 AM > > > To: Richards, Christopher [RICH2:2Q40:EXCH] > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > Hi Chris, > > > > >It's not just for translating AVPs on the fly, but also for how to > > > >re-use existing RADIUS > > > >VSA AVPs. > > > >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that > I now want to > > > >use in Diameter. I want avoid having to completely redefine it. > > > >From my reading of RFC3588, it says something along the lines that all AVP > codes 0 to 255 > > > >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 > was included. > > > >As an example, if you have access to 3GPP TS 29.061, take a look at the > RADIUS VSAs defined >for 3GPP. > > > > >When I want to put this information into a Diameter AVP, do I set the > > > >Vendor-ID flag or not? > > > > as Dave pointed out the NASREQ is intended to be the generic RADIUS > replacement within Diameter. If you just use the NASREQ defined AVPs, that > practically uses those AVP numbers from 1 through 255 you're talking about, > you should be able to match the 3GPP TS 29.061 needs. > > > > For those 3gpp vendor-specific attributes defined in TS 29.061 I think you > should follow the rules defined in NASREQ section 9.6.2, RADIUS > Interactions. According to the mentioned rules the V bit is to be set. > > > > I copied here sect. 9.4 of the NASREQ draft, that clearly state that > attribute code 26 must not appear in Diameter messages. > > > > Regards > > > Marco > > > > 9.4 Prohibited RADIUS Attributes > > > > The following RADIUS attributes MUST NOT appear in a Diameter > > > message. Instead, they are translated to other Diameter AVPs or > > > handled in some special manner. The rules for the treatment of the > > > attributes are discussed in Sections 9.1, 9.2 and 9.6. > > > > Attribute Description Defined Nearest Diameter AVP > > > ----------------------------------------------------------------- > > > 3 CHAP-Password RFC 2865 CHAP-Auth Group > > > 26 Vendor-Specific RFC 2865 Vendor Specific AVP > > > 29 Termination-Action RFC 2865 Authorization-Lifetime > > > 40 Acct-Status-Type RFC 2866 Accounting-Record-Type > > > 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets > > > 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets > > > 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets > > > 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets > > > 49 Acct-Terminate-Cause RFC 2866 Termination-Cause > > > 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets > > > 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets > > > 80 Message-Authenticator RFC 2869 none - check and discard > > > From owner-aaa-wg@merit.edu Mon May 24 14:30: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 OAA22052 for ; Mon, 24 May 2004 14:30:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AE5D91258; Mon, 24 May 2004 14:30:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80EC49125B; Mon, 24 May 2004 14:30: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 417BC91258 for ; Mon, 24 May 2004 14:30:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E093459467; Mon, 24 May 2004 14:30:15 -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 4534359595 for ; Mon, 24 May 2004 14:30:14 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4OIWqK15964; Mon, 24 May 2004 11:32:52 -0700 Date: Mon, 24 May 2004 11:32:52 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <40B23CC8.8090100@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122415@esebe023.ntc.nokia.com> <40B23CC8.8090100@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Ok. But I wonder if it would be useful to write down also > the thinking behind this, i.e., the use of the State attribute > in RADIUS to do the restart. "This is necessary because ...". Yes. An errata to RFC 3579 might also make sense. From owner-aaa-wg@merit.edu Mon May 24 15:02:23 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 PAA23221 for ; Mon, 24 May 2004 15:02:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 437D09125B; Mon, 24 May 2004 15:01:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00C659125E; Mon, 24 May 2004 15:01: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 1C0C79125B for ; Mon, 24 May 2004 15:01:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE912594BE; Mon, 24 May 2004 15:01:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h013.c000.snv.cp.net [209.228.32.77]) by segue.merit.edu (Postfix) with SMTP id 74A9F593D6 for ; Mon, 24 May 2004 15:01:32 -0400 (EDT) Received: (cpmta 15993 invoked from network); 24 May 2004 12:01:30 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.77) with SMTP; 24 May 2004 12:01:30 -0700 X-Sent: 24 May 2004 19:01:30 GMT Message-Id: <5.2.1.1.2.20040524135932.0357fd90@getmail.mitton.com> X-Sender: david@mitton.com@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 24 May 2004 14:53:47 -0400 To: "Mark Watson" , "Christopher Richards" , "'marco.stura@nokia.com'" From: David Mitton Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Cc: "'aaa-wg@merit.edu'" , "'jari.arkko@kolumbus.fi'" In-Reply-To: <588B15E2E2B1D41180B800508BF934F20DB4BDEB@bmdhd6.europe.nor tel.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk On 5/24/2004 06:04 PM +0100, Mark Watson wrote:
Hi David,
 
I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor).

VSAs were not intended to be used by other SDOs to extend the protocol.
I'm not aware of such use being approved by an IETF WG.

RADIUS does not have an "application identifier".  Any VSA encodings are assumed to be singular, that is not overlapped in any way.  Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs. 

There's a difference between application dependent semantics, and the actual message encoding.  While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability.

I'm not sure why an application dependent transformation in Diameter is desirable.   Certainly there is enough encoding space to work around any legacy encodings.

I guess I could see some rationale, but it's not something that we'd want to standardize.  These types of cases are to be avoided.  It causes more complexity in proxy agents and gateways.  NASes might need to deal with two types of responses or worse yet make two different types of requests.

 
On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things about RADIUS that were problematic.  VSAs were one of these.   If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding?  

Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions.   Even if that interoperability is not used.. initially.

 
Comments ?
 
Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application.

It should. 

Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention.
 
...Mark

I'm not sure why, but we could put that on the errata/"bis" list.

Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap.
Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different?

Dave.

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi all,
 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.


That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?
 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?
 
Regards...Mark
 
 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Marco,
 
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Chris,
 
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
 
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
 
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
 
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
 
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.
>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.
For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.
I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.
Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard
From owner-aaa-wg@merit.edu Mon May 24 15:35: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 PAA25037 for ; Mon, 24 May 2004 15:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0E4B9125D; Mon, 24 May 2004 15:35:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C63E9125E; Mon, 24 May 2004 15:35:11 -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 625CD9125D for ; Mon, 24 May 2004 15:35:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4A446592B8; Mon, 24 May 2004 15:35:10 -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 B51FC58F37 for ; Mon, 24 May 2004 15:35:09 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 77DCB89846; Mon, 24 May 2004 22:35:07 +0300 (EEST) Message-ID: <40B24D8A.6070009@kolumbus.fi> Date: Mon, 24 May 2004 22:31:22 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A6122415@esebe023.ntc.nokia.com> <40B23CC8.8090100@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: >>Ok. But I wonder if it would be useful to write down also >>the thinking behind this, i.e., the use of the State attribute >>in RADIUS to do the restart. "This is necessary because ...". > > > Yes. An errata to RFC 3579 might also make sense. Ok. Here's some proposed text. For D-EAP: "This is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). In RADIUS [RFC 3579 Errata], the same functionality is achieved through the inclusion or omission of the State attribute. Translation rules in [NASREQ] ensure that an Access-Request without the State attribute maps to a a new Diameter Session-Id AVP value. Furthemore, a translation agent will always include a State attribute in Access-Challenge messages, making sure that the State attribute is available for a RADIUS NAS." For R-EAP RFC 3579 Errata: "The use of the State attribute is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). The following rules specify how this attribute is used with RADIUS EAP: o RADIUS servers SHOULD always include the State attribute in an Access-Challenge, Access-Accept, or Access-Reject message. o Normally, a NAS copies the received State attribute to an Access-Request sent as a response to an Access-Challenge [RFC 2865 Section 5.24]. Note that an Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if the State attribute has previously been received in an Access-Challenge for the same user and port." --Jari From owner-aaa-wg@merit.edu Mon May 24 15:45:30 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 PAA25390 for ; Mon, 24 May 2004 15:45:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 115AA91270; Mon, 24 May 2004 15:19:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0C829135E; Mon, 24 May 2004 15:19:03 -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 3092091270 for ; Mon, 24 May 2004 15:18:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BC4F594A8; Mon, 24 May 2004 15:18:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from znsgs01r.nortelnetworks.com (znsgs01r.nortelnetworks.com [47.166.48.91]) by segue.merit.edu (Postfix) with ESMTP id BF90D5941C for ; Mon, 24 May 2004 15:18:54 -0400 (EDT) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.160.46.124]) by znsgs01r.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i4OJIIL00220; Mon, 24 May 2004 20:18:19 +0100 (BST) Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 May 2004 20:18:19 +0100 Message-ID: <588B15E2E2B1D41180B800508BF934F20DBA5C32@bmdhd6.europe.nortel.com> From: "Mark Watson" To: "'David Mitton'" , "Christopher Richards" , "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'jari.arkko@kolumbus.fi'" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 24 May 2004 20:18:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C441C3.DEA37E02" 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_01C441C3.DEA37E02 Content-Type: text/plain Hi Dave, Ok, so you have answered my question: you think the AVP codes for use with a given vendor id are taken from a single codespace, which is independent of application. Therefore values 0-255 are identified with RADIUS VSA sub-attributes for the same vendor id. Someone could think differently because the identity between the Diameter vendor-specific AVP codespace and the RADIUS VSA sub-attribute codespace is only defined in Diameter NASREQ and CC, not base. Personally, I think your view is the simplest. But now I know of at least one 'vendor' which has a problem. 3GPP has been allocated a vendor ID by IANA and has defined a number of RADIUS VSA sub-attributes and Diameter AVPs in the resulting codespace. Regards...Mark -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: 24 May 2004 19:54 To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi' Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 06:04 PM +0100, Mark Watson wrote: Hi David, I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor). VSAs were not intended to be used by other SDOs to extend the protocol. I'm not aware of such use being approved by an IETF WG. RADIUS does not have an "application identifier". Any VSA encodings are assumed to be singular, that is not overlapped in any way. Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs. There's a difference between applicati on dependent semantics, and the actual message encoding. While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability. I'm not sure why an application dependent transformation in Diameter is desirable. Certainly there is enough encoding space to work around any legacy encodings. I guess I could see some rationale, but it's not something that we'd want to standardize. These types of cases are to be avoided. It causes more complexity in proxy agents and gateways. NASes might need to deal with two types of responses or worse yet make two different types of requests. On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved. In the development of Diameter, we choose to change a number of things about RADIUS that were problematic. VSAs were one of these. If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding? Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions. Even if that interoperability is not used.. initially. Comments ? Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application. It should. Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention. ...Mark I'm not sure why, but we could put that on the errata/"bis" list. Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap. Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different? Dave. -----Original Message----- From: David Mitton [mailto:david@mitton.com ] Sent: 24 May 2004 17:50 To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 04:48 PM +0100, Mark Watson wrote: Hi all, So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ? I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base. Any exceptions would have to be justified and dealt with when the specification was reviewed. The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications. RADIUS interfacing is another one of these. Dave. That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ? Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ? Regards...Mark -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: 07 May 2004 20:51 To: marco.stura@nokia.com Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Marco, That sounds good. Thanks. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Friday, May 07, 2004 2:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified as follow: When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com ] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C441C3.DEA37E02 Content-Type: text/html Message
Hi Dave,
 
Ok, so you have answered my question: you think the AVP codes for use with a given vendor id are taken from a single codespace, which is independent of application. Therefore values 0-255 are identified with RADIUS VSA sub-attributes for the same vendor id. Someone could think differently because the identity between the Diameter vendor-specific AVP codespace and the RADIUS VSA sub-attribute codespace is only defined in Diameter NASREQ and CC, not base.
 
Personally, I think your view is the simplest. But now I know of at least one 'vendor' which has a problem.
 
3GPP has been allocated a vendor ID by IANA and has defined a number of RADIUS VSA sub-attributes and Diameter AVPs in the resulting codespace.

Regards...Mark
-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 19:54
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi'
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

On 5/24/2004 06:04 PM +0100, Mark Watson wrote:
Hi David,
 
I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor).

VSAs were not intended to be used by other SDOs to extend the protocol.
I'm not aware of such use being approved by an IETF WG.

RADIUS does not have an "application identifier".  Any VSA encodings are assumed to be singular, that is not overlapped in any way.  Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs. 

There's a difference between applicati  on dependent semantics, and the actual message encoding.  While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability.

I'm not sure why an application dependent transformation in Diameter is desirable.   Certainly there is enough encoding space to work around any legacy encodings.

I guess I could see some rationale, but it's not something that we'd want to standardize.  These types of cases are to be avoided.  It causes more complexity in proxy agents and gateways.  NASes might need to deal with two types of responses or worse yet make two different types of requests.


On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things about RADIUS that were problematic.  VSAs were one of these.   If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding?  

Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions.   Even if that interoperability is not used.. initially.


Comments ?
 
Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application.

It should. 

Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention.
 
...Mark

I'm not sure why, but we could put that on the errata/"bis" list.

Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap.
Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different?

Dave.

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi all,

 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.


That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?

 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?

 
Regards...Mark

 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Marco,
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Chris,
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.
>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.
For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.
I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.
Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard
------_=_NextPart_001_01C441C3.DEA37E02-- From owner-aaa-wg@merit.edu Mon May 24 16:29: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 QAA26368 for ; Mon, 24 May 2004 16:29:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D37339125E; Mon, 24 May 2004 16:29:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0F9E91261; Mon, 24 May 2004 16:29:37 -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 6A82B9125E for ; Mon, 24 May 2004 16:29:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 52FC459682; Mon, 24 May 2004 16:29:36 -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 C70DB59675 for ; Mon, 24 May 2004 16:29:35 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 May 2004 22:35:10 +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 i4OKSx3v012222 for ; Mon, 24 May 2004 22:28:59 +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); Mon, 24 May 2004 22:28:59 +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_01C441CD.BE40E5DD" Subject: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Mon, 24 May 2004 22:28:58 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUA= From: "Mark Grayson (mgrayson)" To: X-OriginalArrivalTime: 24 May 2004 20:28:59.0285 (UTC) FILETIME=[BE77F450:01C441CD] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C441CD.BE40E5DD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone clarify whether event-timestamp AVP is mandatory or not. I cannot seem to find a MUST (or even SHOULD)defined. =20 Many thanks, Mark ------_=_NextPart_001_01C441CD.BE40E5DD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Can someone clarify whether=20 event-timestamp AVP is mandatory or not. I cannot seem to find a MUST = (or even=20 SHOULD)defined.
 
Many=20 thanks,
Mark
<= /BODY> ------_=_NextPart_001_01C441CD.BE40E5DD-- From owner-aaa-wg@merit.edu Tue May 25 02:21:01 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 CAA16952 for ; Tue, 25 May 2004 02:21:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CBC691261; Tue, 25 May 2004 02:20:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D19C991262; Tue, 25 May 2004 02:20: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 CE7CE91261 for ; Tue, 25 May 2004 02:20:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6C16594B6; Tue, 25 May 2004 02:20:43 -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 BDCB9593C4 for ; Tue, 25 May 2004 02:20:42 -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 i4P6KKo01020; Tue, 25 May 2004 09:20:20 +0300 (EET DST) X-Scanned: Tue, 25 May 2004 09:19:01 +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 i4P6J1YX013671; Tue, 25 May 2004 09:19:01 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002Lev5G; Tue, 25 May 2004 09:18:59 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 i4P6InH14490; Tue, 25 May 2004 09:18:49 +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); Tue, 25 May 2004 09:18:33 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 May 2004 09:18:32 +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]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 09:18:33 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87A0@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRBvR77T/k0I9jbSReURKmLHAWSFAAYsvmg From: To: , , Cc: , , X-OriginalArrivalTime: 25 May 2004 06:18:32.0742 (UTC) FILETIME=[1AB12460:01C44220] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > Perhaps it would make sense to more clearly label the=20 > universal aspects > within the NASREQ specification, and maybe even note that it=20 > "updates RFC > 3588" in those respects. I support this approach, it would certainly help. Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 24 May, 2004 21:32 > To: Mark Watson > Cc: 'David Mitton'; Christopher Richards; Stura Marco > (Nokia-NET/Helsinki); 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi' > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs >=20 >=20 > Certain aspects of RADIUS/Diameter gateway interaction are valid for > *all* Diameter applications. Others are specific to a given=20 > application. >=20 > Perhaps it would make sense to more clearly label the=20 > universal aspects > within the NASREQ specification, and maybe even note that it=20 > "updates RFC > 3588" in those respects. >=20 >=20 > On Mon, 24 May 2004, Mark Watson wrote: >=20 > > Hi David, > > > > I am not so much thinking of applications which directly=20 > interact with > > RADIUS as cases where new applications are defined and have=20 > a requirement to > > carry some information for which a RADIUS VSA sub-attribute=20 > has already been > > defined (perhaps by a standardisation organisation, rather=20 > than a specific > > vendor). > > > > On the basis that re-use is better than re-invention, it=20 > would be nice if > > such applications could re-use the RADIUS VSA sub-attribute=20 > definition, even > > if there is no actual RADIUS interaction involved. > > > > Comments ? > > > > Another way to put my question would be, is it wise for a Diameter > > implementation to assume that AVP x with Vendor-ID y always=20 > corresponds to > > the same AVP, independent of the application. Or would it=20 > be wiser to assume > > that the meaning of (AVP x, Vendor y) is=20 > application-dependent ? The current > > specification situation suggests the latter, but I am not=20 > sure that is the > > intention. > > > > ...Mark > > > > -----Original Message----- > > From: David Mitton [mailto:david@mitton.com] > > Sent: 24 May 2004 17:50 > > To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher=20 > [RICH2:2Q40:EXCH]; > > marco.stura@nokia.com > > Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > > On 5/24/2004 04:48 PM +0100, Mark Watson wrote: > > > > > > Hi all, > > > > So, this rule will apply to NASREQ and DCC, but other=20 > applications are free > > to do whatever they like ? > > > > > > I would think, (subject to any dissent from the group) that=20 > any Diameter > > application that interacts with RADIUS, would adhere to the=20 > specifications > > in Diameter-NASreq as it's base. Any exceptions would have=20 > to be justified > > and dealt with when the specification was reviewed. > > > > The Diameter Base (RFC3588) specification would be too=20 > unwieldy to cover all > > issues, and parts out certain problems to other=20 > specifications. RADIUS > > interfacing is another one of these. > > > > Dave. > > > > > > > > > > That is, the AVP code codespace when the Vendor-specific=20 > flag is set to 1 is > > application-specific. The same code may mean different=20 > things in different > > applications. This is unlike the AVP code codespace when=20 > the Vendor-specific > > flag is 0, right ? > > > > Would it be better to (also) have a rule for all=20 > applications, or at least > > an 'opt out' rule such as 'unless otherwise specified in a specific > > application....' ? > > > > Regards...Mark > > > > > > > > > > -----Original Message----- > > > > > > From: Richards, Christopher [RICH2:2Q40:EXCH] > > > > > > Sent: 07 May 2004 20:51 > > > > > > To: marco.stura@nokia.com > > > > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > > > > Marco, > > > > > > > > > > > > That sounds good. Thanks. > > > > > > > > Cheers, > > > > > > Chris. > > > > > > > > Shasta Wireless Development > > > > > > Nortel Networks > > > > > > > > Telephone: > > > > > > +1 972 684 3281 > > > > > > ESN 444 3281 > > > > > > -----Original Message----- > > > > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com > > ] > > > > > > Sent: Friday, May 07, 2004 2:47 AM > > > > > > To: Richards, Christopher [RICH2:2Q40:EXCH] > > > > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > > > > Hi Chris, > > > > > > > > > > > > Since it is not terribly clear that other Diameter=20 > applications should > > follow the NASREQ specification when encoding RADIUS vendor=20 > specific AVPs, I > > think it would be beneficial if some statement was added to=20 > DCC section 8. > > E.g. > > > > > > > > > > > > When including RADIUS vendor specific attributes in a DCC=20 > message, the rules > > described in [NASREQ] for formatting the Diameter AVP MUST=20 > be followed. For > > example, the AVP code used is the vendor attribute type code, the > > Vendor-Specific flag MUST be set to 1 and the Vendor-ID=20 > MUST be set to the > > IANA Vendor identification value. The Diameter AVP data=20 > field contains only > > the attribute value of the RADIUS attribute. > > > > > > > > > > > > I better see this kind of text in section 4.1, perhaps=20 > slightly modified as > > follow: > > > > > > > > > > > > When service specific documents include RADIUS vendor=20 > specific attributes in > > a DCC message, the rules described in [NASREQ] ..........etc. > > > > > > > > > > > > Regards > > > > > > Marco > > > > > > -----Original Message----- > > > > > > From: ext Christopher Richards [mailto:crich@nortelnetworks.com > > ] > > > > > > Sent: 04 May, 2004 17:53 > > > > > > To: Stura Marco (Nokia-NET/Helsinki) > > > > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > > > > Hi Marco, > > > > > > > > Thanks for the clarification. > > > > > > > > Since it is not terribly clear that other Diameter=20 > applications should > > follow the NASREQ specification when encoding RADIUS vendor=20 > specific AVPs, I > > think it would be beneficial if some statement was added to=20 > DCC section 8. > > E.g. > > > > > > > > When including RADIUS vendor specific attributes in a DCC=20 > message, the rules > > described in [NASREQ] for formatting the Diameter AVP MUST=20 > be followed. For > > example, the AVP code used is the vendor attribute type code, the > > Vendor-Specific flag MUST be set to 1 and the Vendor-ID=20 > MUST be set to the > > IANA Vendor identification value. The Diameter AVP data=20 > field contains only > > the attribute value of the RADIUS attribute. > > > > > > > > I think it will save confusion in the future. > > > > > > > > Cheers, > > > > > > Chris. > > > > > > > > -----Original Message----- > > > > > > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com > > ] > > > > > > Sent: Tuesday, May 04, 2004 3:53 AM > > > > > > To: Richards, Christopher [RICH2:2Q40:EXCH] > > > > > > Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > > > > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > > > > Hi Chris, > > > > > > > > >It's not just for translating AVPs on the fly, but also for how to > > > > > > >re-use existing RADIUS > > > > > > >VSA AVPs. > > > > > > >I currently have a RADIUS VSA AVP - a VSA that was defined=20 > for RADIUS, that > > I now want to > > > > > > >use in Diameter. I want avoid having to completely redefine it. > > > > > > >From my reading of RFC3588, it says something along the=20 > lines that all AVP > > codes 0 to 255 > > > > > > >are reserved for RADIUS AVPs. From this I also took that=20 > RADIUS AVP code 26 > > was included. > > > > > > >As an example, if you have access to 3GPP TS 29.061, take=20 > a look at the > > RADIUS VSAs defined >for 3GPP. > > > > > > > > >When I want to put this information into a Diameter AVP,=20 > do I set the > > > > > > >Vendor-ID flag or not? > > > > > > > > as Dave pointed out the NASREQ is intended to be the generic RADIUS > > replacement within Diameter. If you just use the NASREQ=20 > defined AVPs, that > > practically uses those AVP numbers from 1 through 255=20 > you're talking about, > > you should be able to match the 3GPP TS 29.061 needs. > > > > > > > > For those 3gpp vendor-specific attributes defined in TS=20 > 29.061 I think you > > should follow the rules defined in NASREQ section 9.6.2, RADIUS > > Interactions. According to the mentioned rules the V bit is=20 > to be set. > > > > > > > > I copied here sect. 9.4 of the NASREQ draft, that clearly state that > > attribute code 26 must not appear in Diameter messages. > > > > > > > > Regards > > > > > > Marco > > > > > > > > 9.4 Prohibited RADIUS Attributes > > > > > > > > The following RADIUS attributes MUST NOT appear in a Diameter > > > > > > message. Instead, they are translated to other Diameter AVPs or > > > > > > handled in some special manner. The rules for the=20 > treatment of the > > > > > > attributes are discussed in Sections 9.1, 9.2 and 9.6. > > > > > > > > Attribute Description Defined Nearest Diameter AVP > > > > > > ----------------------------------------------------------------- > > > > > > 3 CHAP-Password RFC 2865 CHAP-Auth Group > > > > > > 26 Vendor-Specific RFC 2865 Vendor Specific AVP > > > > > > 29 Termination-Action RFC 2865 Authorization-Lifetime > > > > > > 40 Acct-Status-Type RFC 2866 Accounting-Record-Type > > > > > > 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets > > > > > > 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets > > > > > > 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets > > > > > > 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets > > > > > > 49 Acct-Terminate-Cause RFC 2866 Termination-Cause > > > > > > 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets > > > > > > 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets > > > > > > 80 Message-Authenticator RFC 2869 none - check and discard > > > > > > >=20 From owner-aaa-wg@merit.edu Tue May 25 02:25:15 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 CAA17423 for ; Tue, 25 May 2004 02:25:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 234C191262; Tue, 25 May 2004 02:25:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE1591264; Tue, 25 May 2004 02:25:01 -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 2310491262 for ; Tue, 25 May 2004 02:24:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03FC459591; Tue, 25 May 2004 02:24:59 -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 733DF59485 for ; Tue, 25 May 2004 02:24:57 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4P6Oev28141; Tue, 25 May 2004 09:24:40 +0300 (EET DST) X-Scanned: Tue, 25 May 2004 09:23:17 +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 i4P6NHe4030459; Tue, 25 May 2004 09:23:17 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 004a4yC2; Tue, 25 May 2004 09:23:14 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 i4P6N8H18263; Tue, 25 May 2004 09:23:08 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 May 2004 09:23:08 +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_01C44220.BEB80B30" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 09:23:07 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87A1@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRBwZOU4fOaC8ToQWSfEUmGVX93yAAXqgqQ From: To: , , Cc: , , X-OriginalArrivalTime: 25 May 2004 06:23:08.0060 (UTC) FILETIME=[BECB55C0:01C44220] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44220.BEB80B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is = application-dependent ? The current >specification situation suggests the latter, but I am not sure that is = the intention. =20 >...Mark >I'm not sure why, but we could put that on the errata/"bis" list. >Even though the use of Diameter AVPs are application dependant, their = encoding is coordinated across the Diameter=20 >encoding space so there is no overlap. >Could you point to the text in RFC 3588 that gave the impression that = VSA AVPs are different? =20 Personally I cannot find such a text that causes this kind of confusion. If we take the approach suggested by Bernard (i.e. clearly label the = universal aspects within the NASREQ specification), perhaps we could clarify this apsect in NASREQ as well. =20 Marco -----Original Message----- From: ext David Mitton [mailto:david@mitton.com] Sent: 24 May, 2004 21:54 To: Mark Watson; Christopher Richards; Stura Marco (Nokia-NET/Helsinki) Cc: 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi' Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 06:04 PM +0100, Mark Watson wrote: Hi David, =20 I am not so much thinking of applications which directly interact with = RADIUS as cases where new applications are defined and have a = requirement to carry some information for which a RADIUS VSA = sub-attribute has already been defined (perhaps by a standardisation = organisation, rather than a specific vendor). VSAs were not intended to be used by other SDOs to extend the protocol. I'm not aware of such use being approved by an IETF WG. RADIUS does not have an "application identifier". Any VSA encodings are = assumed to be singular, that is not overlapped in any way. Most RADIUS = server implementations use a flat static dictionary to describe = attributes including VSAs. =20 There's a difference between application dependent semantics, and the = actual message encoding. While it may essential to treat the contents = of an AVP differently in different application contexts, the parsing of = the message fields must be mechanical for interoperability. I'm not sure why an application dependent transformation in Diameter is = desirable. Certainly there is enough encoding space to work around any = legacy encodings. I guess I could see some rationale, but it's not something that we'd = want to standardize. These types of cases are to be avoided. It causes = more complexity in proxy agents and gateways. NASes might need to deal = with two types of responses or worse yet make two different types of = requests. On the basis that re-use is better than re-invention, it would be nice = if such applications could re-use the RADIUS VSA sub-attribute = definition, even if there is no actual RADIUS interaction involved. In the development of Diameter, we choose to change a number of things = about RADIUS that were problematic. VSAs were one of these. If you = are going through the trouble of implementing a Diameter application, = why not use the native Diameter encoding? =20 Likewise the purpose of having one encoding is for the interoperability = that results from not having to define/implement more exceptions. Even = if that interoperability is not used.. initially. Comments ? =20 Another way to put my question would be, is it wise for a Diameter = implementation to assume that AVP x with Vendor-ID y always corresponds = to the same AVP, independent of the application.=20 It should. =20 Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is = application-dependent ? The current specification situation suggests the = latter, but I am not sure that is the intention. =20 ...Mark I'm not sure why, but we could put that on the errata/"bis" list. Even though the use of Diameter AVPs are application dependant, their = encoding is coordinated across the Diameter encoding space so there is = no overlap. Could you point to the text in RFC 3588 that gave the impression that = VSA AVPs are different? Dave. -----Original Message----- From: David Mitton [ mailto:david@mitton.com]=20 Sent: 24 May 2004 17:50 To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher = [RICH2:2Q40:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 04:48 PM +0100, Mark Watson wrote: Hi all, =20 So, this rule will apply to NASREQ and DCC, but other applications are = free to do whatever they like ? I would think, (subject to any dissent from the group) that any Diameter = application that interacts with RADIUS, would adhere to the = specifications in Diameter-NASreq as it's base. Any exceptions would = have to be justified and dealt with when the specification was reviewed. The Diameter Base (RFC3588) specification would be too unwieldy to cover = all issues, and parts out certain problems to other specifications. = RADIUS interfacing is another one of these. Dave. That is, the AVP code codespace when the Vendor-specific flag is set to = 1 is application-specific. The same code may mean different things in = different applications. This is unlike the AVP code codespace when the = Vendor-specific flag is 0, right ? =20 Would it be better to (also) have a rule for all applications, or at = least an 'opt out' rule such as 'unless otherwise specified in a = specific application....' ? =20 Regards...Mark =20 -----Original Message-----=20 From: Richards, Christopher [RICH2:2Q40:EXCH]=20 Sent: 07 May 2004 20:51=20 To: marco.stura@nokia.com=20 Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi=20 Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Marco, That sounds good. Thanks. Cheers,=20 Chris.=20 Shasta Wireless Development=20 Nortel Networks=20 Telephone:=20 +1 972 684 3281=20 ESN 444 3281=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Friday, May 07, 2004 2:47 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi=20 Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should = follow the NASREQ specification when encoding RADIUS vendor specific = AVPs, I think it would be beneficial if some statement was added to DCC = section 8. E.g.=20 When including RADIUS vendor specific attributes in a DCC message, the = rules described in [NASREQ] for formatting the Diameter AVP MUST be = followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST = be set to the IANA Vendor identification value. The Diameter AVP data = field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified = as follow: When service specific documents include RADIUS vendor specific = attributes in a DCC message, the rules described in [NASREQ] = ..........etc. Regards=20 Marco=20 -----Original Message-----=20 From: ext Christopher Richards [ mailto:crich@nortelnetworks.com]=20 Sent: 04 May, 2004 17:53=20 To: Stura Marco (Nokia-NET/Helsinki)=20 Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi=20 Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco,=20 Thanks for the clarification.=20 Since it is not terribly clear that other Diameter applications should = follow the NASREQ specification when encoding RADIUS vendor specific = AVPs, I think it would be beneficial if some statement was added to DCC = section 8. E.g.=20 When including RADIUS vendor specific attributes in a DCC message, the = rules described in [NASREQ] for formatting the Diameter AVP MUST be = followed. For example, the AVP code used is the vendor attribute type = code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST = be set to the IANA Vendor identification value. The Diameter AVP data = field contains only the attribute value of the RADIUS attribute.=20 I think it will save confusion in the future.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com]=20 Sent: Tuesday, May 04, 2004 3:53 AM=20 To: Richards, Christopher [RICH2:2Q40:EXCH]=20 Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi=20 Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs=20 Hi Chris,=20 >It's not just for translating AVPs on the fly, but also for how to=20 >re-use existing RADIUS=20 >VSA AVPs.=20 >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, = that I now want to=20 >use in Diameter. I want avoid having to completely redefine it.=20 >From my reading of RFC3588, it says something along the lines that all = AVP codes 0 to 255=20 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP = code 26 was included.=20 >As an example, if you have access to 3GPP TS 29.061, take a look at the = RADIUS VSAs defined >for 3GPP.=20 >When I want to put this information into a Diameter AVP, do I set the=20 >Vendor-ID flag or not?=20 as Dave pointed out the NASREQ is intended to be the generic RADIUS = replacement within Diameter. If you just use the NASREQ defined AVPs, = that practically uses those AVP numbers from 1 through 255 you're = talking about, you should be able to match the 3GPP TS 29.061 needs.=20 For those 3gpp vendor-specific attributes defined in TS 29.061 I think = you should follow the rules defined in NASREQ section 9.6.2, RADIUS = Interactions. According to the mentioned rules the V bit is to be set.=20 I copied here sect. 9.4 of the NASREQ draft, that clearly state that = attribute code 26 must not appear in Diameter messages.=20 Regards=20 Marco=20 9.4 Prohibited RADIUS Attributes=20 The following RADIUS attributes MUST NOT appear in a Diameter=20 message. Instead, they are translated to other Diameter AVPs or=20 handled in some special manner. The rules for the treatment of the=20 attributes are discussed in Sections 9.1, 9.2 and 9.6.=20 Attribute Description Defined Nearest Diameter AVP=20 -----------------------------------------------------------------=20 3 CHAP-Password RFC 2865 CHAP-Auth Group=20 26 Vendor-Specific RFC 2865 Vendor Specific AVP=20 29 Termination-Action RFC 2865 Authorization-Lifetime=20 40 Acct-Status-Type RFC 2866 Accounting-Record-Type=20 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets=20 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets=20 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets=20 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets=20 49 Acct-Terminate-Cause RFC 2866 Termination-Cause=20 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets=20 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets=20 80 Message-Authenticator RFC 2869 none - check and discard=20 ------_=_NextPart_001_01C44220.BEB80B30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>Or would it be wiser to assume = that the=20 meaning of (AVP x, Vendor y) is application-dependent ? The=20 current
 >specification situation suggests = the=20 latter, but I am not sure that is the intention.
 
>...Mark

>I'm not sure why, but we could put = that on=20 the errata/"bis" list.

>Even=20 though the use of Diameter AVPs are application dependant, their = encoding is=20 coordinated across the Diameter 
>encoding space so there is no=20 overlap.
>Could you point = to the=20 text in RFC 3588 that gave the impression that VSA AVPs are=20 different?
 
Personally I cannot find such a text that causes this kind of=20 confusion.
If we=20 take the approach suggested by Bernard (i.e. clearly = label the=20 universal aspects within the NASREQ = specification),
perhaps we could clarify this apsect in NASREQ as=20 well.
 
Marco
-----Original Message-----
From: ext David Mitton=20 [mailto:david@mitton.com]
Sent: 24 May, 2004 = 21:54
To:=20 Mark Watson; Christopher Richards; Stura Marco=20 (Nokia-NET/Helsinki)
Cc: 'aaa-wg@merit.edu';=20 'jari.arkko@kolumbus.fi'
Subject: RE: [AAA-WG]: Diameter = encoding of=20 RADIUS VSA AVPs

On 5/24/2004 06:04 PM +0100, Mark = Watson=20 wrote:
Hi David,
 
I am not so much thinking of applications which directly = interact=20 with RADIUS as cases where new applications are defined and have a=20 requirement to carry some information for which a RADIUS VSA = sub-attribute=20 has already been defined (perhaps by a standardisation organisation, = rather=20 than a specific vendor).

VSAs were not = intended to be=20 used by other SDOs to extend the protocol.
I'm not aware of such = use being=20 approved by an IETF WG.

RADIUS does not have an "application=20 identifier".  Any VSA encodings are assumed to be singular, that = is not=20 overlapped in any way.  Most RADIUS server implementations use a = flat=20 static dictionary to describe attributes including VSAs.  =

There's=20 a difference between application dependent semantics, and the actual = message=20 encoding.  While it may essential to treat the contents of an AVP = differently in different application contexts, the parsing of the = message=20 fields must be mechanical for interoperability.

I'm not sure = why an=20 application dependent transformation in Diameter is = desirable.  =20 Certainly there is enough encoding space to work around any legacy=20 encodings.

I guess I could see some rationale, but it's not = something=20 that we'd want to standardize.  These types of cases are to be=20 avoided.  It causes more complexity in proxy agents and = gateways. =20 NASes might need to deal with two types of responses or worse yet make = two=20 different types of requests.


On the basis that re-use is better than re-invention, it = would be=20 nice if such applications could re-use the RADIUS VSA sub-attribute=20 definition, even if there is no actual RADIUS interaction=20 involved.

In the development of Diameter, we = choose to=20 change a number of things about RADIUS that were problematic.  = VSAs were=20 one of these.   If you are going through the trouble of = implementing=20 a Diameter application, why not use the native Diameter = encoding?  =20

Likewise the purpose of having one encoding is for the=20 interoperability that results from not having to define/implement more = exceptions.   Even if that interoperability is not used..=20 initially.


Comments ?
 
Another way to put my question would be, is it wise for a = Diameter=20 implementation to assume that AVP x with Vendor-ID y always = corresponds to=20 the same AVP, independent of the application. =

It=20 should. 

Or would it be wiser to assume that the meaning of (AVP x, = Vendor y)=20 is application-dependent ? The current specification situation = suggests the=20 latter, but I am not sure that is the = intention.
 
...Mark

I'm not sure=20 why, but we could put that on the errata/"bis" list.

Even = though the=20 use of Diameter AVPs are application dependant, their encoding is = coordinated=20 across the Diameter encoding space so there is no overlap.
Could = you point=20 to the text in RFC 3588 that gave the impression that VSA AVPs are=20 different?

Dave.

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher=20 [RICH2:2Q40:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA=20 AVPs
On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi = all,

 
So, this rule = will apply to=20 NASREQ and DCC, but other applications are free to do whatever = they like=20 ?

I would think, (subject to any dissent from the group) that = any=20 Diameter application that interacts with RADIUS, would adhere to = the=20 specifications in Diameter-NASreq as it's base.  Any = exceptions would=20 have to be justified and dealt with when the specification was=20 reviewed.

The Diameter Base (RFC3588) specification would be too = unwieldy to=20 cover all issues, and parts out certain problems to other=20 specifications.  RADIUS interfacing is another one of = these.

Dave.


That is, the = AVP code=20 codespace when the Vendor-specific flag is set to 1 is=20 application-specific. The same code may mean different things in = different applications. This is unlike the AVP code codespace = when the=20 Vendor-specific flag is 0, right ?

 
Would it be = better to (also)=20 have a rule for all applications, or at least an 'opt out' rule = such as=20 'unless otherwise specified in a specific application....' = ?

 
Regards...Mark

 
=20
-----Original Message-----=20
From: Richards, Christopher [RICH2:2Q40:EXCH]=20
Sent: 07 May 2004 20:51=20
To: marco.stura@nokia.com=20
Cc: david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi=20
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA=20 AVPs
Marco,
=20
That sounds = good.=20 Thanks.

Cheers,=20
Chris.

Shasta Wireless = Development=20
Nortel Networks

Telephone:=20
+1 972 684 3281=20
ESN 444 3281=20
-----Original Message-----=20
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Friday, May 07, 2004 2:47 AM=20
To: Richards, Christopher [RICH2:2Q40:EXCH]=20
Cc: david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi=20
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA=20 AVPs
Hi = Chris,
=20
Since it is not terribly clear that other = Diameter=20 applications should follow the NASREQ specification when = encoding RADIUS=20 vendor specific AVPs, I think it would be beneficial if some = statement=20 was added to DCC section 8. E.g.=20
=20
When including RADIUS vendor specific = attributes in a=20 DCC message, the rules described in [NASREQ] for formatting the = Diameter=20 AVP MUST be followed. For example, the AVP code used is the = vendor=20 attribute type code, the Vendor-Specific flag MUST be set to 1 = and the=20 Vendor-ID MUST be set to the IANA Vendor identification value. = The=20 Diameter AVP data field contains only the attribute value of the = RADIUS=20 attribute.
=20
I better see = this kind of text=20 in section 4.1, perhaps slightly modified as follow:
=20
When service = specific=20 documents include RADIUS vendor specific attributes in a DCC = message,=20 the rules described in [NASREQ] ..........etc.
=20
Regards=20
Marco=20
-----Original Message-----=20
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]=20
Sent: 04 May, 2004 17:53=20
To: Stura Marco (Nokia-NET/Helsinki)=20
Cc: david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi=20
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA=20 AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other = Diameter=20 applications should follow the NASREQ specification when = encoding RADIUS=20 vendor specific AVPs, I think it would be beneficial if some = statement=20 was added to DCC section 8. E.g.=20
When including RADIUS vendor specific = attributes in a=20 DCC message, the rules described in [NASREQ] for formatting the = Diameter=20 AVP MUST be followed. For example, the AVP code used is the = vendor=20 attribute type code, the Vendor-Specific flag MUST be set to 1 = and the=20 Vendor-ID MUST be set to the IANA Vendor identification value. = The=20 Diameter AVP data field contains only the attribute value of the = RADIUS=20 attribute.=20
I think it will save confusion in the = future.=20

Cheers,=20
Chris.

-----Original Message-----=20
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20
Sent: Tuesday, May 04, 2004 3:53 AM=20
To: Richards, Christopher = [RICH2:2Q40:EXCH]=20
Cc: david@mitton.com; aaa-wg@merit.edu;=20 jari.arkko@kolumbus.fi=20
Subject: RE: [AAA-WG]: Diameter encoding of = RADIUS VSA=20 AVPs

Hi Chris,

>It's not just for translating AVPs on the = fly, but=20 also for how to=20
>re-use existing RADIUS=20
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA = that was=20 defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to = completely=20 redefine it.=20
>From my reading of RFC3588, it says = something along=20 the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I = also took=20 that RADIUS AVP code 26 was included.=20
>As an example, if you have access to 3GPP = TS=20 29.061, take a look at the RADIUS VSAs defined >for 3GPP. =
>When I want to put this information into = a Diameter=20 AVP, do I set the=20
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to = be the=20 generic RADIUS replacement within Diameter. If you just use the = NASREQ=20 defined AVPs, that practically uses those AVP numbers from 1 = through 255=20 you're talking about, you should be able to match the 3GPP TS = 29.061=20 needs.=20
For those 3gpp vendor-specific attributes = defined in TS=20 29.061 I think you should follow the rules defined in NASREQ = section=20 9.6.2, RADIUS Interactions. According to the mentioned rules the = V bit=20 is to be set.
I copied here sect. 9.4 of the NASREQ draft, = that=20 clearly state that attribute code 26 must not appear in Diameter = messages.=20
Regards=20
Marco

9.4 Prohibited RADIUS Attributes =

   The following RADIUS attributes = MUST NOT=20 appear in a Diameter=20
   message.  Instead, they are = translated to other Diameter AVPs or=20
   handled in some special manner. = The rules=20 for the treatment of the=20
   attributes are discussed in = Sections 9.1,=20 9.2 and 9.6.

   Attribute=20 Description      =20 Defined     Nearest Diameter AVP=20
  =20 = ----------------------------------------------------------------- =
    3=20 = CHAP-Password          =  =20 RFC 2865    CHAP-Auth Group=20
   26=20 = Vendor-Specific         =20 RFC 2865    Vendor Specific AVP=20
   29=20 Termination-Action       RFC=20 2865    Authorization-Lifetime=20
   40=20 Acct-Status-Type         = RFC=20 2866    Accounting-Record-Type=20
   42=20 Acct-Input-Octets        RFC=20 2866    Accounting-Input-Octets=20
   43=20 Acct-Output-Octets       RFC=20 2866    Accounting-Output-Octets=20
   47=20 Acct-Input-Packets       RFC=20 2866    Accounting-Input-Packets=20
   48=20 Acct-Output-Packets      RFC=20 2866    Accounting-Output-Packets=20
   49=20 Acct-Terminate-Cause     RFC = 2866   =20 Termination-Cause=20
   52=20 Acct-Input-Gigawords     RFC = 2869   =20 Accounting-Input-Octets=20
   53 = Acct-Output-Gigawords   =20 RFC 2869    Accounting-Output-Octets=20
   80 = Message-Authenticator   =20 RFC 2869    none - check and discard=20 =
------_=_NextPart_001_01C44220.BEB80B30-- From owner-aaa-wg@merit.edu Tue May 25 06:24:29 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 GAA29388 for ; Tue, 25 May 2004 06:24:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D83491269; Tue, 25 May 2004 06:24:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B2179126A; Tue, 25 May 2004 06:24: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 7B26E91269 for ; Tue, 25 May 2004 06:24:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 618E959665; Tue, 25 May 2004 06:24:15 -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 8764159645 for ; Tue, 25 May 2004 06:24:14 -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 i4PAO6v28972; Tue, 25 May 2004 13:24:06 +0300 (EET DST) X-Scanned: Tue, 25 May 2004 13:22:51 +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 i4PAMp6p031853; Tue, 25 May 2004 13:22:51 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00LOmoDh; Tue, 25 May 2004 13:21:24 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 i4PALOH10095; Tue, 25 May 2004 13:21:24 +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, 25 May 2004 13:21:22 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 May 2004 13:21:23 +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_01C44242.070DD28B" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Tue, 25 May 2004 13:21:22 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87A4@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUAAFS0ZAA== From: To: Cc: X-OriginalArrivalTime: 25 May 2004 10:21:23.0033 (UTC) FILETIME=[07431C90:01C44242] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44242.070DD28B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 >Can someone clarify whether event-timestamp AVP is mandatory or not. I = cannot seem to find a MUST (or even SHOULD) >defined. =20 The intention was that event-timestamp SHOULD be present in CCR command. = The AVP is defined in the base. The text concerning this AVP was written at the time when the DCC was = still at individual draft level, since then=20 it has never been updated. =20 Event-timestamp use is described for first, intermediate and final = interrogations as well as for one-time event direct debiting, but the text is not consistent. The folowing sentences = can be found: =20 The Event-Timestamp AVP contains the time when the service event is=20 requested in the service element.=20 =20 The Event-Timestamp AVP contains the time of the event that triggered = the sending of the new Credit-Control-Request. =20 =20 The Event-Timestamp AVP MAY contain the time of the session was=20 terminated. =20 =20 The Event-Timestamp AVP contains the time when the service event is = requested=20 in the service element. =20 The right sentences should be =20 The Event-Timestamp AVP SHOULD be included in the request and contains = the time=20 when the service event is requested in the service element. =20 The Event-Timestamp AVP SHOULD be included in the request and = contains the time of the=20 event that triggered the sending of the new Credit-Control-Request. =20 =20 The Event-Timestamp AVP SHOULD be included in the request and = contains the time=20 when the session was terminated. =20 =20 The Event-Timestamp AVP SHOULD be included in the request and = contains the time=20 when the service event is requested in the service element. =20 I think we need to update this during the IESG review round. =20 Regards Marco ------_=_NextPart_001_01C44242.070DD28B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Mark,
 
>Can someone clarify whether event-timestamp = AVP is=20 mandatory or not. I cannot seem to find a MUST (or even=20 SHOULD)
>defined.
&nbs= p;
The = intention was that=20 event-timestamp SHOULD be present in CCR command. The AVP is defined in = the=20 base.
The text = concerning this=20 AVP was written at the time when the DCC was still at individual draft=20 level, since then =
it has=20 never been = updated.
 
Event-timestamp use is=20 described for first, intermediate and final interrogations as well as = for=20 one-time event
direct = debiting, but the=20 text is not consistent. The folowing sentences can be=20 found:
 
   = The=20 Event-Timestamp AVP contains the time when the service event is =
  =20 requested in the service element.
 

   The Event-Timestamp AVP contains the time of the = event=20 that triggered
   the sending of the new=20 Credit-Control-Request. 
 

   The=20 Event-Timestamp AVP MAY contain the time of the session was =
  =20 terminated.  
 
   = The=20 Event-Timestamp AVP contains the time when the service event is = requested=20
   in the service = element.
 
The right = sentences=20 should be
 
  The Event-Timestamp AVP SHOULD be included in the request=20 and contains the time =
   when the service event is = requested in the=20 service element.
 

   The = Event-Timestamp=20 AVP SHOULD be included in the request and contains the time of the
   event that triggered the = sending of=20 the new Credit-Control-Request. =20
 

   The = Event-Timestamp=20 AVP SHOULD be included in the request and contains the time =
   when the session=20 was terminated.  =20
 
   = The=20 Event-Timestamp AVP SHOULD be included in the request and contains the = time=20
    when=20 the service event is requested in the service=20 element.
 
I think we = need to=20 update this during the IESG review=20 round.
 
Regards
Marco
 ------_=_NextPart_001_01C44242.070DD28B-- From owner-aaa-wg@merit.edu Tue May 25 10:41:01 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 KAA16078 for ; Tue, 25 May 2004 10:41:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 539689126B; Tue, 25 May 2004 10:40:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14EDF9126D; Tue, 25 May 2004 10:40: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 C4F749126B for ; Tue, 25 May 2004 10:40:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA4D859662; Tue, 25 May 2004 10:40:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 231E659660 for ; Tue, 25 May 2004 10:40:41 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 10:40:08 -0400 Message-ID: From: Avi Lior To: "'David Mitton'" , Mark Watson , Christopher Richards , "'marco.stura@nokia.com'" Cc: "'aaa-wg@merit.edu'" , "'jari.arkko@kolumbus.fi'" Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 10:40:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44266.286CE8A0" 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_01C44266.286CE8A0 Content-Type: text/plain David, Where does it say that VSAs were not intended to be used by other SDOs to extend the protocol? Some folks even talked about using Type 26 with Vendor Id of 0 to allow the IETF to extend RADIUS attributes just in case we ran out of RADIUS attributes. IMO it make alot of sense to allow SDOs to extend RADIUS or even Diameter in cases where they dont care about interoperability and thus don't need to cut RFCs for their work. Avi. -----Original Message----- From: David Mitton [mailto:david@mitton.com] Sent: Monday, May 24, 2004 2:54 PM To: Mark Watson; Christopher Richards; 'marco.stura@nokia.com' Cc: 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi' Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 06:04 PM +0100, Mark Watson wrote: Hi David, I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor). VSAs were not intended to be used by other SDOs to extend the protocol. I'm not aware of such use being approved by an IETF WG. RADIUS does not have an "application identifier". Any VSA encodings are assumed to be singular, that is not overlapped in any way. Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs. There's a difference between application dependent semantics, and the actual message encoding. While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability. I'm not sure why an application dependent transformation in Diameter is desirable. Certainly there is enough encoding space to work around any legacy encodings. I guess I could see some rationale, but it's not something that we'd want to standardize. These types of cases are to be avoided. It causes more complexity in proxy agents and gateways. NASes might need to deal with two types of responses or worse yet make two different types of requests. On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved. In the development of Diameter, we choose to change a number of things about RADIUS that were problematic. VSAs were one of these. If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding? Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions. Even if that interoperability is not used.. initially. Comments ? Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application. It should. Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention. ...Mark I'm not sure why, but we could put that on the errata/"bis" list. Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap. Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different? Dave. -----Original Message----- From: David Mitton [mailto:david@mitton.com ] Sent: 24 May 2004 17:50 To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs On 5/24/2004 04:48 PM +0100, Mark Watson wrote: Hi all, So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ? I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base. Any exceptions would have to be justified and dealt with when the specification was reviewed. The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications. RADIUS interfacing is another one of these. Dave. That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ? Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ? Regards...Mark -----Original Message----- From: Richards, Christopher [RICH2:2Q40:EXCH] Sent: 07 May 2004 20:51 To: marco.stura@nokia.com Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Marco, That sounds good. Thanks. Cheers, Chris. Shasta Wireless Development Nortel Networks Telephone: +1 972 684 3281 ESN 444 3281 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Friday, May 07, 2004 2:47 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I better see this kind of text in section 4.1, perhaps slightly modified as follow: When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc. Regards Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com ] Sent: 04 May, 2004 17:53 To: Stura Marco (Nokia-NET/Helsinki) Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_001_01C44266.286CE8A0 Content-Type: text/html Message
David,
 
Where does it say that VSAs were not intended to be used by other SDOs to extend the protocol?
 
Some folks even talked about using Type 26 with Vendor Id of  0 to allow the IETF to extend RADIUS attributes just in case we ran out of RADIUS attributes.
 
IMO it make alot of sense to allow SDOs to extend RADIUS or even Diameter in cases where they dont care about interoperability and thus don't need to cut RFCs for their work.
 
Avi. 
-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: Monday, May 24, 2004 2:54 PM
To: Mark Watson; Christopher Richards; 'marco.stura@nokia.com'
Cc: 'aaa-wg@merit.edu'; 'jari.arkko@kolumbus.fi'
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

On 5/24/2004 06:04 PM +0100, Mark Watson wrote:
Hi David,
 
I am not so much thinking of applications which directly interact with RADIUS as cases where new applications are defined and have a requirement to carry some information for which a RADIUS VSA sub-attribute has already been defined (perhaps by a standardisation organisation, rather than a specific vendor).

VSAs were not intended to be used by other SDOs to extend the protocol.
I'm not aware of such use being approved by an IETF WG.

RADIUS does not have an "application identifier".  Any VSA encodings are assumed to be singular, that is not overlapped in any way.  Most RADIUS server implementations use a flat static dictionary to describe attributes including VSAs. 

There's a difference between application dependent semantics, and the actual message encoding.  While it may essential to treat the contents of an AVP differently in different application contexts, the parsing of the message fields must be mechanical for interoperability.

I'm not sure why an application dependent transformation in Diameter is desirable.   Certainly there is enough encoding space to work around any legacy encodings.

I guess I could see some rationale, but it's not something that we'd want to standardize.  These types of cases are to be avoided.  It causes more complexity in proxy agents and gateways.  NASes might need to deal with two types of responses or worse yet make two different types of requests.


On the basis that re-use is better than re-invention, it would be nice if such applications could re-use the RADIUS VSA sub-attribute definition, even if there is no actual RADIUS interaction involved.

In the development of Diameter, we choose to change a number of things about RADIUS that were problematic.  VSAs were one of these.   If you are going through the trouble of implementing a Diameter application, why not use the native Diameter encoding?  

Likewise the purpose of having one encoding is for the interoperability that results from not having to define/implement more exceptions.   Even if that interoperability is not used.. initially.


Comments ?
 
Another way to put my question would be, is it wise for a Diameter implementation to assume that AVP x with Vendor-ID y always corresponds to the same AVP, independent of the application.

It should. 

Or would it be wiser to assume that the meaning of (AVP x, Vendor y) is application-dependent ? The current specification situation suggests the latter, but I am not sure that is the intention.
 
...Mark

I'm not sure why, but we could put that on the errata/"bis" list.

Even though the use of Diameter AVPs are application dependant, their encoding is coordinated across the Diameter encoding space so there is no overlap.
Could you point to the text in RFC 3588 that gave the impression that VSA AVPs are different?

Dave.

-----Original Message-----
From: David Mitton [mailto:david@mitton.com]
Sent: 24 May 2004 17:50
To: Watson, Mark [MOP:EP10:EXCH]; Richards, Christopher [RICH2:2Q40:EXCH]; marco.stura@nokia.com
Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
On 5/24/2004 04:48 PM +0100, Mark Watson wrote:
Hi all,

 
So, this rule will apply to NASREQ and DCC, but other applications are free to do whatever they like ?

I would think, (subject to any dissent from the group) that any Diameter application that interacts with RADIUS, would adhere to the specifications in Diameter-NASreq as it's base.  Any exceptions would have to be justified and dealt with when the specification was reviewed.

The Diameter Base (RFC3588) specification would be too unwieldy to cover all issues, and parts out certain problems to other specifications.  RADIUS interfacing is another one of these.

Dave.


That is, the AVP code codespace when the Vendor-specific flag is set to 1 is application-specific. The same code may mean different things in different applications. This is unlike the AVP code codespace when the Vendor-specific flag is 0, right ?

 
Would it be better to (also) have a rule for all applications, or at least an 'opt out' rule such as 'unless otherwise specified in a specific application....' ?

 
Regards...Mark

 
-----Original Message-----
From: Richards, Christopher [RICH2:2Q40:EXCH]
Sent: 07 May 2004 20:51
To: marco.stura@nokia.com
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Marco,
That sounds good. Thanks.

Cheers,
Chris.

Shasta Wireless Development
Nortel Networks

Telephone:
+1 972 684 3281
ESN 444 3281
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Friday, May 07, 2004 2:47 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Chris,
Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
I better see this kind of text in section 4.1, perhaps slightly modified as follow:
When service specific documents include RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] ..........etc.
Regards
Marco
-----Original Message-----
From: ext Christopher Richards [mailto:crich@nortelnetworks.com]
Sent: 04 May, 2004 17:53
To: Stura Marco (Nokia-NET/Helsinki)
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs
Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g.
When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute.
I think it will save confusion in the future.

Cheers,
Chris.

-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Chris,

>It's not just for translating AVPs on the fly, but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to completely redefine it.
>From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP.
>When I want to put this information into a Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs.
For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set.
I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages.
Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT appear in a Diameter
   message.  Instead, they are translated to other Diameter AVPs or
   handled in some special manner. The rules for the treatment of the
   attributes are discussed in Sections 9.1, 9.2 and 9.6.

   Attribute Description       Defined     Nearest Diameter AVP
   -----------------------------------------------------------------
    3 CHAP-Password            RFC 2865    CHAP-Auth Group
   26 Vendor-Specific          RFC 2865    Vendor Specific AVP
   29 Termination-Action       RFC 2865    Authorization-Lifetime
   40 Acct-Status-Type         RFC 2866    Accounting-Record-Type
   42 Acct-Input-Octets        RFC 2866    Accounting-Input-Octets
   43 Acct-Output-Octets       RFC 2866    Accounting-Output-Octets
   47 Acct-Input-Packets       RFC 2866    Accounting-Input-Packets
   48 Acct-Output-Packets      RFC 2866    Accounting-Output-Packets
   49 Acct-Terminate-Cause     RFC 2866    Termination-Cause
   52 Acct-Input-Gigawords     RFC 2869    Accounting-Input-Octets
   53 Acct-Output-Gigawords    RFC 2869    Accounting-Output-Octets
   80 Message-Authenticator    RFC 2869    none - check and discard
------_=_NextPart_001_01C44266.286CE8A0-- From owner-aaa-wg@merit.edu Tue May 25 11: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 LAA20932 for ; Tue, 25 May 2004 11:48:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2E7C91203; Tue, 25 May 2004 11:48:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B87249126A; Tue, 25 May 2004 11:48: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 E7DAF91203 for ; Tue, 25 May 2004 11:48:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D135359653; Tue, 25 May 2004 11:48:22 -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 5367D59664 for ; Tue, 25 May 2004 11:48:17 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 25 May 2004 17:54:32 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4PFmD1P014755; Tue, 25 May 2004 17:48:13 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 25 May 2004 17:44:55 +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_01C4426F.AF46CD06" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Tue, 25 May 2004 17:48:12 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUAAFS0ZAAATR7zQ From: "Mark Grayson (mgrayson)" To: Cc: X-OriginalArrivalTime: 25 May 2004 15:44:55.0968 (UTC) FILETIME=[3A45EA00:01C4426F] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4426F.AF46CD06 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marco =20 thanks for that!=20 =20 Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an attacker to charge a third party's account? =20 Thanks, Mark =20 -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 25 May 2004 06:21 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Hi Mark, =20 >Can someone clarify whether event-timestamp AVP is mandatory or not. I cannot seem to find a MUST (or even SHOULD) >defined. =20 The intention was that event-timestamp SHOULD be present in CCR command. The AVP is defined in the base. The text concerning this AVP was written at the time when the DCC was still at individual draft level, since then=20 it has never been updated. =20 Event-timestamp use is described for first, intermediate and final interrogations as well as for one-time event direct debiting, but the text is not consistent. The folowing sentences can be found: =20 The Event-Timestamp AVP contains the time when the service event is=20 requested in the service element.=20 =20 =09 The Event-Timestamp AVP contains the time of the event that triggered=20 the sending of the new Credit-Control-Request. =20 =20 =09 The Event-Timestamp AVP MAY contain the time of the session was=20 terminated. =20 =20 The Event-Timestamp AVP contains the time when the service event is requested=20 in the service element. =20 =09 The right sentences should be =20 The Event-Timestamp AVP SHOULD be included in the request and contains the time=20 when the service event is requested in the service element. =20 The Event-Timestamp AVP SHOULD be included in the request and contains the time of the=20 event that triggered the sending of the new Credit-Control-Request. =20 =20 =09 The Event-Timestamp AVP SHOULD be included in the request and contains the time=20 when the session was terminated. =20 =20 The Event-Timestamp AVP SHOULD be included in the request and contains the time=20 when the service event is requested in the service element. =20 I think we need to update this during the IESG review round. =20 Regards Marco ------_=_NextPart_001_01C4426F.AF46CD06 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Marco
 
thanks=20 for that!
 
Another question I have concerns the handling of subscription = ID AVP in=20 the CCA. What happens if this differs from the value in the CCR. Should = the DCCA=20 client use the returned ID in subseqent CCR messages? Could this be used = by an=20 attacker to charge a third party's account?
 
Thanks,
Mark
 
-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 25 = May=20 2004 06:21
To: Mark Grayson (mgrayson)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event = Time=20 Stamp

Hi=20 Mark,
 
>Can someone clarify whether event-timestamp = AVP is=20 mandatory or not. I cannot seem to find a MUST (or even=20 SHOULD)
>defined.
&nbs= p;
The=20 intention was that event-timestamp SHOULD be present in CCR command. = The AVP=20 is defined in the base.
The text=20 concerning this AVP was written at the time when the DCC was still at=20 individual draft level, since = then=20
it has=20 never been = updated.
 
Event-timestamp use is described for first, = intermediate and final interrogations as well as for one-time=20 event
direct=20 debiting, but the text is not consistent. The folowing sentences = can be=20 found:
 
   The=20 Event-Timestamp AVP contains the time when the service event is=20
   requested in the service element.=20
 

   The = Event-Timestamp=20 AVP contains the time of the event that triggered
   the = sending=20 of the new Credit-Control-Request.  =
 

   The=20 Event-Timestamp AVP MAY contain the time of the session was =
  =20 terminated.  
 
   The=20 Event-Timestamp AVP contains the time when the service event is = requested=20
   in the service = element.
 
The right=20 sentences should be
 
  The Event-Timestamp AVP SHOULD be included in the request=20 and contains the time =
   when the service event is = requested in the=20 service element.
 

   The=20 Event-Timestamp AVP SHOULD be included in the request and contains the time of the =
   event that triggered = the sending=20 of the new Credit-Control-Request. =20
 

   The=20 Event-Timestamp AVP SHOULD be included in the request and = contains the=20 time
   when the session=20 was terminated.  =20
 
   The Event-Timestamp AVP SHOULD = be=20 included in the request and contains the time=20
    when the service event = is=20 requested in the service = element.
 
I think we = need to=20 update this during the IESG review=20 round.
 
Regards
Marco
=00 ------_=_NextPart_001_01C4426F.AF46CD06-- From owner-aaa-wg@merit.edu Tue May 25 13:04: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 NAA29925 for ; Tue, 25 May 2004 13:04:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6519B9126C; Tue, 25 May 2004 13:04:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38A709126E; Tue, 25 May 2004 13:04: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 166E89126C for ; Tue, 25 May 2004 13:04:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEBD759640; Tue, 25 May 2004 13:04:40 -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 F37AB592E2 for ; Tue, 25 May 2004 13:04:39 -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 i4PH4OE04015; Tue, 25 May 2004 20:04:24 +0300 (EET DST) X-Scanned: Tue, 25 May 2004 20:04:06 +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 i4PH46OT032716; Tue, 25 May 2004 20:04:06 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00up2JWh; Tue, 25 May 2004 20:04:06 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 i4PH3pH21603; Tue, 25 May 2004 20:03:51 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 25 May 2004 20:03:50 +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]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 20:03:50 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRCZo6ZFcPCnI+lQnmWFQGRiqtKCAAEyWfA From: To: , , , , Cc: , X-OriginalArrivalTime: 25 May 2004 17:03:51.0179 (UTC) FILETIME=[40ADC5B0:01C4427A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi, > Where does it say that VSAs were not intended to be used by other SDOs = to extend the protocol? clip .. > IMO it make alot of sense to allow SDOs to extend RADIUS or even = Diameter in cases where they dont=20 > care about interoperability and thus don't need to cut RFCs for their = work. SDO I thought stood for Standardization Developement Organzition - the = reason behind SDOs were for creating interoperation between vendors. Vendors, last time I = checked, were generally classified as "someone who exchanges goods or services for = money" - which seems to be different than what an SDO is.=20 YMMV, John From owner-aaa-wg@merit.edu Tue May 25 13:11: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 NAA00548 for ; Tue, 25 May 2004 13:11:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54A969126E; Tue, 25 May 2004 13:11:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 262F091272; Tue, 25 May 2004 13:11: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 163BB9126E for ; Tue, 25 May 2004 13:11:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0031559687; Tue, 25 May 2004 13:11:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id ACCD8596A8 for ; Tue, 25 May 2004 13:11:13 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 May 2004 13:11:13 -0400 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Avi Lior , david@mitton.com, mwatson@nortelnetworks.com, crich@nortelnetworks.com, marco.stura@nokia.com Cc: aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 13:11:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Interoperability between other SDOs that is. At the SDOs vendors get together and agree on how to interoperate amognst themselves. In the case of 3GPP2 they develop 3GPP2 specific VSAs. In this case 3GPP2 can be viewed as super-vendor. The alternative is not to do this and take everything to the IETF. So do you really think that the IETF has the cycles to address all the AAA requirements of all SDOs? Cause I don't. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, May 25, 2004 1:04 PM > To: avi@bridgewatersystems.com; david@mitton.com; > mwatson@nortelnetworks.com; crich@nortelnetworks.com; > marco.stura@nokia.com > Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > Avi, > > > Where does it say that VSAs were not intended to be used by > other SDOs > > to extend the protocol? > > clip .. > > > IMO it make alot of sense to allow SDOs to extend RADIUS or even > > Diameter in cases where they dont > > care about interoperability and thus don't need to cut RFCs > for their work. > > SDO I thought stood for Standardization Developement > Organzition - the reason behind SDOs were for creating > interoperation between vendors. Vendors, last time I > checked, were generally classified as "someone who exchanges > goods or services for money" - which seems to be different > than what an SDO is. > > YMMV, > John > From owner-aaa-wg@merit.edu Tue May 25 16:32: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 QAA16596 for ; Tue, 25 May 2004 16:32:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B560791282; Tue, 25 May 2004 16:32:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EA5991283; Tue, 25 May 2004 16:32: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 29D8F91282 for ; Tue, 25 May 2004 16:32:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 133AC592AB; Tue, 25 May 2004 16:32:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from hermes.jf.intel.com (fmr05.intel.com [134.134.136.6]) by segue.merit.edu (Postfix) with ESMTP id 8277659250 for ; Tue, 25 May 2004 16:32:15 -0400 (EDT) Received: from petasus.jf.intel.com (petasus.jf.intel.com [10.7.209.6]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i4PKX4ca006803; Tue, 25 May 2004 20:33:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i4PKW8Dm021864; Tue, 25 May 2004 20:32:40 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004052513314827985 ; Tue, 25 May 2004 13:31:48 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 25 May 2004 13:31:48 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 25 May 2004 13:31:47 -0700 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRCfH50ZIGBcAyxSrqqsz/lBt4EaQAFBtTg From: "Adrangi, Farid" To: "Avi Lior" , , , , , Cc: , X-OriginalArrivalTime: 25 May 2004 20:31:48.0399 (UTC) FILETIME=[4DAE73F0:01C44297] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Sorry for jumping in this ... =20 IMO, taking all VSAs defined within an SDO to IETF for standardization may not be a practical thing to do as Avi stated. Rather, the idea should be to identify VSAs that are commonly defined across SDOs (same in concept, but different in format/syntax and perhaps content) or VSAs that can be used by other SDOs and standardize them at IETF. To best of my knowledge, VSAs defined within an SDO are intended to provide "intra" interoperability (i.e., amongst the SDO's vendors). BR, Farid > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]=20 > On Behalf Of Avi Lior > Sent: Tuesday, May 25, 2004 10:11 AM > To: 'john.loughney@nokia.com'; Avi Lior; david@mitton.com;=20 > mwatson@nortelnetworks.com; crich@nortelnetworks.com;=20 > marco.stura@nokia.com > Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs >=20 >=20 > Interoperability between other SDOs that is. >=20 > At the SDOs vendors get together and agree on how to=20 > interoperate amognst themselves. In the case of 3GPP2 they=20 > develop 3GPP2 specific VSAs. In this case 3GPP2 can be=20 > viewed as super-vendor. >=20 > The alternative is not to do this and take everything to the=20 > IETF. So do you really think that the IETF has the cycles to=20 > address all the AAA requirements of all SDOs? Cause I don't. >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Tuesday, May 25, 2004 1:04 PM > > To: avi@bridgewatersystems.com; david@mitton.com;=20 > > mwatson@nortelnetworks.com; crich@nortelnetworks.com;=20 > > marco.stura@nokia.com > > Cc: aaa-wg@merit.edu; jari.arkko@kolumbus.fi > > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > >=20 > >=20 > > Avi, > >=20 > > > Where does it say that VSAs were not intended to be used by > > other SDOs > > > to extend the protocol? > >=20 > > clip .. > >=20 > > > IMO it make alot of sense to allow SDOs to extend RADIUS or even > > > Diameter in cases where they dont > > > care about interoperability and thus don't need to cut RFCs=20 > > for their work. > >=20 > > SDO I thought stood for Standardization Developement > > Organzition - the reason behind SDOs were for creating=20 > > interoperation between vendors. Vendors, last time I=20 > > checked, were generally classified as "someone who exchanges=20 > > goods or services for money" - which seems to be different=20 > > than what an SDO is.=20 > >=20 > > YMMV, > > John > >=20 >=20 From owner-aaa-wg@merit.edu Tue May 25 23:23: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 XAA18547 for ; Tue, 25 May 2004 23:23:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2871D9120E; Tue, 25 May 2004 23:22:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F04D191210; Tue, 25 May 2004 23:22: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 BFBEF9120E for ; Tue, 25 May 2004 23:22:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A80A5596AD; Tue, 25 May 2004 23:22:48 -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 4DB9F59680 for ; Tue, 25 May 2004 23:22:34 -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 i4Q3MUE07762; Wed, 26 May 2004 06:22:30 +0300 (EET DST) X-Scanned: Wed, 26 May 2004 06:21:52 +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 i4Q3LqFl011208; Wed, 26 May 2004 06:21:52 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 001w92Nu; Wed, 26 May 2004 06:21:50 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 i4Q3LnH05395; Wed, 26 May 2004 06:21:49 +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); Wed, 26 May 2004 06:21:38 +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]: Diameter encoding of RADIUS VSA AVPs Date: Wed, 26 May 2004 06:21:36 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRCe2WkFwldCr//R6ac2XjNkbHYCgAVHohA From: To: , , , , Cc: , X-OriginalArrivalTime: 26 May 2004 03:21:38.0299 (UTC) FILETIME=[8E676CB0:01C442D0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Avi, > Interoperability between other SDOs that is. If it were so simple, I might have an easier time agreeing, but we do know of several operators deploying 3GPP and 3GPP2 networks in different places of the the world - they may have some need for interoperability between these networks. Also, different SDOs (GSMA, IEEE) have interest in AAA standardization and the output of these bodies may in fact be used by other SDOs. =20 To put it differently, if the feature is worth standardizing, why wouldn't interoperability (at some point) be a good thing? =20 =20 > At the SDOs vendors get together and agree on how to interoperate = amognst > themselves. In the case of 3GPP2 they develop 3GPP2 specific VSAs. = In this > case 3GPP2 can be viewed as super-vendor. Taking this literally, I don't buy it. The super-vendor is not selling hardware/software/services, and if you're point is taken literally, I am sure anti-trust regulators might have something to look into. =20 > The alternative is not to do this and take everything to the IETF. So = do > you really think that the IETF has the cycles to address all the AAA > requirements of all SDOs? Cause I don't. There's the rub, I agree. I would say that the IETF doesn't have the=20 cycles, processes nor will even to do this. However, I believe that is a discussion happening elsewhere, in one of the IETF process-oriented working groups. However, let's just say that I understand your point and agree we have = to live with it, however I am not sure that the IETF should give its = blessing to it. John From owner-aaa-wg@merit.edu Tue May 25 23:53:54 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 XAA19483 for ; Tue, 25 May 2004 23:53:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 04D8091285; Tue, 25 May 2004 23:53:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C048691287; Tue, 25 May 2004 23:53:41 -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 C0B2291285 for ; Tue, 25 May 2004 23:53:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ABB95596A0; Tue, 25 May 2004 23:53:40 -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 EBA86596E7 for ; Tue, 25 May 2004 23:53:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4Q3u6a02377; Tue, 25 May 2004 20:56:06 -0700 Date: Tue, 25 May 2004 20:56:06 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 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 > There's the rub, I agree. I would say that the IETF doesn't have the > cycles, processes nor will even to do this. However, I believe that is > a discussion happening elsewhere, in one of the IETF process-oriented > working groups. Actually, I would say that the IETF is struggling with the extensibility issue in general. One potential model for AAA long term is the SNMP extensibility model -- enabling SDOs to create their own MIBs, but providing review via MIB Doctors and reserving protocol changes to the IETF. Many of the issues that we have with SDO extensions derive from the lack of a cleanly articulated data model in AAA. For example, in SNMP there is no difference in the data model between enterprise and standard MIBs. This makes it possible to develop an enterprise MIB and bring it over into the standards space without large scale changes. But that is not the case with RADIUS -- VSAs have more variation and flexibility than standard attributes do. I believe that is inherently problematic -- because it creates issues with bringing widely deployed vendor-specific attributes into the standards space, as we have seen. I would hope that over time we would be able to move more towards the SNMP model in AAA -- where the data model is homogeneous between the enterprise and standards space, where there are well articulated guidelines for application design, and where there is a AAA Doctors group to assist IETF WGs and SDOs in proper AAA application design. That way, the IETF can focus on what it cares about most -- interoperability between implementations, while satisfying SDO needs for AAA application review without having to spawn an endless stream of new WG work items. We're trying this approach now with IEEE 802.1, with David Harrington serving as the MIB Doctor in residence. The old approach of handling IEEE 802.1 MIBs in the IETF Bridge WG was no longer working, due to cutbacks in standards budgets. So we will see how this more "lightweight" model works out for SNMP. From owner-aaa-wg@merit.edu Wed May 26 05:37: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 FAA02751 for ; Wed, 26 May 2004 05:37:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2CFC9128A; Wed, 26 May 2004 05:37:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A02479128E; Wed, 26 May 2004 05:37:05 -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 8C4FB9128A for ; Wed, 26 May 2004 05:37:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68726596A0; Wed, 26 May 2004 05:37:04 -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 D773559656 for ; Wed, 26 May 2004 05:37:03 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EBBE789874; Wed, 26 May 2004 12:36:56 +0300 (EEST) Message-ID: <40B46456.3050304@kolumbus.fi> Date: Wed, 26 May 2004 12:33:10 +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: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs References: 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: > But that is not the case with RADIUS -- VSAs have more variation and > flexibility than standard attributes do. I believe that is inherently > problematic -- because it creates issues with bringing widely deployed > vendor-specific attributes into the standards space, as we have seen. I believe this is the crux of the problem -- the bits are different, and not just the official status of the extension. If you add a difference in expressive power (in either direction) and significant timeliness differences, this brings even greater problems. Where does that leave us? I think we need (a) Vendors and SDOs doing their own things in an easy manner, without having to bring everything to the IETF. (b) IETF specialist assistance in the above, where needed. (c) Migration towards the same expressive power and technical solutions whether its IETF standard, other SDO standard, or vendor specific solution. (d) Recognition that some of the solutions originally intended as an SDO-internal mechanism end up being a global interoperability issue. Example: replacement of FOOBAR SDO radio with wireless LANs, and expecting mobility or something like that to still work. Another example: developing a SDO specific multimedia network, and then later realizing the need for that network to interoperate with another SDO's multimedia network. Anyway, we started this discussion from the rules regarding RADIUS VSA usage in Diameter. Have we concluded what to do for that? There was a suggestion to specify in RADEXT what the universal and application specific VSA rules are, but it isn't clear to me what attributes belong to which part. Do we have suggested text? --Jari From owner-aaa-wg@merit.edu Wed May 26 05:41:18 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 FAA02879 for ; Wed, 26 May 2004 05:41:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F0DD59128E; Wed, 26 May 2004 05:41:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE40C9128F; Wed, 26 May 2004 05:41:03 -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 531B89128E for ; Wed, 26 May 2004 05:41:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2280459701; Wed, 26 May 2004 05:41:02 -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 87DAD596FA for ; Wed, 26 May 2004 05:41:01 -0400 (EDT) Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4Q9etAh001717 for ; Wed, 26 May 2004 11:40:55 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 May 2004 11:40:55 +0200 Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id LFSY8YTR; Wed, 26 May 2004 11:40:55 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 26 May 2004 11:40:55 +0200 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476AA57@eestqnt105.es.eu.ericsson.se> X-Sybari-Trust: dc254a09 3becbf40 856156a7 00000139 From: "David Mariblanca (ML/EEM)" To: aaa-wg@merit.edu Cc: radiusext@ops.ietf.org Subject: [AAA-WG]: FW: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt Date: Wed, 26 May 2004 11:40:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C44305.88FFA921" X-OriginalArrivalTime: 26 May 2004 09:40:55.0446 (UTC) FILETIME=[8AB87B60:01C44305] 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_000_01C44305.88FFA921 Content-Type: text/plain; charset="ISO-8859-1" Hi all, probably you have read this announcement. Comments to the paper are welcome, please send them to this AAA WG list. Thanks and best regards, David. -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: martes, 25 de mayo de 2004 17:03 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : EAP lower layer attributes for AAA protocols Author(s) : D. Mariblanca Filename : draft-mariblanca-aaa-eap-lla-00.txt Pages : 6 Date : 2004-5-24 This document defines a new AVP to be transported in RADIUS or Diameter when EAP is carried over these protocols. The purpose of this AVP is to determine which layer 2 protocol was used to encapsulate the EAP messages at the point they were initiated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-mariblanca-aaa-eap-lla-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C44305.88FFA921 Content-Type: message/rfc822 To: Subject: Date: Wed, 26 May 2004 11:40:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C44305.88FFA921" ------_=_NextPart_002_01C44305.88FFA921 Content-Type: text/plain ------_=_NextPart_002_01C44305.88FFA921 Content-Type: application/octet-stream; name="ATT34897" Content-Disposition: attachment; filename="ATT34897" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-5-24153224.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt ------_=_NextPart_002_01C44305.88FFA921 Content-Type: message/external-body; site="internet-drafts"; dir="draft-mariblanca-aaa-eap-lla-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C44305.88FFA921-- ------_=_NextPart_000_01C44305.88FFA921 Content-Type: text/plain; name="ATT3489756.txt" Content-Disposition: attachment; filename="ATT3489756.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C44305.88FFA921-- From owner-aaa-wg@merit.edu Wed May 26 05:57:21 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 FAA04042 for ; Wed, 26 May 2004 05:57:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A21749128F; Wed, 26 May 2004 05:57:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D6BA91209; Wed, 26 May 2004 05:57: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 EADD39128F for ; Wed, 26 May 2004 05:57:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD5CB596D5; Wed, 26 May 2004 05:57:08 -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 2A5D0592EC for ; Wed, 26 May 2004 05:57:08 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 1A8FE8986F; Wed, 26 May 2004 12:57:07 +0300 (EEST) Message-ID: <40B4690F.8050404@kolumbus.fi> Date: Wed, 26 May 2004 12:53: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: "David Mariblanca (ML/EEM)" , Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: FW: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt References: <1AB3D30B989BF141BBD5C70057B2EF7C0476AA57@eestqnt105.es.eu.ericsson.se> In-Reply-To: <1AB3D30B989BF141BBD5C70057B2EF7C0476AA57@eestqnt105.es.eu.ericsson.se> 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 David, I like this draft, particularly the fact that its short, simple and to the point. Given that it is simple, I wonder if we could move it forward pretty quickly. A couple of nits: - At the beginning of Section 3.1, I believe there should be a paragraph break (an empty line) after the fifth line. - I believe we need an IANA Considerations section. Suggested text: XXX. IANA Considerations New values for the EAP-Lower-Layer AVP are to be allocated by First Come First Served [RFC 2434], in accordance with RADIUS and Diameter IANA guidelines [RFC 3575] [RFC 3588]. Question to Bernard: I can see that RFC 3575 says Designated Expert while RFC 3588 says FCFS. I wonder if that's a problem. I think the latter makes more sense. - RFC 2119 missing from the reference list. - Split references list into Normative and Informative sections. Or, in the case of this draft you just need the former, so maybe its sufficient to rename the current section to "Normative References". --Jari David Mariblanca (ML/EEM) wrote: > Hi all, > probably you have read this announcement. Comments to the paper are welcome, please send them to this AAA WG list. > > Thanks and best regards, > David. > > > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org]On Behalf Of > Internet-Drafts@ietf.org > Sent: martes, 25 de mayo de 2004 17:03 > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : EAP lower layer attributes for AAA protocols > Author(s) : D. Mariblanca > Filename : draft-mariblanca-aaa-eap-lla-00.txt > Pages : 6 > Date : 2004-5-24 > > This document defines a new AVP to be transported in RADIUS or > Diameter when EAP is carried over these protocols. The purpose of > this AVP is to determine which layer 2 protocol was used to > encapsulate the EAP messages at the point they were initiated. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-mariblanca-aaa-eap-lla-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > ------------------------------------------------------------------------ > > Date: > Wed, 26 May 2004 11:40:55 +0200 > > MIME-Version: > 1.0 > X-Mailer: > Internet Mail Service (5.5.2653.19) > Content-Type: > multipart/mixed; boundary="----_=_NextPart_002_01C44305.88FFA921" > > > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce From owner-aaa-wg@merit.edu Wed May 26 06:36: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 GAA06653 for ; Wed, 26 May 2004 06:36:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 957EE91292; Wed, 26 May 2004 06:36:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60D1D91294; Wed, 26 May 2004 06:36: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 1837A91292 for ; Wed, 26 May 2004 06:36:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ECE075959C; Wed, 26 May 2004 06:36:07 -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 ED59059492 for ; Wed, 26 May 2004 06:36:06 -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 i4QAZuE03687; Wed, 26 May 2004 13:35:56 +0300 (EET DST) X-Scanned: Wed, 26 May 2004 13:34:35 +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 i4QAYZeM002810; Wed, 26 May 2004 13:34:35 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 003t67i1; Wed, 26 May 2004 13:34:33 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 i4QAYVH03430; Wed, 26 May 2004 13:34:31 +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); Wed, 26 May 2004 13:34:23 +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]: Diameter encoding of RADIUS VSA AVPs Date: Wed, 26 May 2004 13:34:22 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRDBRAHgyCdHZtlSWeBT4HvUQUXzwAB8Mzg From: To: , Cc: X-OriginalArrivalTime: 26 May 2004 10:34:23.0077 (UTC) FILETIME=[029E2150:01C4430D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Jari & Bernard, > I believe this is the crux of the problem -- the bits are > different, and not just the official status of the extension. > If you add a difference in expressive power (in either > direction) and significant timeliness differences, this > brings even greater problems. >=20 > Where does that leave us? I think we need >=20 > (a) Vendors and SDOs doing their own things in > an easy manner, without having to bring everything > to the IETF. >=20 > (b) IETF specialist assistance in the above, where > needed. >=20 > (c) Migration towards the same expressive power and > technical solutions whether its IETF standard, > other SDO standard, or vendor specific solution. >=20 > (d) Recognition that some of the solutions originally > intended as an SDO-internal mechanism end up being > a global interoperability issue. Example: replacement > of FOOBAR SDO radio with wireless LANs, and expecting > mobility or something like that to still work. Another > example: developing a SDO specific multimedia network, > and then later realizing the need for that network > to interoperate with another SDO's multimedia network. We probably need one (or two things) more: (e) Guidelines on Diameter & RADIUS extensiblitity. I think someone already mentioned that a guideline (or BCP) on how to define Diameter applications would be a good thing. John From owner-aaa-wg@merit.edu Wed May 26 08:31:30 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 IAA13005 for ; Wed, 26 May 2004 08:31:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0AA3F91211; Wed, 26 May 2004 08:31:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C44BE91216; Wed, 26 May 2004 08:31:05 -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 46A1991211 for ; Wed, 26 May 2004 08:31:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24B7F59492; Wed, 26 May 2004 08:31:04 -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 E0AD75923B for ; Wed, 26 May 2004 08:31:02 -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 i4QCUMS13927; Wed, 26 May 2004 15:30:22 +0300 (EET DST) X-Scanned: Wed, 26 May 2004 15:29:45 +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 i4QCTjrs011698; Wed, 26 May 2004 15:29:45 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00MH732e; Wed, 26 May 2004 15:29:43 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 i4QCThH07114; Wed, 26 May 2004 15:29:43 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 May 2004 15:29:43 +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_01C4431D.1F4536AD" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 15:29:43 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87B3@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUAAFS0ZAAATR7zQACam6lA= From: To: Cc: X-OriginalArrivalTime: 26 May 2004 12:29:43.0291 (UTC) FILETIME=[1F62FCB0:01C4431D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4431D.1F4536AD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mark, =20 >Another question I have concerns the handling of subscription ID AVP in = the CCA. What happens if this differs from the=20 >value in the CCR. Should the DCCA client use the returned ID in = subseqent CCR messages? Could this be used by an=20 >attacker to charge a third party's account? =20 An authenticated identity must always be used in a Subscription-Id AVP = in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The = Subscription-id(s) to be used may also be=20 returned by the AAA server in the successful AA-answer that = authenticated the user, this is to be used in CCR messages sent = thereafter. The security section discusses recommendations how to prevent an = attacker to modify CCR/CCA messages, basically using TLS or IPSec. =20 Regards Marco ------_=_NextPart_001_01C4431D.1F4536AD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Mark,
 
>Another=20 question I have concerns the handling of subscription ID AVP in the CCA. = What=20 happens if this differs from the
>value in the=20 CCR. Should the DCCA client use the returned ID in subseqent CCR = messages? Could=20 this be used by an
>attacker to=20 charge a third party's account?
 
An authenticated identity must always be used = in a=20 Subscription-Id AVP in all the CCR messages, authentication=20 is
not performed with the DCC application but = e.g. with=20 NASREQ or EAP. The Subscription-id(s) to be used may also be
returned by the AAA server in the successful = AA-answer=20 that authenticated the user, this is to be used in CCR messages sent=20 thereafter.
The security section discusses = recommendations how to=20 prevent an attacker to modify CCR/CCA messages,=20 basically
using TLS or = IPSec.
 
Regards
Marco
= ------_=_NextPart_001_01C4431D.1F4536AD-- From owner-aaa-wg@merit.edu Wed May 26 08:33: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 IAA13078 for ; Wed, 26 May 2004 08:33:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DD4991212; Wed, 26 May 2004 08:32:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B7D791216; Wed, 26 May 2004 08:32: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 E847B91212 for ; Wed, 26 May 2004 08:32:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4DA859620; Wed, 26 May 2004 08:32:57 -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 12B4059608 for ; Wed, 26 May 2004 08:32:57 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 May 2004 14:39:27 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4QCWp1R012355; Wed, 26 May 2004 14:32:53 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 May 2004 14:29:33 +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_01C4431D.8EA2FCF6" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 14:32:49 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUAAFS0ZAAATR7zQACam6lAABOoUwA== From: "Mark Grayson (mgrayson)" To: Cc: X-OriginalArrivalTime: 26 May 2004 12:29:33.0078 (UTC) FILETIME=[194C9B60:01C4431D] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4431D.8EA2FCF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable so what is the rationale for having the subscription ID returned in the CCA? =20 Cheers, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 26 May 2004 08:30 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp =09 =09 Hi Mark, =20 >Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the=20 >value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an=20 >attacker to charge a third party's account? =20 An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be=20 returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter. The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically using TLS or IPSec. =20 Regards Marco ------_=_NextPart_001_01C4431D.8EA2FCF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
so=20 what is the rationale for having the subscription ID returned in = the=20 CCA?
 
Cheers,
Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: = 26 May=20 2004 08:30
To: Mark Grayson (mgrayson)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event = Time=20 Stamp

Hi=20 Mark,
 
>Another question I have concerns the = handling of=20 subscription ID AVP in the CCA. What happens if this differs from the=20
>value in the CCR. Should the DCCA client = use the=20 returned ID in subseqent CCR messages? Could this be used by an=20
>attacker to charge a third party's=20 account?
 
An = authenticated=20 identity must always be used in a Subscription-Id AVP in all the = CCR=20 messages, authentication is
not = performed with the=20 DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to = be used=20 may also be=20
returned by the AAA server in the = successful=20 AA-answer that authenticated the user, this is to be used in CCR = messages sent=20 thereafter.
The = security section=20 discusses recommendations how to prevent an attacker to modify CCR/CCA = messages, basically
using TLS = or=20 IPSec.
 
Regards
Marco
<= /BODY> =00 ------_=_NextPart_001_01C4431D.8EA2FCF6-- From owner-aaa-wg@merit.edu Wed May 26 09:06: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 JAA14536 for ; Wed, 26 May 2004 09:06:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3D30191216; Wed, 26 May 2004 09:06:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08D1D91218; Wed, 26 May 2004 09:06:11 -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 7321791216 for ; Wed, 26 May 2004 09:06:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 58BF85959F; Wed, 26 May 2004 09:06:10 -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 349DC596A0 for ; Wed, 26 May 2004 09:05:38 -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 i4QD5No04724; Wed, 26 May 2004 16:05:24 +0300 (EET DST) X-Scanned: Wed, 26 May 2004 16:00:14 +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 i4QD0Ea7005713; Wed, 26 May 2004 16:00:14 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00sPN4YG; Wed, 26 May 2004 15:58:20 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 i4QCvZH16088; Wed, 26 May 2004 15:57:35 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 26 May 2004 15:55: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_01C44320.C2B296AE" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 15:55:45 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D018B0573@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcQdpXv3bXROmLFnTR+OTGUX+bfpdQDglYKwCClgaUAAFS0ZAAATR7zQACam6lAABOoUwAAAlviA From: To: Cc: X-OriginalArrivalTime: 26 May 2004 12:55:46.0081 (UTC) FILETIME=[C2E1D110:01C44320] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C44320.C2B296AE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >so what is the rationale for having the subscription ID returned in the = CCA? =20 Good question! =20 I cannot recall the reason why is in CCA, I tried to dig out in the aaa = mail archive but I didn't find any hint. My opinion is that it shouldn't be there, = there is actually no use for it. =20 Marco -----Original Message----- From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: 26 May, 2004 15:33 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp so what is the rationale for having the subscription ID returned in the = CCA? =20 Cheers, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 26 May 2004 08:30 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Hi Mark, =20 >Another question I have concerns the handling of subscription ID AVP in = the CCA. What happens if this differs from the=20 >value in the CCR. Should the DCCA client use the returned ID in = subseqent CCR messages? Could this be used by an=20 >attacker to charge a third party's account? =20 An authenticated identity must always be used in a Subscription-Id AVP = in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The = Subscription-id(s) to be used may also be=20 returned by the AAA server in the successful AA-answer that = authenticated the user, this is to be used in CCR messages sent = thereafter. The security section discusses recommendations how to prevent an = attacker to modify CCR/CCA messages, basically using TLS or IPSec. =20 Regards Marco ------_=_NextPart_001_01C44320.C2B296AE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
>so what is=20 the rationale for having the subscription ID returned in the=20 CCA?
 
Good=20 question!
 
I=20 cannot recall the reason why is in CCA, I tried to dig out in the aaa = mail=20 archive
but I didn't find any hint. My opinion is that it shouldn't be = there, there is=20 actually
no use for=20 it.
 
Marco
-----Original Message-----
From: ext Mark Grayson = (mgrayson)=20 [mailto:mgrayson@cisco.com]
Sent: 26 May, 2004 = 15:33
To:=20 Stura Marco (Nokia-NET/Helsinki)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event = Time=20 Stamp

so=20 what is the rationale for having the subscription ID returned in = the=20 CCA?
 
Cheers,
Mark
-----Original Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 26 May=20 2004 08:30
To: Mark Grayson (mgrayson)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: = Event Time=20 Stamp

Hi=20 Mark,
 
>Another question I have concerns the = handling of=20 subscription ID AVP in the CCA. What happens if this differs from = the=20
>value in the CCR. Should the DCCA = client use the=20 returned ID in subseqent CCR messages? Could this be used by an=20
>attacker to charge a third party's=20 account?
 
An = authenticated=20 identity must always be used in a Subscription-Id AVP in all = the CCR=20 messages, authentication is
not = performed with=20 the DCC application but e.g. with NASREQ or EAP. The = Subscription-id(s) to=20 be used may also be=20
returned by the AAA server in the = successful=20 AA-answer that authenticated the user, this is to be used in CCR = messages=20 sent = thereafter.
The = security section=20 discusses recommendations how to prevent an attacker to modify = CCR/CCA=20 messages, basically
using = TLS or=20 IPSec.
 
Regards
Marco
<= /BLOCKQUOTE> ------_=_NextPart_001_01C44320.C2B296AE-- From owner-aaa-wg@merit.edu Wed May 26 09:10:30 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 JAA14790 for ; Wed, 26 May 2004 09:10:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 71D7591294; Wed, 26 May 2004 09:10:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3705991290; Wed, 26 May 2004 09: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 C311591299 for ; Wed, 26 May 2004 09:10:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC18B5959F; Wed, 26 May 2004 09:10:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin.ericsson.se (penguin.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id 20136596C9 for ; Wed, 26 May 2004 09:10:07 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4QDA4PA005030 for ; Wed, 26 May 2004 15:10:04 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 26 May 2004 15:10:04 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 26 May 2004 15:10:04 +0200 Message-ID: From: "Harri Hakala (JO/LMF)" To: "'marco.stura@nokia.com'" , mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 15:10:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44322.5572EF44" X-OriginalArrivalTime: 26 May 2004 13:10:04.0446 (UTC) FILETIME=[C281EBE0:01C44322] 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_01C44322.5572EF44 Content-Type: text/plain; charset="ISO-8859-1" Hi, We do not need the subscription-id in the CCA command, so it may be better to remove it, since it cause confusion. regards....Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com Sent: 26. toukokuuta 2004 15:56 To: mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp >so what is the rationale for having the subscription ID returned in the CCA? Good question! I cannot recall the reason why is in CCA, I tried to dig out in the aaa mail archive but I didn't find any hint. My opinion is that it shouldn't be there, there is actually no use for it. Marco -----Original Message----- From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: 26 May, 2004 15:33 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp so what is the rationale for having the subscription ID returned in the CCA? Cheers, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 26 May 2004 08:30 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Hi Mark, >Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the >value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an >attacker to charge a third party's account? An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter. The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically using TLS or IPSec. Regards Marco ------_=_NextPart_001_01C44322.5572EF44 Content-Type: text/html; charset="ISO-8859-1" Message
Hi,
 
We do not need the subscription-id in the CCA command, so it may be better 
to remove it, since it cause confusion.
 
regards....Harri
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com
Sent: 26. toukokuuta 2004 15:56
To: mgrayson@cisco.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

>so what is the rationale for having the subscription ID returned in the CCA?
 
Good question!
 
I cannot recall the reason why is in CCA, I tried to dig out in the aaa mail archive
but I didn't find any hint. My opinion is that it shouldn't be there, there is actually
no use for it.
 
Marco
-----Original Message-----
From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]
Sent: 26 May, 2004 15:33
To: Stura Marco (Nokia-NET/Helsinki)
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

so what is the rationale for having the subscription ID returned in the CCA?
 
Cheers,
Mark
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 26 May 2004 08:30
To: Mark Grayson (mgrayson)
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

Hi Mark,
 
>Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the
>value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an
>attacker to charge a third party's account?
 
An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is
not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be
returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter.
The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically
using TLS or IPSec.
 
Regards
Marco
------_=_NextPart_001_01C44322.5572EF44-- From owner-aaa-wg@merit.edu Wed May 26 10:05:00 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 KAA17505 for ; Wed, 26 May 2004 10:04:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07C5B91296; Wed, 26 May 2004 10:04:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C945D91298; Wed, 26 May 2004 10:04: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 1D3C291296 for ; Wed, 26 May 2004 10:04:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 09E2E594A6; Wed, 26 May 2004 10:04: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 1DA8559266 for ; Wed, 26 May 2004 10:04:42 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 May 2004 16:11:14 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4QE4c1P000912; Wed, 26 May 2004 16:04:38 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 May 2004 16:01:19 +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_01C4432A.615F6AC4" Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 16:04:37 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Event Time Stamp Thread-Index: AcRDIsqffMKDk64CSwCwppWqtQ9FMQAB2NEw From: "Mark Grayson (mgrayson)" To: "Harri Hakala (JO/LMF)" , Cc: X-OriginalArrivalTime: 26 May 2004 14:01:19.0625 (UTC) FILETIME=[EB74FF90:01C44329] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4432A.615F6AC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ok sounds good - also FYI, a typo exists on page 17 - multiple-service-credit-control, should be multiple-services-credit-control =20 Cheers, Mark -----Original Message----- From: Harri Hakala (JO/LMF) [mailto:harri.hakala@ericsson.com]=20 Sent: 26 May 2004 09:10 To: 'marco.stura@nokia.com'; Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp =09 =09 Hi, =20 =09 We do not need the subscription-id in the CCA command, so it may be better=20 to remove it, since it cause confusion. =20 regards....Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com Sent: 26. toukokuuta 2004 15:56 To: mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp =09 =09 >so what is the rationale for having the subscription ID returned in the CCA? =20 Good question! =20 I cannot recall the reason why is in CCA, I tried to dig out in the aaa mail archive but I didn't find any hint. My opinion is that it shouldn't be there, there is actually no use for it. =20 Marco -----Original Message----- From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: 26 May, 2004 15:33 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp =09 =09 so what is the rationale for having the subscription ID returned in the CCA? =20 Cheers, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]=20 Sent: 26 May 2004 08:30 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp =09 =09 Hi Mark, =20 >Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the=20 >value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an=20 >attacker to charge a third party's account? =20 An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be=20 returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter. The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically using TLS or IPSec. =20 Regards Marco ------_=_NextPart_001_01C4432A.615F6AC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
ok=20 sounds good - also FYI, a typo exists on page 17 -=20 multiple-service-credit-control, should be=20 multiple-services-credit-control
 
Cheers,
Mark
-----Original Message-----
From: = Harri Hakala=20 (JO/LMF) [mailto:harri.hakala@ericsson.com]
Sent: 26 May = 2004=20 09:10
To: 'marco.stura@nokia.com'; Mark Grayson=20 (mgrayson)
Cc: aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Event Time Stamp

Hi,
 
We do not = need the subscription-id in the CCA = command, = so=20 it=20 may be better 
to remove=20 it, since it cause=20 confusion.
 
regards....Harri
-----Original Message-----
From: = owner-aaa-wg@merit.edu=20 [mailto:owner-aaa-wg@merit.edu]On Behalf Of=20 marco.stura@nokia.com
Sent: 26. toukokuuta 2004=20 15:56
To: mgrayson@cisco.com
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: = Event Time=20 Stamp

>so what is the rationale for having the = subscription ID=20 returned in the CCA?
 
Good question!
 
I=20 cannot recall the reason why is in CCA, I tried to dig out in the = aaa mail=20 archive
but I didn't find any hint. My = opinion is that it=20 shouldn't be there, there is=20 actually
no = use for=20 it.
 
Marco
-----Original Message-----
From: ext Mark = Grayson=20 (mgrayson) [mailto:mgrayson@cisco.com]
Sent: 26 May, = 2004=20 15:33
To: Stura Marco (Nokia-NET/Helsinki)
Cc: = aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: = Event=20 Time Stamp

so what is the rationale for having the subscription = ID=20 returned in the CCA?
 
Cheers,
Mark
-----Original = Message-----
From:=20 marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: 26=20 May 2004 08:30
To: Mark Grayson = (mgrayson)
Cc:=20 aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: = Event=20 Time Stamp

Hi Mark,
 
>Another question I have concerns = the handling=20 of subscription ID AVP in the CCA. What happens if this differs = from the=20
>value in the CCR. Should the DCCA = client use=20 the returned ID in subseqent CCR messages? Could this be used by = an=20
>attacker to charge a third party's=20 account?
 
An = authenticated=20 identity must always be used in a Subscription-Id AVP in = all the=20 CCR messages, authentication is
not = performed=20 with the DCC application but e.g. with NASREQ or EAP. The=20 Subscription-id(s) to be used may also be=20
returned by the AAA server in the = successful=20 AA-answer that authenticated the user, this is to be used in CCR = messages sent=20 = thereafter.
The = security=20 section discusses recommendations how to prevent an attacker to = modify=20 CCR/CCA messages, basically
using TLS or=20 IPSec.
 
Regards
Marco
<= /BLOCKQUOTE>
=00 ------_=_NextPart_001_01C4432A.615F6AC4-- From mxsabiniarz@wp.pl Wed May 26 12:05:18 2004 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25816 for ; Wed, 26 May 2004 12:05:18 -0400 (EDT) Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BT0u7-00025s-Tc for aaa-archive@ietf.org; Wed, 26 May 2004 12:05:20 -0400 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BT0t6-0001zy-00 for aaa-archive@ietf.org; Wed, 26 May 2004 12:04:16 -0400 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1BT0sX-0001uu-00 for aaa-archive@ietf.org; Wed, 26 May 2004 12:03:41 -0400 Received: from c-67-172-57-148.client.comcast.net ([67.172.57.148] helo=68.195.77.93) by mx2.foretec.com with smtp (Exim 4.24) id 1BT0sT-0007DK-Ge for aaa-archive@ietf.org; Wed, 26 May 2004 12:03:39 -0400 Received: from mail2.tda-inc.com (mail2.tda-inc.com [65.219.50.26]) by mail1.synacor.com with smtp; May, 26 2004 17:52:05 +0600 From: etureasybizsuccess To: aaa-archive@ietf.org Subject: work from home-paying job fkd Sender: etureasybizsuccess Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Date: Wed, 26 May 2004 19:02:17 +0200 X-Mailer: Microsoft Outlook IMO Build 9.0.2416 (9.0.2910.0) X-Priority: 1 Message-Id: X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: Yes, hits=21.0 required=5.0 tests=DOMAIN_4U2,FORGED_MUA_OIMO, FORGED_OUTLOOK_TAGS,FORGED_RCVD_NET_HELO,HTML_40_50, HTML_FONTCOLOR_UNKNOWN,HTML_FONT_BIG,HTML_FONT_INVISIBLE, HTML_IMAGE_ONLY_06,HTML_MESSAGE,HTML_TAG_BALANCE_BODY, HTML_TAG_BALANCE_HTML,LINES_OF_YELLING,MIME_HTML_ONLY, RCVD_NUMERIC_HELO,TRACKER_ID,WITH_LC_SMTP,WORK_AT_HOME, X_PRIORITY_HIGH autolearn=no version=2.60 X-Spam-Report: * 0.5 X_PRIORITY_HIGH Sent with 'X-Priority' set to high * 4.3 WITH_LC_SMTP Received line contains spam-sign (lowercase smtp) * 0.3 RCVD_NUMERIC_HELO Received: contains a numeric HELO * 0.6 DOMAIN_4U2 BODY: Domain name containing a "4u" variant * 1.3 WORK_AT_HOME BODY: Information on how to work at home (1) * 3.5 TRACKER_ID BODY: Incorporates a tracking ID number * 0.5 HTML_40_50 BODY: Message is 40% to 50% HTML * 0.1 HTML_FONTCOLOR_UNKNOWN BODY: HTML font color is unknown to us * 1.7 HTML_IMAGE_ONLY_06 BODY: HTML: images with 400-600 bytes of words * 0.3 HTML_TAG_BALANCE_BODY BODY: HTML has unbalanced "body" tags * 0.0 HTML_MESSAGE BODY: HTML included in message * 0.1 HTML_FONT_BIG BODY: HTML has a big font * 0.0 LINES_OF_YELLING BODY: A WHOLE LINE OF YELLING DETECTED * 0.4 HTML_TAG_BALANCE_HTML BODY: HTML has unbalanced "html" tags * 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts * 0.4 HTML_FONT_INVISIBLE BODY: HTML font color is same as background * 3.0 FORGED_RCVD_NET_HELO Host HELO'd using the wrong IP network * 1.1 FORGED_OUTLOOK_TAGS Outlook can't send HTML in this format * 2.7 FORGED_MUA_OIMO Forged mail pretending to be from MS Outlook IMO

Hi   aaa-archive tyipgsj

the way you see it:
GET AN INCOME - DESERVING YOUR SKILLS !!!


heto
click picture for details

 
NOTICE: This is a one time message.
You have received this e-mail because you expressed interest in career and employment information.
In case you suppose this mail has reached your mailbox by an error, we certainly apologize.
remove


611hnoacr let the PC replace you in job dkwwaxjstxbjhofrhejmfsttktebgptjkq From owner-aaa-wg@merit.edu Wed May 26 12:18:17 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 MAA26689 for ; Wed, 26 May 2004 12:18:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01F5C9121A; Wed, 26 May 2004 12:17:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDAB69121B; Wed, 26 May 2004 12:17: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 544A29121A for ; Wed, 26 May 2004 12:17:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A222596D3; Wed, 26 May 2004 12:17:56 -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 B980A5923B for ; Wed, 26 May 2004 12:17:55 -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 i4QGHTH24120; Wed, 26 May 2004 12:17:29 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 May 2004 12:17:29 -0400 Message-ID: <7E49849DDCBEAA489C65292E8B8AE7E8967D5E@zrc2hxm2.corp.nortel.com> From: "Christopher Richards" To: "Harri Hakala (JO/LMF)" , "'marco.stura@nokia.com'" , mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Date: Wed, 26 May 2004 12:17:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4433C.EE2B04F4" 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_01C4433C.EE2B04F4 Content-Type: text/plain I agree. Cheers, Chris. -----Original Message----- From: Harri Hakala (JO/LMF) [mailto:harri.hakala@ericsson.com] Sent: Wednesday, May 26, 2004 8:10 AM To: 'marco.stura@nokia.com'; mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Hi, We do not need the subscription-id in the CCA command, so it may be better to remove it, since it cause confusion. regards....Harri -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com Sent: 26. toukokuuta 2004 15:56 To: mgrayson@cisco.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp >so what is the rationale for having the subscription ID returned in the CCA? Good question! I cannot recall the reason why is in CCA, I tried to dig out in the aaa mail archive but I didn't find any hint. My opinion is that it shouldn't be there, there is actually no use for it. Marco -----Original Message----- From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: 26 May, 2004 15:33 To: Stura Marco (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp so what is the rationale for having the subscription ID returned in the CCA? Cheers, Mark -----Original Message----- From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] Sent: 26 May 2004 08:30 To: Mark Grayson (mgrayson) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp Hi Mark, >Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the >value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an >attacker to charge a third party's account? An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter. The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically using TLS or IPSec. Regards Marco ------_=_NextPart_001_01C4433C.EE2B04F4 Content-Type: text/html Message
I agree.

Cheers,
Chris.

-----Original Message-----
From: Harri Hakala (JO/LMF) [mailto:harri.hakala@ericsson.com]
Sent: Wednesday, May 26, 2004 8:10 AM
To: 'marco.stura@nokia.com'; mgrayson@cisco.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

Hi,
 
We do not need the subscription-id in the CCA command, so it may be better 
to remove it, since it cause confusion.
 
regards....Harri
-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of marco.stura@nokia.com
Sent: 26. toukokuuta 2004 15:56
To: mgrayson@cisco.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

>so what is the rationale for having the subscription ID returned in the CCA?
 
Good question!
 
I cannot recall the reason why is in CCA, I tried to dig out in the aaa mail archive
but I didn't find any hint. My opinion is that it shouldn't be there, there is actually
no use for it.
 
Marco
-----Original Message-----
From: ext Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]
Sent: 26 May, 2004 15:33
To: Stura Marco (Nokia-NET/Helsinki)
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

so what is the rationale for having the subscription ID returned in the CCA?
 
Cheers,
Mark
-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com]
Sent: 26 May 2004 08:30
To: Mark Grayson (mgrayson)
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Event Time Stamp

Hi Mark,
 
>Another question I have concerns the handling of subscription ID AVP in the CCA. What happens if this differs from the
>value in the CCR. Should the DCCA client use the returned ID in subseqent CCR messages? Could this be used by an
>attacker to charge a third party's account?
 
An authenticated identity must always be used in a Subscription-Id AVP in all the CCR messages, authentication is
not performed with the DCC application but e.g. with NASREQ or EAP. The Subscription-id(s) to be used may also be
returned by the AAA server in the successful AA-answer that authenticated the user, this is to be used in CCR messages sent thereafter.
The security section discusses recommendations how to prevent an attacker to modify CCR/CCA messages, basically
using TLS or IPSec.
 
Regards
Marco
------_=_NextPart_001_01C4433C.EE2B04F4-- From owner-aaa-wg@merit.edu Wed May 26 16:03: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 QAA11073 for ; Wed, 26 May 2004 16:03:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DA2F91221; Wed, 26 May 2004 16:03:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D4F3912A0; Wed, 26 May 2004 16:03: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 C84D591221 for ; Wed, 26 May 2004 16:03:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACEC0595AC; Wed, 26 May 2004 16:03:17 -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 EF4B058E5C for ; Wed, 26 May 2004 16:03:16 -0400 (EDT) Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 May 2004 22:09:23 +0200 X-BrightmailFiltered: true Received: from XBE-AMS-302.cisco.com (xbe-ams-302.cisco.com [144.254.75.92]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i4QK2Y1V026183; Wed, 26 May 2004 22:02:41 +0200 (MEST) Received: from xbe-ams-313.cisco.com ([144.254.228.203]) by XBE-AMS-302.cisco.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 26 May 2004 21:57:47 +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_01C4435C.2DAFB969" Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID Date: Wed, 26 May 2004 22:01:05 +0200 Message-ID: Thread-Topic: [AAA-WG]: DCCA Draft 05: Session ID Thread-Index: AcRDIsqffMKDk64CSwCwppWqtQ9FMQAB2NEwAAuAgJA= From: "Mark Grayson (mgrayson)" To: "Harri Hakala (JO/LMF)" , Cc: X-OriginalArrivalTime: 26 May 2004 19:57:47.0468 (UTC) FILETIME=[B79AD8C0:01C4435B] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4435C.2DAFB969 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ok - apologies if it is now too late to bring these issues....=20 =20 section 4.1 says that "The service SHOULD be identified using the Service-Identifier AVP."=20 =20 Is this always true, even for Multi-Service? =20 Section 5.2 says that " in the case of multiple services the Service-Identifier AVP or the Rating-Group AVP within the Multiples-Service-Credit-Control AVP, always indicates the concerned service."=20 =20 Can Rating-Group AVP be used to identify a service? =20 Note, this section defines "or" and other define "and/or". Which is correct? =20 =20 Then section 8.20 says "tariff change is not used for time based quota" and section 5.1 indicates that "For time-based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used." I presume the latter is correct and section 8.20 needs correcting. =20 Cheers, Mark =20 =20 =20 ------_=_NextPart_001_01C4435C.2DAFB969 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
ok -=20 apologies if it is now too late to bring these issues.... =
 
section 4.1 says that "The service SHOULD be identified using = the=20 Service-Identifier AVP."
 
Is=20 this always true, even for Multi-Service?
 
Section 5.2 says that " in the case of multiple services the=20 Service-Identifier AVP or the Rating-Group AVP within the=20 Multiples-Service-Credit-Control AVP, always indicates the concerned = service."=20
 
Can=20 Rating-Group AVP be used to identify a service?
 
Note, this section defines "or" and other define "and/or". = Which is=20 correct?
 
 
Then=20 section 8.20 says "tariff change is not used for time based quota" and = section=20 5.1 indicates that "For time-based services where the quota is NOT = continuously=20 consumed at a regular rate, the tariff change mechanism described for = volume and=20 event units MAY be used." I presume the latter is correct and section = 8.20 needs=20 correcting.
 
Cheers,
Mark
 
 
 
------_=_NextPart_001_01C4435C.2DAFB969-- From owner-aaa-wg@merit.edu Wed May 26 16:35: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 QAA13568 for ; Wed, 26 May 2004 16:35:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29434912A0; Wed, 26 May 2004 16:34:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2CA5912A4; Wed, 26 May 2004 16:34: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 094F4912A0 for ; Wed, 26 May 2004 16:34:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1A7859565; Wed, 26 May 2004 16:34:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 91D095936B for ; Wed, 26 May 2004 16:34:48 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 May 2004 16:34:27 -0400 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , jari.arkko@kolumbus.fi, aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Wed, 26 May 2004 16:34:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > We probably need one (or two things) more: > > (e) Guidelines on Diameter & RADIUS extensiblitity. I think > someone already mentioned that a guideline (or BCP) on how > to define Diameter applications would be a good thing. I agree (and it was me) Avi > John > From owner-aaa-wg@merit.edu Wed May 26 16:48: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 QAA14823 for ; Wed, 26 May 2004 16:48:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADA9191225; Wed, 26 May 2004 16:48:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 793AC912A1; Wed, 26 May 2004 16:48:12 -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 3A8D491225 for ; Wed, 26 May 2004 16:48:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 28EDC5950C; Wed, 26 May 2004 16:48:11 -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 92F3A594F9 for ; Wed, 26 May 2004 16:48:10 -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 i4QKlJ911407; Wed, 26 May 2004 16:47:19 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 26 May 2004 16:47:20 -0400 Message-ID: <7E49849DDCBEAA489C65292E8B8AE7E89EA663@zrc2hxm2.corp.nortel.com> From: "Christopher Richards" To: "Mark Grayson (mgrayson)" , "Harri Hakala (JO/LMF)" , marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID Date: Wed, 26 May 2004 16:47:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44362.9FD766C4" 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_01C44362.9FD766C4 Content-Type: text/plain Hi Mark, I've put in some comments below. Cheers, Chris. -----Original Message----- From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] Sent: Wednesday, May 26, 2004 3:01 PM To: Harri Hakala (JO/LMF); marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID ok - apologies if it is now too late to bring these issues.... section 4.1 says that "The service SHOULD be identified using the Service-Identifier AVP." Is this always true, even for Multi-Service? [Chris Richards ] No. Section 5.2 says that " in the case of multiple services the Service-Identifier AVP or the Rating-Group AVP within the Multiples-Service-Credit-Control AVP, always indicates the concerned service." Can Rating-Group AVP be used to identify a service? [Chris Richards ] Yes. And I would argue that it is the simpler and preferred method to identify a service. Note, this section defines "or" and other define "and/or". Which is correct? [Chris Richards ] The "or". I'm not sure how the "and/or" could work. Then section 8.20 says "tariff change is not used for time based quota" and section 5.1 indicates that "For time-based services where the quota is NOT continuously consumed at a regular rate, the tariff change mechanism described for volume and event units MAY be used." I presume the latter is correct and section 8.20 needs correcting. [Chris Richards ] Yes. The latter is correct. Time quotas are not necessarily decemented at a constant rate (of 1 second per second) - therefore the tariff change mechanism is useful for these scenarios. Cheers, Mark ------_=_NextPart_001_01C44362.9FD766C4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCCA Draft 05: Session ID

Hi Mark,

I've put in some comments below.

Cheers,
Chris.

-----Original Message-----
From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com] =
Sent: Wednesday, May 26, 2004 3:01 PM
To: Harri Hakala (JO/LMF); = marco.stura@nokia.com
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Session = ID


ok - apologies if it is now too late to bring these = issues....

section 4.1 says that "The service SHOULD be = identified using the Service-Identifier AVP."

Is this always true, even for Multi-Service?

[Chris Richards ] No.

Section 5.2 says that " in the case of multiple = services the Service-Identifier AVP or the Rating-Group AVP within the = Multiples-Service-Credit-Control AVP, always indicates the concerned = service."

Can Rating-Group AVP be used to identify a = service?

[Chris Richards ] Yes. And I would argue that it is = the simpler and preferred method to identify a service.

Note, this section defines "or" and other = define "and/or". Which is correct?

[Chris Richards ] The "or". I'm not sure = how the "and/or" could work.

Then section 8.20 says "tariff change is not = used for time based quota" and section 5.1 indicates that = "For time-based services where the quota is NOT continuously = consumed at a regular rate, the tariff change mechanism described for = volume and event units MAY be used." I presume the latter is = correct and section 8.20 needs correcting.

[Chris Richards ] Yes. The latter is correct. Time = quotas are not necessarily decemented at a constant rate (of 1 second = per second) - therefore the tariff change mechanism is useful for these = scenarios.

Cheers,
Mark

------_=_NextPart_001_01C44362.9FD766C4-- From owner-aaa-wg@merit.edu Wed May 26 18:31: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 SAA25219 for ; Wed, 26 May 2004 18:31:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8B2691246; Wed, 26 May 2004 18:31:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A3AE912A4; Wed, 26 May 2004 18:31: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 3037B91246 for ; Wed, 26 May 2004 18:31:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D9845935C; Wed, 26 May 2004 18:31:25 -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 700D759351 for ; Wed, 26 May 2004 18:31:24 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4QMWsJ02859; Wed, 26 May 2004 15:32:54 -0700 Date: Wed, 26 May 2004 15:32:54 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: Pasi.Eronen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... In-Reply-To: <40B24D8A.6070009@kolumbus.fi> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A6122415@esebe023.ntc.nokia.com> <40B23CC8.8090100@kolumbus.fi> <40B24D8A.6070009@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I like this. We should probably bring the RFC 3579 Errata issue to EAP WG. I've filed it as Issue 242 on the EAP issues list. On Mon, 24 May 2004, Jari Arkko wrote: > Bernard Aboba wrote: > >>Ok. But I wonder if it would be useful to write down also > >>the thinking behind this, i.e., the use of the State attribute > >>in RADIUS to do the restart. "This is necessary because ...". > > > > > > Yes. An errata to RFC 3579 might also make sense. > > Ok. Here's some proposed text. For D-EAP: > > "This is necessary in order to distinguish a restarted > EAP authentication process from the continuation of an ongoing > process (by the same user on the same NAS and port). > > In RADIUS [RFC 3579 Errata], the same functionality is > achieved through the inclusion or omission of the State > attribute. Translation rules in [NASREQ] ensure that > an Access-Request without the State attribute maps to a > a new Diameter Session-Id AVP value. Furthemore, a > translation agent will always include a State attribute > in Access-Challenge messages, making sure that the State > attribute is available for a RADIUS NAS." > > For R-EAP RFC 3579 Errata: > > "The use of the State attribute is necessary in order to > distinguish a restarted EAP authentication process from > the continuation of an ongoing process (by the same user > on the same NAS and port). > > The following rules specify how this attribute is used > with RADIUS EAP: > > o RADIUS servers SHOULD always include the State > attribute in an Access-Challenge, Access-Accept, > or Access-Reject message. > > o Normally, a NAS copies the received State attribute > to an Access-Request sent as a response to an > Access-Challenge [RFC 2865 Section 5.24]. Note that > an Access-Request sent as a result of a new or > restarted authentication run MUST NOT include the > State attribute, even if the State attribute has > previously been received in an Access-Challenge > for the same user and port." > > --Jari > From owner-aaa-wg@merit.edu Thu May 27 05:00: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 FAA08891 for ; Thu, 27 May 2004 05:00:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8076D912AC; Thu, 27 May 2004 05:00:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DD3F912AD; Thu, 27 May 2004 05:00:00 -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 91DC8912AC for ; Thu, 27 May 2004 04:59:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A48559586; Thu, 27 May 2004 04:59:58 -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 2102159579 for ; Thu, 27 May 2004 04:59:43 -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 i4R8wWE10677; Thu, 27 May 2004 11:58:32 +0300 (EET DST) X-Scanned: Thu, 27 May 2004 11:57:48 +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 i4R8vm9f022059; Thu, 27 May 2004 11:57:48 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00XIzq6R; Thu, 27 May 2004 11:57:46 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4R8vkH26794; Thu, 27 May 2004 11:57:46 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 27 May 2004 11:57: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_01C443C8.ADA8F960" Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID Date: Thu, 27 May 2004 11:57:45 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87BC@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: DCCA Draft 05: Session ID Thread-Index: AcRDYt707hRNQtSPTpWOeTUeEBwUDAAVDZ2A From: To: , , Cc: X-OriginalArrivalTime: 27 May 2004 08:57:47.0015 (UTC) FILETIME=[AE4F0170:01C443C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C443C8.ADA8F960 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 more comments in line. =20 Marco -----Original Message----- From: ext Christopher Richards [mailto:crich@nortelnetworks.com] Sent: 26 May, 2004 23:47 To: Mark Grayson (mgrayson); Harri Hakala (JO/LMF); Stura Marco = (Nokia-NET/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID Hi Mark,=20 I've put in some comments below.=20 Cheers,=20 Chris.=20 -----Original Message-----=20 From: Mark Grayson (mgrayson) [ mailto:mgrayson@cisco.com]=20 Sent: Wednesday, May 26, 2004 3:01 PM=20 To: Harri Hakala (JO/LMF); marco.stura@nokia.com=20 Cc: aaa-wg@merit.edu=20 Subject: RE: [AAA-WG]: DCCA Draft 05: Session ID=20 ok - apologies if it is now too late to bring these issues....=20 section 4.1 says that "The service SHOULD be identified using the = Service-Identifier AVP."=20 Is this always true, even for Multi-Service?=20 [Chris Richards ] No. =20 [MSt] Chris is right.=20 The DCC is basically a framework for credit control, Section 4.1 = describes how to define service-specific rating inputs AVPs and ensure = interoperability for those services. This sentence refers to the = Service-Id at command level, that identifies the set of mandatory AVPs = defined in a service specific document that may be present in the CCR = command and need to be supported. The principle is that the server = checks first the Service-Identifier AVP at command level to determine if = the request can be satisfied. For instance, a service "network access flow based cc" is defined in a = service specific document. This document need to define the content of = the Service-Identifier AVP (e.g. FBCC_v100@SDO.example.org) and all the = mandatory rating input AVPs that must be supported by DCC = implementations that support "network access flow based cc".=20 Section 5.2 says that " in the case of multiple services the = Service-Identifier AVP or the Rating-Group AVP within the = Multiples-Service-Credit-Control AVP, always indicates the concerned = service."=20 Can Rating-Group AVP be used to identify a service?=20 [Chris Richards ] Yes. And I would argue that it is the simpler and = preferred method to identify a service.=20 [MSt] The definition and relationship of Rating-Groups and Service-id = in the context of the MSCC, can be found in section 5.1.1. From there it = should be clear that Rating-Groups identifies an aggregate of services = subject to the same cost and rating type (e.g. $0.5/MB), not a single = service. If the server grants quota to a Rating-Group, all the services = belonging to that RG can consume the quota. Note, this section defines "or" and other define "and/or". Which is = correct?=20 [Chris Richards ] The "or". I'm not sure how the "and/or" could work. =20 [MSt] and/or simply means that both RG and SI could be present at MSCC = AVP level. If both AVPs are present in CCA within a MSCC AVP, only the = service identified by SI can consume the granted quota. If both AVPs are = present in CCR, the SI details the amount of consumed quota per each = service. This is defined in section 8.16: The Service-Identifier and the Rating-Group AVPs are used to=20 associate the granted units to a given service or rating group. =20 In case both the Service-Identifier and the Rating-Group AVPs are=20 included, the target of the service units is always the service(s)=20 indicated by the value of the Service-Identifier AVP(s). If only the=20 Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control=20 AVP relates to all the services that belong to the specified rating=20 group. For instance, the service specific document that define "network access = flow based cc" should also states whether RG only or both RG and SI = levels is required. If you are happy with the RG level, then the = parameters that identify the services (e.g. IP 5-tuple) could be = provided to the service element associated to the same RG but with no = use of SI. Then section 8.20 says "tariff change is not used for time based quota" = and section 5.1 indicates that "For time-based services where the quota = is NOT continuously consumed at a regular rate, the tariff change = mechanism described for volume and event units MAY be used." I presume = the latter is correct and section 8.20 needs correcting. [Chris Richards ] Yes. The latter is correct. Time quotas are not = necessarily decemented at a constant rate (of 1 second per second) - = therefore the tariff change mechanism is useful for these scenarios. =20 [MSt] I think section 8.20 says=20 The tariff change mechanism is optional for client and server and it=20 is not used for time-based services as defined in the section 5. Where section 5 defines what Chris pointed out. Cheers,=20 Mark=20 ------_=_NextPart_001_01C443C8.ADA8F960 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: DCCA Draft 05: Session ID
Hi,
 
more=20 comments in line.
 
Marco
-----Original Message-----
From: ext Christopher = Richards=20 [mailto:crich@nortelnetworks.com]
Sent: 26 May, 2004=20 23:47
To: Mark Grayson (mgrayson); Harri Hakala (JO/LMF); = Stura=20 Marco (Nokia-NET/Helsinki)
Cc: = aaa-wg@merit.edu
Subject:=20 RE: [AAA-WG]: DCCA Draft 05: Session ID

Hi Mark,

I've put in some comments below.

Cheers,
Chris.

-----Original Message-----
From: Mark=20 Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20
Sent: Wednesday, May 26, 2004 3:01 PM =
To: Harri Hakala (JO/LMF); marco.stura@nokia.com =
Cc: aaa-wg@merit.edu
Subject: RE: = [AAA-WG]:=20 DCCA Draft 05: Session ID


ok - apologies if it is now too late to bring these = issues....=20

section 4.1 says that "The service SHOULD be = identified using=20 the Service-Identifier AVP."

Is this always true, even for Multi-Service? =

[Chris Richards ] No.  

[MSt] Chris is right. 

The=20 DCC is basically a framework for credit control, Section 4.1 describes = how=20 to define service-specific rating inputs AVPs and ensure = interoperability=20 for those services. This sentence refers to the Service-Id at command = level,=20 that identifies the set of mandatory AVPs defined in a service = specific=20 document that may be present in the CCR command and need to be = supported. The=20 principle is that the server checks first the Service-Identifier AVP = at=20 command level to determine if the request can be = satisfied.

For=20 instance, a service "network access flow based cc" is defined in a = service=20 specific document. This document need to define the content of the=20 Service-Identifier AVP (e.g. FBCC_v100@SDO.example.org) = and all=20 the mandatory rating input AVPs that must be supported by DCC = implementations=20 that support "network access flow based cc".

Section 5.2 says that " in the case of multiple services the=20 Service-Identifier AVP or the Rating-Group AVP within the=20 Multiples-Service-Credit-Control AVP, always indicates the concerned = service."=20

Can Rating-Group AVP be used to identify a = service?=20

[Chris Richards ] Yes. And I would argue that it is = the=20 simpler and preferred method to identify a service. 

[MSt]  The definition and relationship of=20 Rating-Groups and Service-id in the context of the MSCC, can be = found in=20 section 5.1.1. From there it should be clear that Rating-Groups = identifies an=20 aggregate of services subject to the same cost and rating type (e.g. = $0.5/MB),=20 not a single service. If the server grants quota to a Rating-Group, = all the=20 services belonging to that RG can consume the = quota.

Note, this section defines "or" and other define = "and/or".=20 Which is correct?

[Chris Richards ] The "or". I'm not sure how the = "and/or"=20 could work.  

[MSt]=20 and/or simply means that both RG and SI could be present at MSCC AVP = level. If=20 both AVPs are present in CCA within a MSCC AVP, only the = service=20 identified by SI can consume the granted quota. If both AVPs are = present=20 in CCR, the SI details the amount of consumed quota = per each=20 service. This is defined in section 8.16:

  The Service-Identifier and = the=20 Rating-Group AVPs are used to
   associate the granted = units to=20 a given service or rating group. 
  In case both the=20 Service-Identifier and the Rating-Group AVPs are
  included, = the=20 target of the service units is always the service(s)
  = indicated by=20 the value of the Service-Identifier AVP(s). If only the
 =20 Rating-Group-Id AVP is present, the Multiple-Services-Credit-Control=20
  AVP relates to all the services that belong to the = specified rating=20
  group.

For=20 instance, the service specific document that define "network access = flow based=20 cc" should also states whether RG only or both RG and SI levels = is=20 required. If you are happy with the RG level, then the = parameters=20 that identify the services (e.g. IP 5-tuple) could be provided to the = service=20 element associated to the same RG but with no use of = SI.

Then section = 8.20 says=20 "tariff change is not used for time based quota" and section 5.1 = indicates=20 that "For time-based services where the quota is NOT continuously = consumed at=20 a regular rate, the tariff change mechanism described for volume and = event=20 units MAY be used." I presume the latter is correct and section 8.20 = needs=20 correcting.

[Chris Richards ] Yes. The latter is correct. Time = quotas are=20 not necessarily decemented at a constant rate (of 1 second per second) = -=20 therefore the tariff change mechanism is useful for these=20 scenarios.  

[MSt] I think section 8.20=20 says 

  The tariff change mechanism = is=20 optional for client and server and it
   is not used for = time-based services as defined in the section 5.

Where section 5 defines what Chris pointed=20 out.

Cheers,
Mark=20

------_=_NextPart_001_01C443C8.ADA8F960-- From owner-aaa-wg@merit.edu Thu May 27 07:08: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 HAA15350 for ; Thu, 27 May 2004 07:08:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8AA1912B5; Thu, 27 May 2004 07:08:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 89C97912B4; Thu, 27 May 2004 07:08: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 5FA0F912B2 for ; Thu, 27 May 2004 07:08:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 406FA595D4; Thu, 27 May 2004 07:08:29 -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 B320E59549 for ; Thu, 27 May 2004 07:08:23 -0400 (EDT) Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i4RB8AE01777; Thu, 27 May 2004 14:08:10 +0300 (EET DST) X-Scanned: Thu, 27 May 2004 14:07:38 +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 i4RB7cm9019442; Thu, 27 May 2004 14:07:38 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00LSFdoU; Thu, 27 May 2004 14:07:02 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 i4RB71H28561; Thu, 27 May 2004 14:07:01 +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, 27 May 2004 14:06: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: RE: [AAA-WG]: Wrapping up Diameter EAP... Date: Thu, 27 May 2004 14:06:56 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A612241E@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Wrapping up Diameter EAP... Thread-Index: AcRBxlUy8A1GxbJaQa+vDIV/zK3JuACEzM/A From: To: , Cc: X-OriginalArrivalTime: 27 May 2004 11:06:56.0871 (UTC) FILETIME=[B9952F70:01C443DA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Ok, I have now put together version -06.b which adds the=20 following section:=20 2.8.5 Identifier space In EAP, each session has its own unique Identifier space. Diameter server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct EAP sessions, originating on the same NAS. This is done by using the Session-Id AVP. If a Diameter NAS is in the middle of a multi-round authentication exchange, and it detects that the EAP session between the client and the NAS has been terminated for some reason, it MUST select a new Diameter Session-Id for any subsequent EAP sessions. This is necessary in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). In RADIUS, the same functionality can be achieved through the inclusion or omission of the State attribute. Translation rules in [NASREQ] ensure that an Access-Request without the State attribute maps to a a new Diameter Session-Id AVP value. Furthemore, a translation agent will always include a State attribute in Access-Challenge messages, making sure that the State attribute is available for a RADIUS NAS. Is this sufficient? BR, Pasi > -----Original Message----- > From: owner-aaa-wg@merit.edu=20 > [mailto:owner-aaa-wg@merit.edu]On Behalf Of > ext Jari Arkko > Sent: Monday, May 24, 2004 10:31 PM > To: Bernard Aboba > Cc: Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... >=20 >=20 > Bernard Aboba wrote: > >>Ok. But I wonder if it would be useful to write down also > >>the thinking behind this, i.e., the use of the State attribute > >>in RADIUS to do the restart. "This is necessary because ...". > >=20 > >=20 > > Yes. An errata to RFC 3579 might also make sense. >=20 > Ok. Here's some proposed text. For D-EAP: >=20 > "This is necessary in order to distinguish a restarted > EAP authentication process from the continuation of an ongoing > process (by the same user on the same NAS and port). >=20 > In RADIUS [RFC 3579 Errata], the same functionality is > achieved through the inclusion or omission of the State > attribute. Translation rules in [NASREQ] ensure that > an Access-Request without the State attribute maps to a > a new Diameter Session-Id AVP value. Furthemore, a > translation agent will always include a State attribute > in Access-Challenge messages, making sure that the State > attribute is available for a RADIUS NAS." >=20 > For R-EAP RFC 3579 Errata: >=20 > "The use of the State attribute is necessary in order to > distinguish a restarted EAP authentication process from > the continuation of an ongoing process (by the same user > on the same NAS and port). >=20 > The following rules specify how this attribute is used > with RADIUS EAP: >=20 > o RADIUS servers SHOULD always include the State > attribute in an Access-Challenge, Access-Accept, > or Access-Reject message. >=20 > o Normally, a NAS copies the received State attribute > to an Access-Request sent as a response to an > Access-Challenge [RFC 2865 Section 5.24]. Note that > an Access-Request sent as a result of a new or > restarted authentication run MUST NOT include the > State attribute, even if the State attribute has > previously been received in an Access-Challenge > for the same user and port." >=20 > --Jari >=20 From owner-aaa-wg@merit.edu Thu May 27 07:19: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 HAA15630 for ; Thu, 27 May 2004 07:19:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C2C32912B2; Thu, 27 May 2004 07:19:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E170912B4; Thu, 27 May 2004 07:19: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 43760912B2 for ; Thu, 27 May 2004 07:19:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2885B595C1; Thu, 27 May 2004 07:19:47 -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 35CBA59437 for ; Thu, 27 May 2004 07:19:46 -0400 (EDT) Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id EA09F898B8; Thu, 27 May 2004 14:19:28 +0300 (EEST) Message-ID: <40B5CDDD.9010807@kolumbus.fi> Date: Thu, 27 May 2004 14:15:41 +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]: Wrapping up Diameter EAP... References: <052E0C61B69C3741AFA5FE88ACC775A612241E@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A612241E@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 Ok. Nit: s/furthemore/furthermore/ (this was originally a mistake in my text). Pasi.Eronen@nokia.com wrote: > Ok, I have now put together version -06.b which adds the > following section: > > 2.8.5 Identifier space > > In EAP, each session has its own unique Identifier space. Diameter > server implementations MUST be able to distinguish between EAP > packets with the same Identifier existing within distinct EAP > sessions, originating on the same NAS. This is done by using the > Session-Id AVP. > > If a Diameter NAS is in the middle of a multi-round authentication > exchange, and it detects that the EAP session between the client and > the NAS has been terminated for some reason, it MUST select a new > Diameter Session-Id for any subsequent EAP sessions. This is > necessary in order to distinguish a restarted EAP authentication > process from the continuation of an ongoing process (by the same user > on the same NAS and port). > > In RADIUS, the same functionality can be achieved through the > inclusion or omission of the State attribute. Translation rules in > [NASREQ] ensure that an Access-Request without the State attribute > maps to a a new Diameter Session-Id AVP value. Furthemore, a > translation agent will always include a State attribute in > Access-Challenge messages, making sure that the State attribute is > available for a RADIUS NAS. > > Is this sufficient? > > BR, > Pasi > > >>-----Original Message----- >>From: owner-aaa-wg@merit.edu >>[mailto:owner-aaa-wg@merit.edu]On Behalf Of >>ext Jari Arkko >>Sent: Monday, May 24, 2004 10:31 PM >>To: Bernard Aboba >>Cc: Eronen Pasi (Nokia-NRC/Helsinki); aaa-wg@merit.edu >>Subject: Re: [AAA-WG]: Wrapping up Diameter EAP... >> >> >>Bernard Aboba wrote: >> >>>>Ok. But I wonder if it would be useful to write down also >>>>the thinking behind this, i.e., the use of the State attribute >>>>in RADIUS to do the restart. "This is necessary because ...". >>> >>> >>>Yes. An errata to RFC 3579 might also make sense. >> >>Ok. Here's some proposed text. For D-EAP: >> >> "This is necessary in order to distinguish a restarted >> EAP authentication process from the continuation of an ongoing >> process (by the same user on the same NAS and port). >> >> In RADIUS [RFC 3579 Errata], the same functionality is >> achieved through the inclusion or omission of the State >> attribute. Translation rules in [NASREQ] ensure that >> an Access-Request without the State attribute maps to a >> a new Diameter Session-Id AVP value. Furthemore, a >> translation agent will always include a State attribute >> in Access-Challenge messages, making sure that the State >> attribute is available for a RADIUS NAS." >> >>For R-EAP RFC 3579 Errata: >> >> "The use of the State attribute is necessary in order to >> distinguish a restarted EAP authentication process from >> the continuation of an ongoing process (by the same user >> on the same NAS and port). >> >> The following rules specify how this attribute is used >> with RADIUS EAP: >> >> o RADIUS servers SHOULD always include the State >> attribute in an Access-Challenge, Access-Accept, >> or Access-Reject message. >> >> o Normally, a NAS copies the received State attribute >> to an Access-Request sent as a response to an >> Access-Challenge [RFC 2865 Section 5.24]. Note that >> an Access-Request sent as a result of a new or >> restarted authentication run MUST NOT include the >> State attribute, even if the State attribute has >> previously been received in an Access-Challenge >> for the same user and port." >> >>--Jari > > > From owner-aaa-wg@merit.edu Thu May 27 12:02: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 MAA04810 for ; Thu, 27 May 2004 12:02:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 157E39122A; Thu, 27 May 2004 12:02:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D74A9912B8; Thu, 27 May 2004 12:02: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 BF1BE9122A for ; Thu, 27 May 2004 12:02:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A375F59554; Thu, 27 May 2004 12:02:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 619D059552 for ; Thu, 27 May 2004 12:02:37 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id MAA13746 for ; Thu, 27 May 2004 12:05:36 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma013731; Thu, 27 May 04 12:05:12 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 27 May 2004 12:02:11 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 27 May 2004 12:02:11 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 May 2004 12:02:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 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]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 12:02:10 -0400 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRCZkovFQYPsVgVSLKyEDVE3M55wgBmhLIw From: "Nelson, David" To: X-OriginalArrivalTime: 27 May 2004 16:02:11.0078 (UTC) FILETIME=[F812AA60:01C44403] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:87.1726 M:98.0684 P:95.9108 R:95.9108 S:33.8662 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi Lior writes... =A0 > Where does it say that VSAs were not intended to be used > by other SDOs to extend the protocol? This is a discussion that we have been holding on the RADEXT mailing = list. Unfortunately, it doesn't explicitly say this anywhere that I'm = aware of. I say unfortunately, since it has caused some problems. If = anyone is interested, peruse the archives of the RADEXT list. IMHO, it = is implicit in the term "Vendor Specific", meaning specific to a = particular implementation of a particular vendor. The context for this = interpretation exists in the history of the RADIUS WG. It was always = intended that attributes for general usage (i.e. multi-vendor = interoperability) would be in the standard attribute ID space. I don't = believe there was ever consensus in the RADIUS WG that VSAs would be a = "standard" method to extend the protocol. > Some folks=A0even talked about using Type 26 with Vendor Id of=A0 > 0 to allow the IETF to extend RADIUS attributes just in case=20 > we=A0ran out of RADIUS attributes. That has been suggested. I don't know if there is any substantial = support at this point. =A0 > IMO it make a lot of sense to allow SDOs to extend RADIUS or=20 > even Diameter in cases where they don't care about interoperability > and thus don't=A0need to cut RFCs for their work. IMHO, the phrases "SDO" and "don't care about interoperability" are = oxymoronic. I would have expected that interoperability would have been = one of the primary objectives of any standard, no? :-) -- Dave From owner-aaa-wg@merit.edu Thu May 27 13:33: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 NAA10700 for ; Thu, 27 May 2004 13:33:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 99012912B8; Thu, 27 May 2004 13:33:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66559912BA; Thu, 27 May 2004 13:33: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 62BC8912B8 for ; Thu, 27 May 2004 13:33:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5038A595DF; Thu, 27 May 2004 13:33:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id ECE25594C6 for ; Thu, 27 May 2004 13:33:32 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 13:33:32 -0400 Message-ID: From: Avi Lior To: "'Nelson, David'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 13:33:31 -0400 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 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com]=20 > Sent: Thursday, May 27, 2004 12:02 PM > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs >=20 >=20 > David Nelson wrote: >I don't believe there was ever consensus=20 > in the RADIUS WG that VSAs would be a "standard" method to=20 > extend the protocol. Can you show me where this was even discussed in the RADIUS WG?=20 If you can't then you would be misleading the crowd. =A0 > > IMO it make a lot of sense to allow SDOs to extend RADIUS or > > even Diameter in cases where they don't care about interoperability > > and thus don't=A0need to cut RFCs for their work. >=20 > IMHO, the phrases "SDO" and "don't care about=20 > interoperability" are oxymoronic. I would have expected that=20 > interoperability would have been one of the primary=20 > objectives of any standard, no? :-) Obviously SDO care about standards. But perhaps there are several scopes for interoperability. One scope = is global scope, another is within a domain such as a domain controlled by = an SDO. Avi > -- Dave >=20 >=20 From owner-aaa-wg@merit.edu Thu May 27 15:43: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 PAA19640 for ; Thu, 27 May 2004 15:43:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 152C9912C0; Thu, 27 May 2004 15:42:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2683912C1; Thu, 27 May 2004 15:42:53 -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 B8B9E912C0 for ; Thu, 27 May 2004 15:42:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A4A205969C; Thu, 27 May 2004 15:42:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 3BAA259229 for ; Thu, 27 May 2004 15:42:52 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA26547 for ; Thu, 27 May 2004 15:45:52 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma026536; Thu, 27 May 04 15:45:30 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 27 May 2004 15:42:28 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 27 May 2004 15:42:28 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 May 2004 15:42:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 15:42:32 -0400 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcREEMJQ3YbSCvQLTN2BDDlpOpGwpgAEExLA From: "Nelson, David" To: X-OriginalArrivalTime: 27 May 2004 19:42:28.0243 (UTC) FILETIME=[BE1DFE30:01C44422] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:30.6231 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi Lior writes... > >I don't believe there was ever consensus > > in the RADIUS WG that VSAs would be a "standard" method to > > extend the protocol. >=20 > Can you show me where this was even discussed in the RADIUS WG? Well, I haven't undertaken a search of the RADIUS WG archives, but my statements are not based on the "written history". My statements are based on my personal experience. I was active in the RADIUS WG from the initial BOFs. I have already stipulated that these items of context never made their way into the RFCs. On the other hand, I think that the term "Vendor-Specific" is sufficiently self-describing. You have alluded to SDOs as "Super-Vendors", and I think that stretches the notion of "vendor" to the point of being meaningless. > If you can't then you would be misleading the crowd. That's a rather unfounded assertion. I am providing historic context, from first hand personal observation. I have not represented it as documented fact. However, first hand personal observation is permissible under the rules of evidence in a court of law. I therefore take exception to the assertion that my intent is to mislead. You are certainly free to question the accuracy of my memory, if you so choose. -- Dave From owner-aaa-wg@merit.edu Thu May 27 16:26: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 QAA22459 for ; Thu, 27 May 2004 16:26:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1B367912C1; Thu, 27 May 2004 16:26:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA723912C2; Thu, 27 May 2004 16:26: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 CEF4B912C1 for ; Thu, 27 May 2004 16:26:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AFD68596B6; Thu, 27 May 2004 16:26:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 6D330596B5 for ; Thu, 27 May 2004 16:26:38 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 16:26:38 -0400 Message-ID: From: Avi Lior To: "'Nelson, David'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 16:26:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I think when someone makes a statement such as: "... there was ever consensus in the RADIUS WG" that statement should not be based on someone's "personal experience". To me the above statement implies that there was official discussion in an open forum (mail list, in the meetings). But maybe my interpretation is wrong. > On the other hand, I think that the > term "Vendor-Specific" is sufficiently self-describing. You > have alluded to SDOs as "Super-Vendors", and I think that > stretches the notion of "vendor" to the point of being meaningless. Vendor could be an organization right? Avi > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Thursday, May 27, 2004 3:43 PM > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > Avi Lior writes... > > > >I don't believe there was ever consensus > > > in the RADIUS WG that VSAs would be a "standard" method > to extend > > >the protocol. > > > > Can you show me where this was even discussed in the RADIUS WG? > > Well, I haven't undertaken a search of the RADIUS WG > archives, but my statements are not based on the "written > history". My statements are based on my personal experience. > I was active in the RADIUS WG from the initial BOFs. I have > already stipulated that these items of context never made > their way into the RFCs. On the other hand, I think that the > term "Vendor-Specific" is sufficiently self-describing. You > have alluded to SDOs as "Super-Vendors", and I think that > stretches the notion of "vendor" to the point of being meaningless. > > > If you can't then you would be misleading the crowd. > > That's a rather unfounded assertion. I am providing historic > context, from first hand personal observation. I have not > represented it as documented fact. However, first hand > personal observation is permissible under the rules of > evidence in a court of law. I therefore take exception to > the assertion that my intent is to mislead. You are > certainly free to question the accuracy of my memory, if you > so choose. > > -- Dave > > From owner-aaa-wg@merit.edu Thu May 27 17:07: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 RAA25045 for ; Thu, 27 May 2004 17:07:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B28F1912C4; Thu, 27 May 2004 17:06:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81BE5912C5; Thu, 27 May 2004 17:06: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 5DE4D912C4 for ; Thu, 27 May 2004 17:06:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4869F59241; Thu, 27 May 2004 17:06:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id CD066592AD for ; Thu, 27 May 2004 17:06:50 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA02776 for ; Thu, 27 May 2004 17:09:50 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma002769; Thu, 27 May 04 17:09:04 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 27 May 2004 17:06:03 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 27 May 2004 17:06:03 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 May 2004 17:06:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 17:06:14 -0400 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcREKPUPTYS+AKt3R1mnY6tPEUcNGgAAyAPg From: "Nelson, David" To: X-OriginalArrivalTime: 27 May 2004 21:06:03.0242 (UTC) FILETIME=[6B4A1CA0:01C4442E] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:92.2363 M:98.0659 P:95.9108 R:95.9108 S:18.2673 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Avi Lior writes... =20 > To me the above statement implies that there was official discussion in an > open forum (mail list, in the meetings). I'm giving you my recollection of discussion that took place during meetings and/or on the mailing list. Please don't attempt to pin me down to names and dates. :-( > Vendor could be an organization right? I would not have thought so. There exceptional cases, of course, with "Open Source" consortia being the most obvious, but I can't think of any organization (read SDO or consortium) from which I can purchase product (my definition of "vendor"). At this point, I'll offer two observations. 1.) This thread is duplicating discussions we've held (and will continue to hold) on the RADEXT mailing list. 2.) There are unresolved interoperability issues here, and all the debate just underscores the need for some more specific "rules" or guidance in this area. Legalistic wrangling about why a given design approach "isn't prohibited" is not nearly as productive as pointing out why that design approach has technical merit that other approaches do not have. -- Dave From owner-aaa-wg@merit.edu Thu May 27 18:42: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 SAA02030 for ; Thu, 27 May 2004 18:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD62C912CB; Thu, 27 May 2004 18:41:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 988A3912CD; Thu, 27 May 2004 18:41: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 A14FA912CB for ; Thu, 27 May 2004 18:41:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8417A59521; Thu, 27 May 2004 18:41: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 F3FBC5939C for ; Thu, 27 May 2004 18:41:56 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4RMiJ722121; Thu, 27 May 2004 15:44:19 -0700 Date: Thu, 27 May 2004 15:44:19 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 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 > > >I don't believe there was ever consensus > > > in the RADIUS WG that VSAs would be a "standard" method to > > > extend the protocol. > > > > Can you show me where this was even discussed in the RADIUS WG? RFC 2865 Section 6.2 states: " Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful." An SDO is not a vendor, and typically requires interoperability between vendors, so that this language does not apply to use by SDOs. That said, it seems fairly clear to me that the IETF needs to provide a means by which SDOs can create their own SDO-specific attributes in a way that will be compatible with future standardization, if necessary. From owner-aaa-wg@merit.edu Thu May 27 19:32:46 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 TAA04867 for ; Thu, 27 May 2004 19:32:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3280B912CD; Thu, 27 May 2004 19:32:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 05BE8912CE; Thu, 27 May 2004 19:32: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 E42AE912CD for ; Thu, 27 May 2004 19:32:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D10EC59473; Thu, 27 May 2004 19:32:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 90DC859407 for ; Thu, 27 May 2004 19:32:26 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Thu, 27 May 2004 19:32:26 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , "Nelson, David" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 19:32:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > That said, it seems fairly clear to me that the IETF needs to > provide a means by which SDOs can create their own > SDO-specific attributes in a way that will be compatible with > future standardization, if necessary. I agree SDOs will standerdize what they need without going to a "Global" review unless they deem that they need interoperability outside their domain. VSAs fit that definition today - minus the discussion of what exactly a vendor is. Perhaps you can explain how creating a new class of attributes would actually change anything other than satisfy those that insist that an SDO is not a Vendor. That is really my point. Finally, regardless of how some define what a Vendor is - the fact is that SDOs already have Vendor Ids. So that defintion has already be accepted by IANA. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, May 27, 2004 6:44 PM > To: Nelson, David > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > > >I don't believe there was ever consensus > > > > in the RADIUS WG that VSAs would be a "standard" method > to extend > > > >the protocol. > > > > > > Can you show me where this was even discussed in the RADIUS WG? > > RFC 2865 Section 6.2 states: > > " Note that RADIUS defines a mechanism for Vendor-Specific > extensions > (Attribute 26) and the use of that should be encouraged instead of > allocation of global attribute types, for functions > specific only to > one vendor's implementation of RADIUS, where no interoperability is > deemed useful." > > An SDO is not a vendor, and typically requires > interoperability between vendors, so that this language does > not apply to use by SDOs. > > That said, it seems fairly clear to me that the IETF needs to > provide a means by which SDOs can create their own > SDO-specific attributes in a way that will be compatible with > future standardization, if necessary. > From owner-aaa-wg@merit.edu Thu May 27 20:08: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 UAA06577 for ; Thu, 27 May 2004 20:08:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9979D912CE; Thu, 27 May 2004 20:08:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64A03912CF; Thu, 27 May 2004 20:08:08 -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 120C4912CE for ; Thu, 27 May 2004 20:08:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EECED594C7; Thu, 27 May 2004 20:08:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from orsfmr001.jf.intel.com (fmr12.intel.com [134.134.136.15]) by segue.merit.edu (Postfix) with ESMTP id 8CE4259241 for ; Thu, 27 May 2004 20:08:06 -0400 (EDT) Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by orsfmr001.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i4S063n8010862; Fri, 28 May 2004 00:06:04 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i4S00dsO006344; Fri, 28 May 2004 00:02:40 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004052717045631813 ; Thu, 27 May 2004 17:04:59 -0700 Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 27 May 2004 17:04:49 -0700 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Thu, 27 May 2004 17:04:49 -0700 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcREQvH1QShuwFCTRMGpeZrHIoHfuAAA4h9Q From: "Puthenkulam, Jose P" To: "Avi Lior" , "Bernard Aboba" , "Nelson, David" Cc: X-OriginalArrivalTime: 28 May 2004 00:04:49.0858 (UTC) FILETIME=[64D9D220:01C44447] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable A VSA is intended for use in the standard for vendor specific secret sauce and NOT intended to promote interoperability for systems within an SDO domain except between systems from the same vendor. (Having said this reality lies elsewhere ;) An SDO attribute is intended to promote interoperability within an SDO domain while being able distinguish namespaces for attributes between SDOs when standards are re-used by other SDOs. My 2 cents... Best regards, jose =20 -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Avi Lior Sent: Thursday, May 27, 2004 4:32 PM To: 'Bernard Aboba'; Nelson, David Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > That said, it seems fairly clear to me that the IETF needs to=20 > provide a means by which SDOs can create their own=20 > SDO-specific attributes in a way that will be compatible with=20 > future standardization, if necessary. I agree SDOs will standerdize what they need without going to a "Global" review unless they deem that they need interoperability outside their domain. VSAs fit that definition today - minus the discussion of what exactly a vendor is. Perhaps you can explain how creating a new class of attributes would actually change anything other than satisfy those that insist that an SDO is not a Vendor. That is really my point. Finally, regardless of how some define what a Vendor is - the fact is that SDOs already have Vendor Ids. So that defintion has already be accepted by IANA. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Thursday, May 27, 2004 6:44 PM > To: Nelson, David > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs >=20 >=20 > > > >I don't believe there was ever consensus > > > > in the RADIUS WG that VSAs would be a "standard" method=20 > to extend=20 > > > >the protocol. > > > > > > Can you show me where this was even discussed in the RADIUS WG? >=20 > RFC 2865 Section 6.2 states: >=20 > " Note that RADIUS defines a mechanism for Vendor-Specific=20 > extensions > (Attribute 26) and the use of that should be encouraged instead of > allocation of global attribute types, for functions=20 > specific only to > one vendor's implementation of RADIUS, where no interoperability is > deemed useful." >=20 > An SDO is not a vendor, and typically requires=20 > interoperability between vendors, so that this language does=20 > not apply to use by SDOs. >=20 > That said, it seems fairly clear to me that the IETF needs to=20 > provide a means by which SDOs can create their own=20 > SDO-specific attributes in a way that will be compatible with=20 > future standardization, if necessary. >=20 From owner-aaa-wg@merit.edu Fri May 28 00:41: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 AAA18157 for ; Fri, 28 May 2004 00:41:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5FE0991226; Fri, 28 May 2004 00:41:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10875912C8; Fri, 28 May 2004 00:41: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 8B76191226 for ; Fri, 28 May 2004 00:41:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64F5059686; Fri, 28 May 2004 00:41:04 -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 5F9955967E for ; Fri, 28 May 2004 00:41:03 -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 i4S4efS27476; Fri, 28 May 2004 07:40:41 +0300 (EET DST) X-Scanned: Fri, 28 May 2004 07:39:56 +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 i4S4duPk003659; Fri, 28 May 2004 07:39:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ienYLL; Fri, 28 May 2004 07:39:54 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 i4S4drH24007; Fri, 28 May 2004 07:39:53 +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); Fri, 28 May 2004 07:39:53 +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]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 28 May 2004 07:39:52 +0300 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcREO+uozjeHtzExSmKmVyjizuuerwAMXaJg From: To: , Cc: X-OriginalArrivalTime: 28 May 2004 04:39:53.0864 (UTC) FILETIME=[D2014880:01C4446D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, > An SDO is not a vendor, and typically requires interoperability = between > vendors, so that this language does not apply to use by SDOs. I generally agree. =20 > That said, it seems fairly clear to me that the IETF needs to provide = a > means by which SDOs can create their own SDO-specific attributes in a = way > that will be compatible with future standardization, if necessary. I completely agree. It seems that the IETF generally works from the = 'not invented here' syndrome, and wants to see everything done completely within the IETF, which is not scalable. I think there should be a = difference between vendor-specific attributes / extensions and ones done in SDOs, especially ones that have cooperation with the IETF. John From owner-aaa-wg@merit.edu Fri May 28 01:18: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 BAA19773 for ; Fri, 28 May 2004 01:18:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 897D1912C8; Fri, 28 May 2004 01:17:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AAC0912CC; Fri, 28 May 2004 01:17: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 53429912C8 for ; Fri, 28 May 2004 01:17:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E567595BE; Fri, 28 May 2004 01:17:51 -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 9747D594A3 for ; Fri, 28 May 2004 01:17:50 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4S5IsI12239; Thu, 27 May 2004 22:18:54 -0700 Date: Thu, 27 May 2004 22:18:54 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: dnelson@enterasys.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 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 > I completely agree. It seems that the IETF generally works from the 'not > invented here' syndrome, and wants to see everything done completely > within the IETF, which is not scalable. It has become increasingly apparent that the IETF cannot handle the volume of SNMP MIB work required by SDOs such as IEEE 802.1. Increasingly companies are not willing to foot the travel bill for attending multiple SDO meetings in order to progress the same work item, and the IETF has often become the "odd man out". This argues to moving toward a model where the work is done within the SDO that needs it, with review from IETF "Doctor" teams based on guidelines documents. This is more or less the model we are moving toward with SNMP. To get there with AAA we will need to articulate the application design guidelines for RADIUS and Diameter (and interoperation between them), build up a AAA Doctor team, and iron out differences between the data models in the enterprise and standards space within RADIUS (thankfully, Diameter does not have such a discrepancy). > I think there should be a difference > between vendor-specific attributes / extensions and ones done in SDOs, > especially ones that have cooperation with the IETF. We will have to work through what the difference is and how it is handled. To date we have several proposals on how to handle SDO Specific Attributes (SSAs): a. Allow SDOs to continue to use the existing RADIUS VSA space, but perhaps provide updated guidance on the design of SDO-specific attributes within that space. b. Create a new SSA space with a fixed attribute format, so as to enable more uniform behavior. My sense is that a) is probably most appropriate for SDO work not done in cooperation with IETF. SDOs already are using the existing VSA space and are unlikely to abandon it. But choice b) may be workable for attributes done in SDOs with the cooperation of the IETF, particularly where it is desired to standardize attributes that have previously been implemented in the VSA space. However, if choice b) is really only about IETF work, then perhaps it makes more sense to think of it as an "IETF Extended Attribute Space" rather than an SDO-specific space. The difference between the two comes from whether we think that SDOs will use the SSA space *in addition* to their existing VSA space. And of course in all of this we will need to understand the implications for Diameter-RADIUS translation. From owner-aaa-wg@merit.edu Fri May 28 08: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 IAA27076 for ; Fri, 28 May 2004 08:51:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 78616912D0; Fri, 28 May 2004 08:51:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43646912D3; Fri, 28 May 2004 08: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 25B1B912D0 for ; Fri, 28 May 2004 08:51:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A3FC5973F; Fri, 28 May 2004 08:51:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ctron-dnm.enterasys.com (ctron-dnm.enterasys.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id C3625596F1 for ; Fri, 28 May 2004 08:51:04 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id IAA29667 for ; Fri, 28 May 2004 08:54:05 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma029653; Fri, 28 May 04 08:53:56 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 28 May 2004 08:50:53 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 28 May 2004 08:50:53 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 28 May 2004 08:50:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 28 May 2004 08:50:53 -0400 Message-ID: Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcREcydYEQZxmXh+RAW6F7m1g0hW4gAPgI2w From: "Nelson, David" To: X-OriginalArrivalTime: 28 May 2004 12:50:53.0235 (UTC) FILETIME=[69289030:01C444B2] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.5 X-pstn-levels: (C:93.0328 M:92.8678 P:95.9108 R:95.9108 S:20.2009 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba writes... > To date we have several proposals on how to handle SDO Specific Attributes > (SSAs): >=20 > a. Allow SDOs to continue to use the existing RADIUS VSA space, but > perhaps provide updated guidance on the design of SDO-specific attributes > within that space. >=20 > b. Create a new SSA space with a fixed attribute format, so as to > enable more uniform behavior. >=20 > My sense is that a) is probably most appropriate for SDO work not done in > cooperation with IETF. SDOs already are using the existing VSA space and > are unlikely to abandon it. >=20 > But choice b) may be workable for attributes done in SDOs with the > cooperation of the IETF, particularly where it is desired to standardize > attributes that have previously been implemented in the VSA space. I agree. One additional factor to consider is the potential for re-use. Let's assume that an attribute is created within one SDO, initially for use within an application scope of that SDO, and is later adopted for use by another SDO (potentially the IETF) for a broader or different application scope. It would better to have chosen the (b) option, to promote the re-usability and greater global interoperability. Of course, the problem is that making the right decision when the attribute is initially developed will require some amount foresight into future areas of applicability. That won't always be easy to determine. -- Dave From owner-aaa-wg@merit.edu Fri May 28 09:50: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 JAA00907 for ; Fri, 28 May 2004 09:50:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25AF0912D3; Fri, 28 May 2004 09:50:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DCE2C912D4; Fri, 28 May 2004 09:50: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 0E776912D3 for ; Fri, 28 May 2004 09:50:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED748596DF; Fri, 28 May 2004 09:50:13 -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 4DA885967A for ; Fri, 28 May 2004 09:50:13 -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 i4SDoBK23242; Fri, 28 May 2004 09:50:11 -0400 (EDT) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 28 May 2004 09:50:11 -0400 Message-ID: <7E49849DDCBEAA489C65292E8B8AE7E8A53EF5@zrc2hxm2.corp.nortel.com> From: "Christopher Richards" To: "Nelson, David" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 28 May 2004 09:50:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C444BA.AD1DE09E" 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_000_01C444BA.AD1DE09E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C444BA.AD1DE09E" ------_=_NextPart_001_01C444BA.AD1DE09E Content-Type: text/plain Hi All, So, back to the original question that started this whole discussion. Can the DCCA authors confirm that the encoding of RADIUS VSAs in Diameter is a closed issue? ---- Original email showing incorrect encoding of RADIUS VSA in Diameter --------> Hi All, Quick question I'm sure has been answered before. When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the Diameter AVP header have the Vendor-Specific bit set (and so include the Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it is in RADIUS)? My interpretation is that since AVP code 26 is not a Diameter vendor specific AVP code - but is a RADIUS defined AVP, so that the Vendor-Specific bit is NOT set in the Diameter AVP header. RADIUS encoding of AVP code 26:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Diameter encoding of a RADIUS VSA AVP (code 26):- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags = 0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diameter AVP Data field... +-+-+-+-+-+-+-+-+-+-+-+..... Where the Diameter AVP data field is:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor type | Vendor length | Vendor Data field.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... Is this the intention of RFC3588? Best Regards, Chris. Response -------------> Cheers, Chris. ------_=_NextPart_001_01C444BA.AD1DE09E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi All,

So, back to the original question that started this = whole discussion. Can the DCCA authors confirm that the encoding of = RADIUS VSAs in Diameter is a closed issue?

---- Original email showing incorrect encoding of = RADIUS VSA in Diameter -------->

Hi All,

Quick question I'm sure has been answered before. =

When sending a RADIUS VSA AVP (code 26) in a Diameter = message, should the Diameter AVP header have the Vendor-Specific bit = set (and so include the Vendor-Id field)? Or should the vendor-id be = part of the AVP data (As it is in RADIUS)?

My interpretation is that since AVP code 26 is not a = Diameter vendor specific AVP code - but is a RADIUS defined AVP, so = that the Vendor-Specific bit is NOT set in the Diameter AVP = header.

RADIUS encoding of AVP code 26:-

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   |     = Type      |  = Length       = |            = Vendor-Id
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
        Vendor-Id = (cont)           = |  String...
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Diameter encoding of a RADIUS VSA AVP (code 26):- =

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   | Type =3D = 26           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;     |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   | Flags =3D 0     = |      = Length           =             =             | =
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   | Diameter AVP Data field...
   +-+-+-+-+-+-+-+-+-+-+-+.....

Where the Diameter AVP data field is:-

    = 0            = ;       = 1            = ;       = 2            = ;       3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   | = Vendor-Id          &nb= sp;           &nb= sp;           &nb= sp;           &nb= sp;      |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
   | Vendor type   | Vendor = length | Vendor Data field....
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-......

Is this the intention of RFC3588?

Best Regards,
Chris.


Response ------------->


Cheers,
Chris.

  ------_=_NextPart_001_01C444BA.AD1DE09E-- ------_=_NextPart_000_01C444BA.AD1DE09E Content-Type: message/rfc822 Content-Description: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Message-ID: <161AA64DA85DFC4BA4D2EB5629B59753069F6CE0@zrc2c012.us.nortel.com> From: "Richards, Christopher [RICH2:2Q40:EXCH]" To: marco.stura@nokia.com Cc: david@mitton.com, aaa-wg@merit.edu, jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Tue, 4 May 2004 10:52:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C444BA.AD1DE09E" ------_=_NextPart_003_01C444BA.AD1DE09E Content-Type: text/plain Hi Marco, Thanks for the clarification. Since it is not terribly clear that other Diameter applications should follow the NASREQ specification when encoding RADIUS vendor specific AVPs, I think it would be beneficial if some statement was added to DCC section 8. E.g. When including RADIUS vendor specific attributes in a DCC message, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute. I think it will save confusion in the future. Cheers, Chris. -----Original Message----- From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com ] Sent: Tuesday, May 04, 2004 3:53 AM To: Richards, Christopher [RICH2:2Q40:EXCH] Cc: david@mitton.com; aaa-wg@merit.edu; jari.arkko@kolumbus.fi Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi Chris, >It's not just for translating AVPs on the fly, but also for how to >re-use existing RADIUS >VSA AVPs. >I currently have a RADIUS VSA AVP - a VSA that was defined for RADIUS, that I now want to >use in Diameter. I want avoid having to completely redefine it. >From my reading of RFC3588, it says something along the lines that all AVP codes 0 to 255 >are reserved for RADIUS AVPs. From this I also took that RADIUS AVP code 26 was included. >As an example, if you have access to 3GPP TS 29.061, take a look at the RADIUS VSAs defined >for 3GPP. >When I want to put this information into a Diameter AVP, do I set the >Vendor-ID flag or not? as Dave pointed out the NASREQ is intended to be the generic RADIUS replacement within Diameter. If you just use the NASREQ defined AVPs, that practically uses those AVP numbers from 1 through 255 you're talking about, you should be able to match the 3GPP TS 29.061 needs. For those 3gpp vendor-specific attributes defined in TS 29.061 I think you should follow the rules defined in NASREQ section 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit is to be set. I copied here sect. 9.4 of the NASREQ draft, that clearly state that attribute code 26 must not appear in Diameter messages. Regards Marco 9.4 Prohibited RADIUS Attributes The following RADIUS attributes MUST NOT appear in a Diameter message. Instead, they are translated to other Diameter AVPs or handled in some special manner. The rules for the treatment of the attributes are discussed in Sections 9.1, 9.2 and 9.6. Attribute Description Defined Nearest Diameter AVP ----------------------------------------------------------------- 3 CHAP-Password RFC 2865 CHAP-Auth Group 26 Vendor-Specific RFC 2865 Vendor Specific AVP 29 Termination-Action RFC 2865 Authorization-Lifetime 40 Acct-Status-Type RFC 2866 Accounting-Record-Type 42 Acct-Input-Octets RFC 2866 Accounting-Input-Octets 43 Acct-Output-Octets RFC 2866 Accounting-Output-Octets 47 Acct-Input-Packets RFC 2866 Accounting-Input-Packets 48 Acct-Output-Packets RFC 2866 Accounting-Output-Packets 49 Acct-Terminate-Cause RFC 2866 Termination-Cause 52 Acct-Input-Gigawords RFC 2869 Accounting-Input-Octets 53 Acct-Output-Gigawords RFC 2869 Accounting-Output-Octets 80 Message-Authenticator RFC 2869 none - check and discard ------_=_NextPart_003_01C444BA.AD1DE09E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs

Hi Marco,

Thanks for the clarification.

Since it is not terribly clear that other Diameter = applications should follow the NASREQ specification when encoding = RADIUS vendor specific AVPs, I think it would be beneficial if some = statement was added to DCC section 8. E.g.

When including RADIUS vendor specific attributes in a = DCC message, the rules described in [NASREQ] for formatting the = Diameter AVP MUST be followed. For example, the AVP code used is the = vendor attribute type code, the Vendor-Specific flag MUST be set to 1 = and the Vendor-ID MUST be set to the IANA Vendor identification value. = The Diameter AVP data field contains only the attribute value of the = RADIUS attribute.

I think it will save confusion in the future.

Cheers,
Chris.


-----Original Message-----
From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
Sent: Tuesday, May 04, 2004 3:53 AM
To: Richards, Christopher [RICH2:2Q40:EXCH]
Cc: david@mitton.com; aaa-wg@merit.edu; = jari.arkko@kolumbus.fi
Subject: RE: [AAA-WG]: Diameter encoding of RADIUS = VSA AVPs


Hi Chris,

>It's not just for translating AVPs on the fly, = but also for how to
>re-use existing RADIUS
>VSA AVPs.
>I currently have a RADIUS VSA AVP - a VSA that = was defined for RADIUS, that I now want to
>use in Diameter. I want avoid having to = completely redefine it.
>From my reading of RFC3588, it says something = along the lines that all AVP codes 0 to 255
>are reserved for RADIUS AVPs. From this I also = took that RADIUS AVP code 26 was included.
>As an example, if you have access to 3GPP TS = 29.061, take a look at the RADIUS VSAs defined >for 3GPP.

>When I want to put this information into a = Diameter AVP, do I set the
>Vendor-ID flag or not?

as Dave pointed out the NASREQ is intended to be the = generic RADIUS replacement within Diameter. If you just use the NASREQ = defined AVPs, that practically uses those AVP numbers from 1 through = 255 you're talking about, you should be able to match the 3GPP TS = 29.061 needs.

For those 3gpp vendor-specific attributes defined in = TS 29.061 I think you should follow the rules defined in NASREQ section = 9.6.2, RADIUS Interactions. According to the mentioned rules the V bit = is to be set.

I copied here sect. 9.4 of the NASREQ draft, that = clearly state that attribute code 26 must not appear in Diameter = messages.

Regards
Marco

9.4 Prohibited RADIUS Attributes

   The following RADIUS attributes MUST NOT = appear in a Diameter
   message.  Instead, they are = translated to other Diameter AVPs or
   handled in some special manner. The = rules for the treatment of the
   attributes are discussed in Sections = 9.1, 9.2 and 9.6.


   Attribute = Description       = Defined     Nearest Diameter AVP
   = -----------------------------------------------------------------=
    3 = CHAP-Password          = ;  RFC 2865    CHAP-Auth Group
   26 = Vendor-Specific          = RFC 2865    Vendor Specific AVP
   29 = Termination-Action       RFC = 2865    Authorization-Lifetime
   40 = Acct-Status-Type         RFC = 2866    Accounting-Record-Type
   42 = Acct-Input-Octets        RFC = 2866    Accounting-Input-Octets
   43 = Acct-Output-Octets       RFC = 2866    Accounting-Output-Octets
   47 = Acct-Input-Packets       RFC = 2866    Accounting-Input-Packets
   48 = Acct-Output-Packets      RFC = 2866    Accounting-Output-Packets
   49 = Acct-Terminate-Cause     RFC 2866    = Termination-Cause
   52 = Acct-Input-Gigawords     RFC 2869    = Accounting-Input-Octets
   53 = Acct-Output-Gigawords    RFC 2869    = Accounting-Output-Octets
   80 = Message-Authenticator    RFC 2869    none = - check and discard

------_=_NextPart_003_01C444BA.AD1DE09E-- ------_=_NextPart_000_01C444BA.AD1DE09E-- From owner-aaa-wg@merit.edu Fri May 28 10:18: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 KAA03955 for ; Fri, 28 May 2004 10:18:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B83F912CF; Fri, 28 May 2004 10:18:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 149BA912D4; Fri, 28 May 2004 10:18:12 -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 D8B98912CF for ; Fri, 28 May 2004 10:18:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B052D5976E; Fri, 28 May 2004 10:18:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from exch01.bridgewatersys.com (bws10.bridgewatersystems.com [216.113.7.10]) by segue.merit.edu (Postfix) with ESMTP id 39ECA59762 for ; Fri, 28 May 2004 10:18:10 -0400 (EDT) Received: by exch01.bridgewatersys.com with Internet Mail Service (5.5.2657.72) id ; Fri, 28 May 2004 10:18:09 -0400 Message-ID: From: Avi Lior To: "'Bernard Aboba'" , john.loughney@nokia.com Cc: dnelson@enterasys.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Fri, 28 May 2004 10:18:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk But actually..... I think realisticaly, if an SDO wants to have something interoperate globally it must reliquish control of that attribute to some other entity. The work has got to be handed off to someone else. You can't expect an SDO to address all requirements in other domains. They tend to do a good job addressing their domain. Also, you can't expect them to guarnatee the stability of the attribute. The SDO could make changes not realizing it's impacts on external entities that adopted the attribute in the first place. They may not even know who if anyone has adopted the attribute. I agree with David, preferably it should relinquish control of the attribute early in the game rather then later. But this is what SDOs do today. They use VSA for their local attributes and they handoff work to the IETF when they desire global interoperability. Or they adopt IETF standards. The attributes therefore are IETF attributes. So I don't know what the benefit of having a new class of attribute. What are we really fixing here? Avi > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Friday, May 28, 2004 1:19 AM > To: john.loughney@nokia.com > Cc: dnelson@enterasys.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs > > > > I completely agree. It seems that the IETF generally works > from the > > 'not invented here' syndrome, and wants to see everything done > > completely within the IETF, which is not scalable. > > It has become increasingly apparent that the IETF cannot > handle the volume of SNMP MIB work required by SDOs such as > IEEE 802.1. Increasingly companies are not willing to foot > the travel bill for attending multiple SDO meetings in order > to progress the same work item, and the IETF has often become > the "odd man out". > > This argues to moving toward a model where the work is done > within the SDO that needs it, with review from IETF "Doctor" > teams based on guidelines documents. This is more or less > the model we are moving toward with SNMP. > > To get there with AAA we will need to articulate the > application design guidelines for RADIUS and Diameter (and > interoperation between them), build up a AAA Doctor team, and > iron out differences between the data models in the > enterprise and standards space within RADIUS (thankfully, > Diameter does not have such a discrepancy). > > > I think there should be a difference > > between vendor-specific attributes / extensions and ones > done in SDOs, > > especially ones that have cooperation with the IETF. > > We will have to work through what the difference is and how > it is handled. To date we have several proposals on how to > handle SDO Specific Attributes > (SSAs): > > a. Allow SDOs to continue to use the existing RADIUS VSA > space, but perhaps provide updated guidance on the design of > SDO-specific attributes within that space. > > b. Create a new SSA space with a fixed attribute format, so > as to enable more uniform behavior. > > My sense is that a) is probably most appropriate for SDO work > not done in cooperation with IETF. SDOs already are using > the existing VSA space and are unlikely to abandon it. > > But choice b) may be workable for attributes done in SDOs > with the cooperation of the IETF, particularly where it is > desired to standardize attributes that have previously been > implemented in the VSA space. > > However, if choice b) is really only about IETF work, then > perhaps it makes more sense to think of it as an "IETF > Extended Attribute Space" rather than an SDO-specific space. > The difference between the two comes from whether we think > that SDOs will use the SSA space *in addition* to their > existing VSA space. > > And of course in all of this we will need to understand the > implications for Diameter-RADIUS translation. > From owner-aaa-wg@merit.edu Mon May 31 05:40: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 FAA09236 for ; Mon, 31 May 2004 05:40:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F016E9120E; Mon, 31 May 2004 05:40:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDBEC9120F; Mon, 31 May 2004 05:40: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 6ABA19120E for ; Mon, 31 May 2004 05:40:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5805F59537; Mon, 31 May 2004 05:40:28 -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 BB4FB590DA for ; Mon, 31 May 2004 05:40:27 -0400 (EDT) Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i4V9eQAh029042 for ; Mon, 31 May 2004 11:40:26 +0200 Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Mon, 31 May 2004 11:40:26 +0200 Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Mon, 31 May 2004 11:40:26 +0200 Message-ID: From: "Leena Mattila (TU/LMF)" To: "'Christopher Richards'" Cc: "Nelson, David" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 31 May 2004 11:40:21 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-OriginalArrivalTime: 31 May 2004 09:40:26.0424 (UTC) FILETIME=[4D7CD380:01C446F3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Chris, yes, the draft-05 has been updated as discussed in the aaa mailing-list, see Marco's summary of changes at http://www.merit.edu/mail.archives/aaa-wg/msg00598.html: "6- Section 4.1: added rules how to include RADIUS vendor specific attributes in service specific documents as discussed in aaa mailing-list (http://www.merit.edu/mail.archives/aaa-wg/msg00537.html). When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute value of the RADIUS attribute." BR, Leena -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of Christopher Richards Sent: 28. toukokuuta 2004 16:50 To: Nelson, David; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Hi All, So, back to the original question that started this whole discussion. Can the DCCA authors confirm that the encoding of RADIUS VSAs in Diameter is a closed issue? ---- Original email showing incorrect encoding of RADIUS VSA in Diameter --------> Hi All, Quick question I'm sure has been answered before. When sending a RADIUS VSA AVP (code 26) in a Diameter message, should the Diameter AVP header have the Vendor-Specific bit set (and so include the Vendor-Id field)? Or should the vendor-id be part of the AVP data (As it is in RADIUS)? My interpretation is that since AVP code 26 is not a Diameter vendor specific AVP code - but is a RADIUS defined AVP, so that the Vendor-Specific bit is NOT set in the Diameter AVP header. RADIUS encoding of AVP code 26:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Diameter encoding of a RADIUS VSA AVP (code 26):- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 26 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Flags = 0 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diameter AVP Data field... +-+-+-+-+-+-+-+-+-+-+-+..... Where the Diameter AVP data field is:- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor type | Vendor length | Vendor Data field.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...... Is this the intention of RFC3588? Best Regards, Chris. Response -------------> Cheers, Chris. From owner-aaa-wg@merit.edu Mon May 31 10:10: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 KAA21967 for ; Mon, 31 May 2004 10:10:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E39091209; Mon, 31 May 2004 10:10:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29D339120F; Mon, 31 May 2004 10:10: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 2E17291209 for ; Mon, 31 May 2004 10:10:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 185FB595C0; Mon, 31 May 2004 10:10: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 3B24B59596 for ; Mon, 31 May 2004 10:10:26 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id i4VEAeP01740; Mon, 31 May 2004 07:10:40 -0700 Date: Mon, 31 May 2004 07:10:39 -0700 (PDT) From: Bernard Aboba To: "Leena Mattila (TU/LMF)" Cc: "'Christopher Richards'" , "Nelson, David" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs 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 about if the Vendor-Specific attribute includes *multiple* attributes? This is allowed in RFC 2865. On Mon, 31 May 2004, Leena Mattila (TU/LMF) wrote: > Hi Chris, > > yes, the draft-05 has been updated as discussed in the aaa mailing-list, see Marco's summary of changes at > http://www.merit.edu/mail.archives/aaa-wg/msg00598.html: > "6- Section 4.1: added rules how to include RADIUS vendor specific attributes in service specific documents as discussed in > aaa mailing-list (http://www.merit.edu/mail.archives/aaa-wg/msg00537.html). > When service specific documents include RADIUS vendor specific attributes that could be used as input in the rating > process, the rules described in [NASREQ] for formatting the Diameter AVP MUST be followed. For example, the > AVP code used is the vendor attribute type code, the Vendor-Specific flag MUST be set to 1 and the Vendor-ID > MUST be set to the IANA Vendor identification value. The Diameter AVP data field contains only the attribute > value of the RADIUS attribute." > > BR, > Leena From owner-aaa-wg@merit.edu Mon May 31 10:50: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 KAA24420 for ; Mon, 31 May 2004 10:50:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60C1E9125C; Mon, 31 May 2004 10:49:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FDE89125F; Mon, 31 May 2004 10:49: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 BE15C9125C for ; Mon, 31 May 2004 10:49:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A32935969D; Mon, 31 May 2004 10:49:42 -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 BF6B95953E for ; Mon, 31 May 2004 10:49:36 -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 i4VEieE12749; Mon, 31 May 2004 17:44:40 +0300 (EET DST) X-Scanned: Mon, 31 May 2004 17:43:57 +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 i4VEhvQb023660; Mon, 31 May 2004 17:43:57 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 006Iu4bu; Mon, 31 May 2004 17:43:56 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 i4VEhtH07330; Mon, 31 May 2004 17:43:55 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 31 May 2004 17:43:55 +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]: Diameter encoding of RADIUS VSA AVPs Date: Mon, 31 May 2004 17:43:54 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D015C87D4@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Diameter encoding of RADIUS VSA AVPs Thread-Index: AcRHGTeB+dUNJRymRoijlIo9VaTKrwAA9JWQ From: To: , Cc: , , X-OriginalArrivalTime: 31 May 2004 14:43:55.0507 (UTC) FILETIME=[B2F26430:01C4471D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, > What about if the Vendor-Specific attribute includes *multiple* > attributes? This is allowed in RFC 2865. I think the rule is also defined in NASREQ. We perhaps don't need to repeat it in DCC since there is a reference to NASREQ. From NASREQ sect. 9.6.2 Nested Multiple vendor data fields MUST be expanded into multiple Diameter AVPs. Regards Marco