From owner-aaa-wg@merit.edu Mon Sep 1 05:01:43 2003 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 FAA02531 for ; Mon, 1 Sep 2003 05:01:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B637A9124D; Mon, 1 Sep 2003 05:01:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A393291247; Mon, 1 Sep 2003 05:00: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 9DD8291241 for ; Mon, 1 Sep 2003 05:00:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8AF255DDAE; Mon, 1 Sep 2003 05:00:18 -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 91BDF5DDAD for ; Mon, 1 Sep 2003 05:00:17 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8190D426001 for ; Mon, 1 Sep 2003 12:00:15 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Sep 2003 12:00:13 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:00:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:00:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Route-Record AVP in responses Date: Mon, 1 Sep 2003 12:00:13 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222DA@esebe023.ntc.nokia.com> Thread-Topic: Route-Record AVP in responses Thread-Index: AcNwZ3RAtZ826cN0TKu0p8FdJ0s0Vw== From: To: X-OriginalArrivalTime: 01 Sep 2003 09:00:13.0540 (UTC) FILETIME=[74863240:01C37067] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Route-Record AVP in responses Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: September 1, 2003 Reference:=20 Document: base and nasreq Comment type: T/E Priority: 1 Section: various Rationale/Explanation of issue: Oops, I know it's kinda late to notice this... but there=20 seems to be some inconsistencies about the Route-Record AVP in some of the following: Base, NASREQ, my head. Route-Record AVP use in requests seems to be ok, but it is not clear if responses should have Route-Record AVPs. - The AVP occurrence tables (in both Base and NASREQ) show=20 that Accounting-Answers MAY have Route-Record AVPs, but=20 all other responses MUST NOT have them. - There's no text saying when or if agents or servers=20 should add Route-Record AVP(s) to responses. - Base (Section 2.10) says that "...the local Diameter agent,=20 on receiving a Diameter response authorizing a session,=20 MUST check the Route-Record AVPs...".=20 - NASREQ (Section 9.2) says that RADIUS translation should add Route-Record AVPs to AA-Answers. (Route-Record is=20 mentioned several times in Section 9, but all the other=20 cases apply only to requests, so they're probably ok). Proposed change: I'm not totally sure what the correct change would be (that is, should answers have Route-Record AVPs or not). They were removed in issue 228, but the text about path authorization (added in issue 390) clearly assumes we=20 have them. Best regards, Pasi From owner-aaa-wg@merit.edu Mon Sep 1 05:13:58 2003 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 FAA02730 for ; Mon, 1 Sep 2003 05:13:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 06A2B91241; Mon, 1 Sep 2003 05:13:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C65DC91247; Mon, 1 Sep 2003 05:13: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 4B48B91241 for ; Mon, 1 Sep 2003 05:13:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E3AF5DDAD; Mon, 1 Sep 2003 05:13:46 -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 7B7095DDC7 for ; Mon, 1 Sep 2003 05:13:45 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h819DeB23303 for ; Mon, 1 Sep 2003 12:13:44 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 1 Sep 2003 12:13:39 +0300 Received: from esebe011.NOE.Nokia.com ([172.21.138.50]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:13:39 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe011.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 1 Sep 2003 12:06:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Misspelled AVP in NASREQ Date: Mon, 1 Sep 2003 12:06:51 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BBBF@esebe023.ntc.nokia.com> Thread-Topic: Misspelled AVP in NASREQ Thread-Index: AcNwaGGtsi1Oe2Q3Tomos2f1UtLSbw== From: To: X-OriginalArrivalTime: 01 Sep 2003 09:06:52.0421 (UTC) FILETIME=[62469B50:01C37068] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Misspelled AVP in NASREQ Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: September 1, 2003 Reference:=20 Document: nasreq Comment type: E Priority: 2 Section: 9.3 Rationale/Explanation of issue: I also noticed that "Route-Record" is misspelled as "Record-Route"=20 several times in NASREQ. All of the cases apply only to requests, so this is purely editorial (and independent of the other issue related to this AVP). Proposed change: search and replace. From owner-aaa-wg@merit.edu Mon Sep 1 13:16:37 2003 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 NAA09577 for ; Mon, 1 Sep 2003 13:16:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E45EB91250; Mon, 1 Sep 2003 13:16:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E22269124B; Mon, 1 Sep 2003 13:16: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 8E34F91250 for ; Mon, 1 Sep 2003 13:15:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 758085DDDC; Mon, 1 Sep 2003 13:15:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id C78125DDDB for ; Mon, 1 Sep 2003 13:15:51 -0400 (EDT) Received: (cpmta 12283 invoked from network); 1 Sep 2003 10:15:50 -0700 Received: from 66.30.106.11 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 1 Sep 2003 10:15:50 -0700 X-Sent: 1 Sep 2003 17:15:50 GMT Message-Id: <5.2.1.1.2.20030901131026.03cfcec0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 01 Sep 2003 13:10:45 -0400 To: , From: David Mitton Subject: Re: [AAA-WG]: Misspelled AVP in NASREQ In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A608BBBF@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 On 9/1/2003 12:06 PM +0300, Pasi.Eronen@nokia.com wrote: >Misspelled AVP in NASREQ >Submitter name: Pasi Eronen >Submitter email address: pasi.eronen@nokia.com >Date first submitted: September 1, 2003 >Reference: >Document: nasreq >Comment type: E >Priority: 2 >Section: 9.3 >Rationale/Explanation of issue: > >I also noticed that "Route-Record" is misspelled as "Record-Route" >several times in NASREQ. All of the cases apply only to requests, >so this is purely editorial (and independent of the other >issue related to this AVP). > >Proposed change: search and replace. I will fix that. Thanks. Dave. From owner-aaa-wg@merit.edu Mon Sep 1 13:29:06 2003 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 NAA09725 for ; Mon, 1 Sep 2003 13:29:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 211C39124B; Mon, 1 Sep 2003 13:28:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6F7B9124F; Mon, 1 Sep 2003 13:28: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 CEBDA9124B for ; Mon, 1 Sep 2003 13:28:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF7285DDD3; Mon, 1 Sep 2003 13:28:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 302CD5DD8C for ; Mon, 1 Sep 2003 13:28:56 -0400 (EDT) Received: (cpmta 19957 invoked from network); 1 Sep 2003 10:28:51 -0700 Received: from 66.30.106.11 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 1 Sep 2003 10:28:51 -0700 X-Sent: 1 Sep 2003 17:28:51 GMT Message-Id: <5.2.1.1.2.20030901131418.02d34d90@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 01 Sep 2003 13:20:39 -0400 To: , From: David Mitton Subject: Re: [AAA-WG]: Authorization-Lifetime/Session-Timeout confusion In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222CB@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 I like this suggestion. Bernard had complained about a similar issue in #404 wrt to 802.1x, but I had problems working out all the details. If there are no further comments, I'll incorporate this approach in NASREQ making sure it works with IEEE 802.1x or 802.1aa or whatever it is this week. Dave. On 8/15/2003 04:13 PM +0300, Pasi.Eronen@nokia.com wrote: >Submitter name: Pasi Eronen >Submitter email address: pasi.eronen@nokia.com >Date first submitted: August 15, 2003 >Reference: >Document: NASREQ >Comment type: T >Priority: 1 >Section: various >Rationale/Explanation of issue: > >There seems to be some confusion about Authorization-Lifetime >and Session-Timeout AVPs between Base and NASREQ. > >More specifically, the state machine in Base (Section 8.1) >specifies that when Session-Timeout expires, the access >device MUST send a STR and move to state Discon. > >This is inconsistent with with NASREQ description for >Termination-Action AVP, which allows other behavior as well. > >Proposed change: > >Remove the Termination-Action AVP completely. > >When translating a RADIUS Access-Accept to Diameter AA-Answer, >do the following: > >- If the RADIUS message contains a Session-Timeout attribute > and a Termination-Action attribute set to DEFAULT (or no > Termination-Action attribute at all), translate it > to AA-Answer with a Session-Timeout AVP (and remove > the Termination-Action attribute). > >- If the RADIUS message contains a Session-Timeout attribute > and a Termination-Action attribute set to AA-REQUEST, > translate it to AA-Answer with Authorization-Lifetime AVP > and Re-Auth-Request-Type set to AUTHORIZE_AUTHENTICATE > (and remove the Session-Timeout attribute). > >When translating a Diameter AA-Answer (with successful result >code) to RADIUS Access-Accept, > >- If the Diameter message contains a Session-Timeout AVP but no > Authorization-Lifetime AVP, translate it to Session-Timeout > attribute (and no Termination-Action). > >- If the Diameter message contains a Authorization-Lifetime AVP but > no Session-Timeout AVP, translate it to Session-Timeout attribute > and Termination-Action set to AA-REQUEST. (And remove > Authorization-Lifetime and Re-Auth-Request-Type) > >- If the Diameter message has both, the Session-Timeout is always > greater or equal than Authorization-Lifetime (required by Base). > I guess the safest bet is to translate it to Session-Timeout > value (with value from Authorization-Lifetime AVP, the smaller one) > and Termination-Action set to AA-REQUEST. (And remove > Authorization-Lifetime and Re-Auth-Request-Type) > >Best regards, >Pasi From owner-aaa-wg@merit.edu Mon Sep 1 13:42:31 2003 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 NAA09878 for ; Mon, 1 Sep 2003 13:42:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9784491252; Mon, 1 Sep 2003 13:42:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D1B491253; Mon, 1 Sep 2003 13:42: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 4EF8B91252 for ; Mon, 1 Sep 2003 13:42:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 395105DDD0; Mon, 1 Sep 2003 13:42:23 -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 AC2055DDB9 for ; Mon, 1 Sep 2003 13:42:22 -0400 (EDT) Received: (cpmta 22880 invoked from network); 1 Sep 2003 10:41:51 -0700 Received: from 66.30.106.11 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.65) with SMTP; 1 Sep 2003 10:41:51 -0700 X-Sent: 1 Sep 2003 17:41:51 GMT Message-Id: <5.2.1.1.2.20030901132534.03cfec00@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 01 Sep 2003 13:29:09 -0400 To: Jari Arkko , Pasi.Eronen@nokia.com From: David Mitton Subject: Re: [AAA-WG]: Authentication method AVP? Cc: aaa-wg@merit.edu In-Reply-To: <3F38BC4E.2080605@kolumbus.fi> References: <052E0C61B69C3741AFA5FE88ACC775A608BB8B@esebe023.ntc.nokia.com> <052E0C61B69C3741AFA5FE88ACC775A608BB8B@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 On 8/12/2003 01:07 PM +0300, Jari Arkko wrote: >Pasi.Eronen@nokia.com wrote: >>Authentication method AVP? >>Submitter name: Pasi Eronen >>Submitter email address: pasi.eronen@nokia.com >>Date first submitted: August 12, 2003 >>Reference: Document: NASREQ-12/EAP >>Comment type: T >>Priority: 2 >>Section: - >>Rationale/Explanation of issue: >>Diameter EAP application has Accounting-EAP-Auth-Method AVP that >>corresponds to the MS-Acct-EAP-Type RADIUS attribute from RFC 2548. In >>RADIUS, this attribute is used together with MS-Acct-Auth-Type attribute >>(which has values for PAP, CHAP, EAP, MS-CHAP-1, etc.). >>Should NASREQ have a corresponding AVP, named perhaps >>Accounting-Auth-Method? (Note that this is different from > >Yes. > >>Acct-Authentic AVP, which has values for local, RADIUS and Diameter) >>I guess we could define this AVP in Diameter EAP document if adding this >>to NASREQ this late would be a problem. > >I think we should put it in NASREQ. > >--Jari Okay, can we elaborate more on the intended semantics? Is this an informational readout for Accounting as to what auth method was actually used? Which end originates it? (if accounting only, then client to Acct server) Which way does it flow? Can we enumerate all the desired values? How does this relate to the RADIUS attributes and MS VSAs at a protocol gateway? We have a day to get this in. Dave. From owner-aaa-wg@merit.edu Mon Sep 1 14:42:55 2003 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 OAA10601 for ; Mon, 1 Sep 2003 14:42:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EF3B9124E; Mon, 1 Sep 2003 14:42:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CCAF191255; Mon, 1 Sep 2003 14:42: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 BC9519124E for ; Mon, 1 Sep 2003 14:42:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A593C5DDAF; Mon, 1 Sep 2003 14:42:45 -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 CF82B5DDB2 for ; Mon, 1 Sep 2003 14:42:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h81IBBt25454 for ; Mon, 1 Sep 2003 11:11:11 -0700 Date: Mon, 1 Sep 2003 11:11:11 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Diameter/DynAuth RADIUS translation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: September 1, 2003 Reference: Document: nasreq-12 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Update the references: [RADDynAuth] M. Chiba, M Dommety, M. Eklund, D. Mitton, B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, August 2003. [RADIUSIANA] B. Aboba, "IANA Considerations for RADIUS", RFC 3575, August 2003. [RAD802.1X] P. Congdon, et.al "IEEE 802.1X RADIUS Usage Guidelines", RFC 3580, September 2003. Update Section 6.1 to include the new Service-Type value: 17 Authorize Only [RFC3576] Delete the following text from Section 9.1: " If the Diameter translation system receives a message as specified in [RADDynAuth], it may translate it into a Diameter Re-Auth-Request message. The consistency and security rules of that specification MUST be applied to the processing and forwarding of this type of message." Add the following to Section 9.1: As described in Section 3.2 of [RADDynAuth], a Service-Type of "Authorize Only" is used in a Disconnect-Request or CoA-Request message, in order to allow for easier translation between RADIUS and Diameter. In order to simplify implementation, a RADIUS/Diameter gateway receiving a RADIUS Disconnect-Request without a Service-Type value of "Authorize Only" MAY reply with a Disconnect-Nak with an Error-Cause attribute with value 405," Unsupported Service" and no Service-Type attribute. Similarly, a RADIUS/Diameter gateway receiving a RADIUS CoA-Request without a Service-Type value of "Authorize Only" MAY reply with a CoA-Nak with an Error-Cause attribute with value 405, "Unsupported Service" and no Service-Type attribute. When included within a RADIUS Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes. A RADIUS CoA-Request is translated to a Diameter Re-Authorization Request (RAR), and a RADIUS Disconnect-Request is translated to a Diameter Session-Termination-Request (STR). A Diameter Re-Authorization Request (RAR) message will receive a Diameter Re-Authorization Answer (RAA) reply which is translated to a RADIUS CoA-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated." A Diameter Session-Termination-Request (STR) message will receive a Diameter Session-Termination-Answer (STA) message reply which is tranlated to a RADIUS Disconnect-Nak containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated." After a Diameter Re-Authorization Answer (RAA) is sent, a Diameter AA-Request will then be sent and is translated to a RADIUS Access-Request with a Service-Type attribute with value "Authorize Only", attempting reauthorization. This Access-Request contains the NAS attributes from the CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request. The RADIUS server will send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it. This is translated to a Diameter AA-Answer. After a Diameter Session-Termination-Answer (STA) is sent, a Diameter Abort-Session-Request (ASR) will be sent and is translated to a RADIUS Access-Request with a Service-Type attribute with value "Authorize Only", attempting reauthorization. This Access-Request contains the NAS and session attributes from the Disconnect-Rquest. The RADIUS server send back an Access-Reject to terminate the session. This is translated to a Diameter Abort-Session-Answer (ASA)." Add the following to Section 9.2: "A Diameter Re-Authorization-Request (RAR) message may be translated to a RADIUS CoA-Request with a Service-Type of "Authorization Only". If a RADIUS CoA-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated" is received in reply, this is translated to a Diameter Re-Authorization-Answer (RAA). An ensuing RADIUS Access-Request with Service-Type of "Authorize Only" is translated to a Diameter AA-Request, and the Diameter AA-Answer is translated to a RADIUS Access-Accept or Access-Reject. A Diameter Session-Termination-Request (STR) is translated to a RADIUS Disconnect-Rquest with a Service-Type of "Authorization Only". If a RADIUS Disconnect-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated" is received in reply, this is translated to a Diameter Session-Termination-Answer (STA). An ensuing RADIUS Access-Request with Service-Type of "Authorize Only" is translated to a Diameter Abort-Session-Request, and the Diameter Abort-Session-Answer is translated to a RADIUS Access-Reject." From mailman-admin@ietf.org Mon Sep 1 22:00:09 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20412 for ; Mon, 1 Sep 2003 22:00:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toL0-0008Nd-61 for aaa-archive@lists.ietf.org; Mon, 01 Sep 2003 09:03:18 -0400 Date: Mon, 01 Sep 2003 09:03:18 -0400 Message-ID: <20030901130318.21711.75643.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-archive@lists.ietf.org: List Password // URL ---- -------- aaa@ietf.org kaithu https://www1.ietf.org/mailman/options/aaa/aaa-archive%40lists.ietf.org From owner-aaa-wg@merit.edu Tue Sep 2 04:40:04 2003 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 EAA00494 for ; Tue, 2 Sep 2003 04:40:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DE359125A; Tue, 2 Sep 2003 04:39:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 377B39125B; Tue, 2 Sep 2003 04:39: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 C437C9125A for ; Tue, 2 Sep 2003 04:39:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A40535DE07; Tue, 2 Sep 2003 04:39:51 -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 2298D5DDCE for ; Tue, 2 Sep 2003 04:39:50 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h828djB19355 for ; Tue, 2 Sep 2003 11:39:47 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 11:39:44 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 11:39:44 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 11:39:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Authentication method AVP? (issue 417) Date: Tue, 2 Sep 2003 11:39:43 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222DC@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Authentication method AVP? Thread-Index: AcNwsGnSbYsLwJgVSyGnh3yvyDWh+AAe+q/A From: To: , Cc: X-OriginalArrivalTime: 02 Sep 2003 08:39:44.0486 (UTC) FILETIME=[C25D3060:01C3712D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable David Mitton wrote: > Okay, can we elaborate more on the intended semantics? >=20 > Is this an informational readout for Accounting as to what auth=20 > method was actually used? >=20 > Which end originates it? (if accounting only, then client=20 > to Acct server) Which way does it flow? Can we enumerate all the=20 > desired values? > > How does this relate to the RADIUS attributes and MS VSAs at a=20 > protocol gateway? >=20 > We have a day to get this in. Like I said earlier, not delaying NASREQ is more important than getting this AVP in (and it could be defined somewhere else, like Diameter EAP, if necessary). The AVP would be informational, from the client to the accounting server. RFC2548 defines the following values for MS-Acct-Auth-Type:=20 PAP (1), CHAP (2), MS-CHAP-1 (3), MS-CHAP-2 (4), and EAP (5).=20 I guess we need a new IANA-managed namespace for these;=20 the initial values could be these for easier translation. Proposed text: - New section (possibly after 8.6) 8.TBD Accounting-Auth-Method AVP The Accounting-Auth-Method AVP (AVP Code TBD) is of type=20 Enumerated. A NAS MAY include this AVP in an Accounting-Request=20 message to indicate what authentication method was used to=20 authenticate the user. The following values are defined: 1 PAP 2 CHAP 3 MS-CHAP-1 4 MS-CHAP-2 5 EAP (BTW, a web page on Microsoft TechNet also shows values NONE (7) and=20 CUSTOM (8), though it's not clear if these are actually ever used. Maybe we should include NONE here?) or=20 - The IANA considerations also need updates. Proposed text: (before 11.1) "This document also creates one new namespace to=20 be managed by IANA, as described in Section 11.5".=20 11.5 Accounting-Auth-Method AVP Values As defined in Section 8.TBD, the Accounting-Auth-Method AVP=20 (AVP Code TBD) defines the values 1-5. All remaining values are=20 available for assignment via IETF Consensus [IANA]." - Section 9: Should we also mention that this AVP could be=20 translated to MS-Acct-Auth-Type VSA? On the other hand,=20 we're not including any translation hints for other VSAs (though Diameter EAP will mention the possibility of=20 translating between MS-MPPE-Send/Recv-Key and whatever key AVP=20 it defines). - Also needs update for this: table in beginning of Section 8,=20 AVP occurrence tables in Sections 10.2.1 and 10.2.2. Best regards, Pasi From owner-aaa-wg@merit.edu Tue Sep 2 08:59:48 2003 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 IAA19240 for ; Tue, 2 Sep 2003 08:59:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03DD191261; Tue, 2 Sep 2003 08:59:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BB3DA91262; Tue, 2 Sep 2003 08:59:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F2FE91261 for ; Tue, 2 Sep 2003 08:59:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CC945DE0B; Tue, 2 Sep 2003 08:59:33 -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 0F3EB5DD8C for ; Tue, 2 Sep 2003 08:59:32 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h82CxTB10971 for ; Tue, 2 Sep 2003 15:59:31 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 2 Sep 2003 15:59:29 +0300 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 15:59:29 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 15:59:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Diameter Credit Control: Failover procedures updated Date: Tue, 2 Sep 2003 15:59:28 +0300 Message-ID: Thread-Topic: [AAA-WG]: Authentication method AVP? Thread-Index: AcNwsGnSbYsLwJgVSyGnh3yvyDWh+AAe+q/AAAlSAAA= From: To: X-OriginalArrivalTime: 02 Sep 2003 12:59:28.0991 (UTC) FILETIME=[0B73EEF0:01C37152] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, After some discussion, we are proposing the following changes to the = Credit Control=20 Failover procedure. I believe Avi raised this point in his review. = We'd appreciate comments on this, we plan on incorporating this into the next version of = the draft. thanks, John 1) Change the second and third paragraphs in section 4.1.4 Failure = Procedures FROM If a communication failure occurs during an ongoing credit-control = session the credit-control client can move the credit control message = stream to an alternative server if the value of the CC-Session-Failover = AVP is set to FAILOVER SUPPORTED. A secondary Credit control server name = received for instance from the AAA server, can be used as an address of = the backup server. If the CC-Session-Failover AVP is set to FAILOVER_NOT = SUPPORTED the credit control message stream MUST NOT be moved to backup = server and the credit control client will terminate or continue the = service depending on the value set in the = Credit-Control-Failure-Handling AVP. The Credit-Control-Failure-Handling = AVP MAY be sent from the authorization server and in the = Credit-Control-Answer from the credit-control server. For new = credit-control sessions, failover to an alternate credit-control server = SHOULD be performed, if possible. The timer, Tx (as defined in section 10), is used in the credit-control = client to supervise the communication with the credit-control server. TO If a failure occurs during an ongoing credit-control session the = credit-control client may move the credit control message stream to an = alternative server if the value of the CC-Session-Failover AVP is set to = FAILOVER SUPPORTED. A secondary Credit control server name received for = instance from the AAA server or locally configured, can be used as an = address of the backup server. If the CC-Session-Failover AVP is set to = FAILOVER_NOT SUPPORTED the credit control message stream MUST NOT be = moved to backup server.=20 For new credit control sessions, failover to an alternative = credit-control server SHOULD be performed if possible. For instance, if = an implementation of the credit control client can determine primary = credit control server unavailability it can establish the new credit = control sessions with a possibly available secondary credit control = server. The AAA client/agent is typically using only a single persistent = transport connection to the AAA agent or server, but it may have = connections to multiple AAA agents or servers and treat them as = primary/secondary or balance load between them. The AAA transport = profile [AAATRANS] defines the application layer watchdog algorithm that = enables failover from a peer that has failed and is controlled by the = timer Twinit. The recommended default value for Twinit is 30 seconds. = Since the AAA infrastructure is common to several different types of AAA = applications, tuning the timer Twinit to a lower value in order to = satisfy the requirements of real-time applications, such as the Diameter = Credit Control application, will certainly increase the probability of = premature failover significantly and potentially cause congestive = collapse in heavy loaded networks. For prepaid services, however, the = end user expects an answer from the network in a reasonable time, thus = the Diameter credit control client shall react faster than the = underlaying base protocol. Therefore this specification defines the = timer Tx that is used by the credit-control client (as defined in = section 10) to supervise the communication with the credit-control = server. When the timer Tx elapses the credit-control client takes an = action to the end user according to the Credit-Control-Failure-Handling = AVP. The Credit-Control-Failure-Handling AVP MAY be sent from the = authorization server and in the Credit-Control-Answer from the = credit-control server. =20 When Tx expires, the Diameter credit control client always terminates = the service if the Credit-Control-Failure-Handling (CCFH) AVP is set to = the value TERMINATE. The credit control session may be moved to an = alternative server only in case a protocol error DIAMETER_TOO_BUSY or = DIAMETER_UNABLE_TO_DELIVER is received before Tx expires, therefore, the = value TERMINATE is not appropriate if proper failover behavior is = desired. 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). 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.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. 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. 2) Add the following sentence at the end of section 4.1.4 In order to support the failover between credit control servers = information transfer about the credit control session and account state = SHOULD take place between the primary and the secondary credit control = server. Implementations supporting the credit control session failover = MUST also ensure proper detection of duplicate or out of sequence = messages. The communication between the servers is regarded as an = implementation issue and is outside of the scope of this specification. 3) Change the first and fourth paragraphs in section 4.2.5 Failure = Procedures FROM Failover to an alternate credit-control server is allowed for one time = event since the server is not maintaining session states. There MAY = exist protocol transparent Diameter relays and redirect agents or = Diameter credit-control proxies between credit-control client and = credit-control server. Failover may occur at any point in the path = between credit-control client and credit-control server in the event = that a transport failure is detected with a peer, as described in = [DIAMBASE]. If the requested action is DIRECT_DEBITING and the = Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER the = credit-control client SHOULD terminate the service if it can determine = from the result code or error code in the answer message that units have = not been debited. Otherwise the credit-control client SHOULD grant the = service to the end user and store the request in the credit-control = application level non-volatile storage. The credit-control client MUST = mark these request messages as possible duplicate by setting the T-flag = in the command header as described in [DIAMBASE] section 3. If the = Direct-Debiting-Failure-Handling AVP is set to CONTINUE the service = SHOULD be granted even if credit-control messages can't be delivered. If = the timer Tx expires the credit-control client MUST continue the service = and eventually buffer the request according to the value of the = Direct-Debiting-Failure-Handling AVP.=20 =20 TO Failover to an alternative credit-control server is allowed for one time = event since the server is not maintaining session states, for instance, = if the credit control client receives a protocol error = DIAMETER_UNABLE_TO_DELIVER or DIAMETER_TOO_BUSY it can re-send the = request to an alternative server if possible. There MAY exist protocol = transparent Diameter relays and redirect agents or Diameter = credit-control proxies between credit-control client and credit-control = server. Failover may occur at any point in the path between = credit-control client and credit-control server in the event that a = transport failure is detected with a peer, as described in [DIAMBASE]. If the requested action is DIRECT_DEBITING and the = Direct-Debiting-Failure-Handling AVP is set to TERMINATE_OR_BUFFER, the = credit-control client SHOULD terminate the service if it can determine, = eventually after a possible re-transmission attempt to an alternative = credit control server, from the result code or error code in the answer = message that units have not been debited. Otherwise the credit-control = client SHOULD grant the service to the end user and store the request in = the credit-control application level non-volatile storage (Note that = re-sending the request at a later time is not a guarantee that the = service will be debited, since the user's account may be empty at the = time when the server successfully processes the request). The = credit-control client MUST mark these request messages as possible = duplicate by setting the T-flag in the command header as described in = [DIAMBASE] section 3. If the Direct-Debiting-Failure-Handling AVP is set = to CONTINUE, the service SHOULD be granted even if credit-control = messages cannot be delivered and messages are not buffered. If the timer Tx expires the credit-control client MUST continue the = service and wait for a possible late answer. If the request timeout the = credit control client re-transmit the request (marked with T-flag) to a = backup credit control server if possible. In the event that also the = re-transmitted request timeout or a temporary error is received in = answer to such a request, the credit control client eventually buffers = the request according to the value of the = Direct-Debiting-Failure-Handling AVP. If a failed answer is received for = the re-transmitted request, the credit control client free all the = resources reserved for the event message. 4) Change the 'Failure to send' definition in section 4.5 FROM In the state table, the event 'Failure to send' means that the Diameter = credit-control client is unable to communicate with the desired = destination (i.e. the answer message is not received within the validity = time of the request). This could be due to the peer being down, or due = to a physical link failure in the path to/from the credit-control = server. TO In the state table, the event 'Failure to send' means that the Diameter = credit-control client is unable to communicate with the desired = destination or with a possibly defined alternative destination in case = failover procedure is supported (e.g. the request timeout and the answer = message is not received). This could be due to the peer being down, or = due to a physical link failure in the path to/from the credit-control = server. 5) Change the 'Temporary error' definition in section 4.5 FROM The event 'Temporary error' means that the Diameter credit-control = client received a transient failure notification in the = Credit-Control-Answer command (i.e. the peer sending back a transient = failure or temporary protocol error notification DIAMETER_TOO_BUSY, or = DIAMETER_LOOP_DETECTED in the Result-Code AVP). TO The event 'Temporary error' means that the Diameter credit-control = client received a protocol error notification DIAMETER_TOO_BUSY, = DIAMETER_UNABLE_TO_DELIVER or DIAMETER_LOOP_DETECTED in the Result-Code = AVP of the Credit-Control-Answer command. The above protocol error = notification may be ultimately received in answer to the re-transmitted = request to a possibly defined alternative destination if failover is = supported. 6) Change the 'Failed answer' definition in section 4.5 FROM The event 'Failed answer' means that the Diameter credit-control client = received non-transient failure (permanent failure) notification in the = Credit-Control-Answer command.=20 TO The event 'Failed answer' means that the Diameter credit-control client = received non-transient failure (permanent failure) notification in the = Credit-Control-Answer command. The above permanent failure notification = may be ultimately received in answer to the re-transmitted request to a = possibly defined alternative destination if failover is supported. 7) Update the state machine in section 4.5 as follow In the following state machine table the failover to a possibly = secondary server upon 'Temporary error' or 'Failure to send' is not = explicitely described. Moving an ongoing credit control message stream = to an alternative server is, however, possible if the = CC-Session-Failover AVP is set to FAILOVER_SUPPORTED as described in = section 4.3.4. Re-sending a credit control event to a an alternative server is = supported as described in section 4.2.5. CLIENT, SESSION BASED for the first interrogation with CCR=20 State Event Action New State=20 ---------------------------------------------------------------=20 Idle Client or device requests Send PendingI=20 access/service CC initial req.,=20 start Tx.=20 =20 PendingI Successful CC initial Stop Tx Open=20 answer received=20 =20 PendingI Failure to send, or Grant Idle=20 temporary error and service to =20 credit-control fault end user=20 handling equal to CONTINUE =20 =20 PendingI Failure to send, or Terminate Idle=20 temporary error and end user's=20 credit-control fault service handling equal to TERMINATE or equal to RETRY_AND_TERMINATE =20 PendingI Tx expired and credit Terminate Idle=20 Control fault handling end user's equal to TERMINATE service =20 PendingI Tx expired and credit-control Grant PendingI=20 fault handling equal to service to =20 CONTINUE or equal to end user RETRY_AND_TERMINATE=20 =20 PendingI CC initial answer Terminate Idle=20 received with result code end user's=20 SERVICE_ DENIED or service USER_UNKNOWN=20 =20 PendingI CC initial answer Grant Idle=20 received with result code service =20 equal to credit-control N/A to end user=20 =20 PendingI Failed CC initial answer Grant Idle=20 received and credit-control Service to=20 fault handling end user=20 equal to CONTINUE=20 =20 PendingI Failed CC initial answer Terminate Idle=20 received and credit-control end user's=20 failure handling equal to service TERMINATE or equal to RETRY_AND_TERMINATE=20 =20 PendingI User service terminated Queue PendingI=20 termination=20 event =20 =20 PendingI Change in rating condition Queue PendingI=20 changed=20 rating =20 condition =20 event =20 =20 =20 CLIENT, SESSION BASED for intermediate and final interrogations=20 State Event Action New State=20 ---------------------------------------------------------------=20 Open Granted unit elapses Send PendingU=20 and no final unit CC update=20 indication received req.,=20 start Tx. =20 =20 Open Granted unit elapses Terminate PendingT=20 and final unit indication end user's =20 received service, send CC termination =20 req.,=20 start Tx.=20 =20 Open Change in rating condition Send PendingU=20 in queue CC update=20 req.,=20 Start Tx. =20 =20 Open Service terminated in queue Send PendingT=20 CC termination=20 req.,=20 start Tx=20 =20 Open Change in rating condition Send PendingU=20 or Validity-Time elapses CC update=20 req.,=20 Start Tx. =20 =20 Open User service terminated Send PendingT=20 CC termination=20 req.,=20 start Tx =20 =20 PendingU Successful CC update Stop Tx Open=20 answer received=20 =20 PendingU Failure to send, or Grant Idle=20 temporary error and service to=20 credit-control fault end user=20 handling equal to CONTINUE =20 =20 PendingU Failure to send, or Terminate Idle=20 temporary error and end user's=20 credit-control fault service handling equal to TERMINATE or equal to RETRY_AND_TERMINATE=20 =20 PendingU Tx expired and credit-control Terminate Idle=20 fault handling equal to end user's=20 TERMINATE service =20 PendingU Tx expired and credit-control Grant PendingU=20 fault handling equal to service to =20 CONTINUE or equal to end user. RETRY_AND_TERMINATE=20 =20 PendingU CC update answer Terminate Idle=20 received with result code end user's=20 SERVICE_DENIED service =20 PendingU CC update answer Grant Idle=20 received with result code service =20 equal to credit-control N/A to end user=20 =20 PendingU Failed CC update Grant Idle=20 answer received and credit service to=20 control fault handling equal end user.=20 to CONTINUE=20 =20 PendingU Failed CC update Terminate Idle=20 answer received and credit end user's=20 control fault handling service equal to TERMINATE or equal to RETRY_AND_TERMINATE=20 =20 PendingU User service terminated Queue PendingU termination=20 event=20 =20 PendingU Change in rating Queue PendingU=20 condition changed =20 rating=20 condition =20 event=20 =20 PendingT Successful CC Idle=20 termination answer received=20 =20 PendingT Tx expired PendingT=20 =20 PendingT Failure to send, or temporary Idle=20 error or failed answer=20 =20 PendingT Change in rating condition PendingT=20 =20 =20 =20 CLIENT, EVENT BASED=20 State Event Action New State=20 ----------------------------------------------------------------=20 Idle Client or device requests Send PendingE=20 a one-time service CC event=20 req.,=20 Start Tx.=20 =20 Idle Request in storage Send PendingB=20 stored =20 request=20 =20 PendingE Successful CC event Idle=20 answer received=20 =20 PendingE Failure to send, temporary Indicate Idle=20 error or failed CC event service=20 answer received, or error=20 Tx expired, requested =20 action GET_BALANCE or=20 PRICE_ENQUIRY=20 =20 PendingE CC event answer Terminate Idle=20 received with result code end user's=20 SERVICE_DENIED or service USER_UNKNOWN and Tx running =20 =20 PendingE CC event answer Grant Idle=20 received with result code service=20 credit-control N/A, requested to end =20 action DIRECT_DEBITING user=20 =20 PendingE Failure to send, temporary Grant Idle=20 error or failed CC event service=20 answer received, requested to end=20 action DIRECT_DEBITING and user fault handling equal to =20 CONTINUE=20 =20 PendingE Failed CC event Terminate Idle=20 answer received or temporary end user's error, requested action service DIRECT_DEBITING and =20 fault handling equal to =20 TERMINATE_OR_BUFFER and Tx running=20 PendingE Tx expired, requested Grant PendingE action DIRECT_DEBITING service to end=20 user =20 PendingE Failure to send, requested Store Idle=20 action DIRECT_DEBITING and request with=20 fault handling equal to T-flag =20 TERMINATE_OR_BUFFER = =20 PendingE Temporary error, requested Store Idle=20 action DIRECT_DEBITING and request=20 fault handling equal to =20 TERMINATE_OR_BUFFER and Tx expired PendingE Failed answer or answer Idle received with result code SERVICE DENIED or USER_UNKNOWN,=20 requested action=20 DIRECT_DEBITING and Tx expired =20 =20 PendingE Failed CC event answer Indicate Idle=20 received, requested service =20 action REFUND error and =20 delete request = =20 =20 PendingE Failure to send or Store Idle=20 Tx expired, requested request=20 action REFUND with T-flag =20 PendingE Temporary error Store Idle=20 and requested action request=20 REFUND =20 =20 PendingB Successful CC answer Delete Idle=20 received request=20 =20 PendingB Failed CC answer Delete Idle=20 received request=20 =20 PendingB Failure to send or Idle = =20 temporary error 8) Change the description of the Tx timer in section 10 FROM Tx timer=20 =20 When real-time credit-control is required, the credit-control client = contacts the credit-control server before and during the service is = provided to an end user. Due to real-time nature of application the = communication delays SHOULD be minimized, e.g. to avoid too long service = set up time experienced by the end user. The Tx timer is introduced to = control the waiting time in the client in the PENDING state.=20 =20 The recommended value is 10 seconds. TO Tx timer=20 =20 When real-time credit-control is required, the credit-control client = contacts the credit-control server before and during the service is = provided to an end user. Due to real-time nature of application the = communication delays SHOULD be minimized, e.g. to avoid too long service = set up time experienced by the end user. The Tx timer is introduced to = control the waiting time in the client in the PENDING state. When the Tx = timer elapses the credit-control client takes an action to the end user = according to the value of the Credit-Control-Failure-Handling AVP or = according to the value of the Direct-Debiting-Failure-Handling AVP. =20 The recommended value is 10 seconds. 9) Change the section 5.10 FROM =20 The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type=20 Enumerated. The credit-control client uses information in this AVP to = decide what to do if the sending of credit-control messages to the=20 credit-control server has been for instance temporarily prevented due = to a network problem. =20 =20 TERMINATE 0 =20 =20 When the Credit-Control-Failure-Handling AVP is set to TERMINATE the=20 service MUST only be granted as long as there is a connection to the credit-control server. If the credit-control client does not receive=20 any Credit-Control-Answer message within the Tx timer (as defined in=20 section 10) the credit-control request is regarded failed. The moving of already started credit-control session to alternative server is=20 not allowed. =20 =20 This is the default behavior if the AVP isn't included in the reply=20 from the authorization or credit-control server. =20 =20 CONTINUE 1 =20 =20 When the Credit-Control-Failure-Handling AVP is set to CONTINUE the=20 service SHOULD be granted even if credit-control messages can't be=20 delivered. =20 TO =20 The Credit-Control-Failure-Handling AVP (AVP Code TBD) is of type=20 Enumerated. The credit-control client uses information in this AVP to = decide what to do if the sending of credit-control messages to the=20 credit-control server has been for instance temporarily prevented due = to a network problem. Depending on the service logic, the=20 credit-control server can order the client to terminate the service immediately when there is a reason to believe that the service cannot be charged, or to try failover to an alternative server, if possible, and then either terminate or grant the service should also the alternative connection fail. =20 TERMINATE 0 =20 =20 When the Credit-Control-Failure-Handling AVP is set to TERMINATE the=20 service MUST only be granted as long as there is a connection to the=20 credit-control server. If the credit-control client does not receive=20 any Credit-Control-Answer message within the Tx timer (as defined in=20 section 10) the credit-control request is regarded failed and the end user's service session is terminated. =20 This is the default behavior if the AVP isn't included in the reply=20 from the authorization or credit-control server. =20 =20 CONTINUE 1 =20 =20 When the Credit-Control-Failure-Handling AVP is set to CONTINUE the credit-control client SHOULD re-send the request to an alternative server in case of transport or temporary failures, provided that failover procedure is supported in the credit-control server and the credit-control client, and an alternative server is = available. Otherwise, the service SHOULD be granted even if credit-control messages can't be delivered. RETRY_AND_TERMINATE 2 =20 =20 When the Credit-Control-Failure-Handling AVP is set to RETRY_AND_TERMINATE the credit-control client SHOULD re-send the request to an alternative server in case of transport or temporary failures, provided that failover procedure is supported in the credit-control server and the credit-control client, and an alternative server is available. Otherwise, the service SHOULD not be granted when the credit-control messages can't be delivered. From exim@www1.ietf.org Tue Sep 2 09:40:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24817 for ; Tue, 2 Sep 2003 09:40:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u69k-0007iW-O0 for aaa-archive@odin.ietf.org; Tue, 02 Sep 2003 04:04:52 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8284qLQ029653 for aaa-archive@odin.ietf.org; Tue, 2 Sep 2003 04:04:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u3bJ-0000Rm-B7 for aaa-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 01:21:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04081 for ; Tue, 2 Sep 2003 01:21:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u3bF-0002Qq-00 for aaa-web-archive@ietf.org; Tue, 02 Sep 2003 01:21:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19u3KI-0004RV-00 for aaa-web-archive@ietf.org; Tue, 02 Sep 2003 01:03:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toKP-0007sU-Cn for aaa-web-archive@ietf.org; Mon, 01 Sep 2003 09:02:41 -0400 Date: Mon, 01 Sep 2003 09:02:41 -0400 Message-ID: <20030901130241.21711.24842.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: aaa-web-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, aaa-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for aaa-web-archive@ietf.org: List Password // URL ---- -------- aaa@ietf.org wumate https://www1.ietf.org/mailman/options/aaa/aaa-web-archive%40ietf.org From owner-aaa-wg@merit.edu Tue Sep 2 10:36:23 2003 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 KAA02310 for ; Tue, 2 Sep 2003 10:36:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4E19091266; Tue, 2 Sep 2003 10:35:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14BA291269; Tue, 2 Sep 2003 10:35: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 2D1F291266 for ; Tue, 2 Sep 2003 10:35:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FC5C5DDEA; Tue, 2 Sep 2003 10:35:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 3764D5DDE9 for ; Tue, 2 Sep 2003 10:35:41 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 523956A904; Tue, 2 Sep 2003 17:35:24 +0300 (EEST) Message-ID: <3F54A9FC.4000806@kolumbus.fi> Date: Tue, 02 Sep 2003 17:32:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Diameter/DynAuth RADIUS translation 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: > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: September 1, 2003 > Reference: > Document: nasreq-12 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > > Update the references: Ok. > Update Section 6.1 to include the new Service-Type value: > > 17 Authorize Only [RFC3576] Ok. > Add the following to Section 9.1: ... > Add the following to Section 9.2: The text sounds right. But I wonder if my head hurts because I'm tired, or because a sequence diagram would make the issue easier. The particular piece of text I had trouble with was where STA, ASR, and RADIUS Access Request were mentioned in the same sentence. Which direction are these messages sent? --Jari From owner-aaa-wg@merit.edu Tue Sep 2 10:38:14 2003 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 KAA02542 for ; Tue, 2 Sep 2003 10:38:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F7FB91265; Tue, 2 Sep 2003 10:37:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED6BE91269; Tue, 2 Sep 2003 10:37: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 09B2691265 for ; Tue, 2 Sep 2003 10:37:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE2BC5DDF3; Tue, 2 Sep 2003 10:37:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B1A1F5DDEA for ; Tue, 2 Sep 2003 10:37:56 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F02046A904; Tue, 2 Sep 2003 17:37:55 +0300 (EEST) Message-ID: <3F54AA93.7060701@kolumbus.fi> Date: Tue, 02 Sep 2003 17:34:59 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Route-Record AVP in responses References: <052E0C61B69C3741AFA5FE88ACC775A61222DA@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222DA@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 Auth48 is on for the base spec, so in theory we can still fix things. Assuming the fixes are simple, and don't get us into additional trouble... --Jari From owner-aaa-wg@merit.edu Tue Sep 2 10:46:37 2003 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 KAA02809 for ; Tue, 2 Sep 2003 10:46:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A64239126A; Tue, 2 Sep 2003 10:46:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B3089126B; Tue, 2 Sep 2003 10:46: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 7DF7991269 for ; Tue, 2 Sep 2003 10:45:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6F9015DDB0; Tue, 2 Sep 2003 10:45:25 -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 CC3205DD8E for ; Tue, 2 Sep 2003 10:45:24 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A2B596A904; Tue, 2 Sep 2003 17:45:23 +0300 (EEST) Message-ID: <3F54AC53.201@kolumbus.fi> Date: Tue, 02 Sep 2003 17:42:27 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: david@mitton.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Authentication method AVP? (issue 417) References: <052E0C61B69C3741AFA5FE88ACC775A61222DC@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222DC@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: > David Mitton wrote: > >>Okay, can we elaborate more on the intended semantics? >> >>Is this an informational readout for Accounting as to what auth >>method was actually used? >> >>Which end originates it? (if accounting only, then client Client. The auth method avp is simple. Compare this to the eap auth method avp in diameter eap, which is harder, because the NAS may not know the authentication method... ;-) >>How does this relate to the RADIUS attributes and MS VSAs at a >>protocol gateway? >> >>We have a day to get this in. Technically, we could leave the vendor specific translation to someone else. But that is easy enough as well... RFC 2548, Section 2.7.4, MS-Acct-Auth-Type <=> our new AVP. > Like I said earlier, not delaying NASREQ is more important than > getting this AVP in (and it could be defined somewhere else, > like Diameter EAP, if necessary). I think this is simple enough that we should just put in. I could be wrong, of course... > The AVP would be informational, from the client to the accounting > server. RFC2548 defines the following values for MS-Acct-Auth-Type: > PAP (1), CHAP (2), MS-CHAP-1 (3), MS-CHAP-2 (4), and EAP (5). > I guess we need a new IANA-managed namespace for these; > the initial values could be these for easier translation. > > Proposed text: > > - New section (possibly after 8.6) > > 8.TBD Accounting-Auth-Method AVP > > The Accounting-Auth-Method AVP (AVP Code TBD) is of type > Enumerated. A NAS MAY include this AVP in an Accounting-Request > message to indicate what authentication method was used to > authenticate the user. The following values are defined: > > 1 PAP > 2 CHAP > 3 MS-CHAP-1 > 4 MS-CHAP-2 > 5 EAP > > (BTW, a web page on Microsoft TechNet also shows values NONE (7) and > CUSTOM (8), though it's not clear if these are actually ever used. > Maybe we should include NONE here?) We definately need a NONE. > or > proddocs/datacenter/sag_ias_log2a.asp> > > - The IANA considerations also need updates. Proposed text: > (before 11.1) "This document also creates one new namespace to > be managed by IANA, as described in Section 11.5". > > 11.5 Accounting-Auth-Method AVP Values > > As defined in Section 8.TBD, the Accounting-Auth-Method AVP > (AVP Code TBD) defines the values 1-5. All remaining values are > available for assignment via IETF Consensus [IANA]." Ok. > - Section 9: Should we also mention that this AVP could be > translated to MS-Acct-Auth-Type VSA? On the other hand, > we're not including any translation hints for other VSAs > (though Diameter EAP will mention the possibility of > translating between MS-MPPE-Send/Recv-Key and whatever key AVP > it defines). Given that the reference is non-standard, if we include translation then that translation hint has to be non-normative. Perhaps you could add a paragraph to Section 9 that starts with For example, ... or add this to an appendix. > - Also needs update for this: table in beginning of Section 8, > AVP occurrence tables in Sections 10.2.1 and 10.2.2. Yes. --Jari From owner-aaa-wg@merit.edu Tue Sep 2 12:46:40 2003 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 MAA13685 for ; Tue, 2 Sep 2003 12:46:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8749291272; Tue, 2 Sep 2003 12:46:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 128C391273; Tue, 2 Sep 2003 12:46: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 9410C91272 for ; Tue, 2 Sep 2003 12:45:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81C855DDB7; Tue, 2 Sep 2003 12:45: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 B52D05DDA5 for ; Tue, 2 Sep 2003 12:45:39 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h82GjbB12119 for ; Tue, 2 Sep 2003 19:45:38 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 19:45:37 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 19:45:37 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 19:45:36 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 19:45:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Route-Record AVP in responses Date: Tue, 2 Sep 2003 19:45:35 +0300 Message-ID: Thread-Topic: [AAA-WG]: Route-Record AVP in responses Thread-Index: AcNxX9reO5gasdR7RNSk1LBBIwZ57QAEbu/A From: To: , Cc: X-OriginalArrivalTime: 02 Sep 2003 16:45:36.0304 (UTC) FILETIME=[A2339B00:01C37171] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Yes, and I am waiting on the simple fixes that don't get=20 us into trouble ;) > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 02 September, 2003 17:35 > To: Eronen Pasi (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Route-Record AVP in responses >=20 >=20 > Auth48 is on for the base spec, so in theory we can still > fix things. Assuming the fixes are simple, and don't get > us into additional trouble... >=20 > --Jari >=20 >=20 >=20 >=20 From owner-aaa-wg@merit.edu Tue Sep 2 14:50:51 2003 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 OAA26004 for ; Tue, 2 Sep 2003 14:50:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95DF991275; Tue, 2 Sep 2003 14:50:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F15991273; Tue, 2 Sep 2003 14: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 3440691260 for ; Tue, 2 Sep 2003 14:50:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11FA95DDB0; Tue, 2 Sep 2003 14:50:10 -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 31E5E5DDA5 for ; Tue, 2 Sep 2003 14:50:09 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h82Io7B20323 for ; Tue, 2 Sep 2003 21:50:08 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 2 Sep 2003 21:50:07 +0300 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 21:50:06 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 2 Sep 2003 21:50:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Route-Record AVP in responses Date: Tue, 2 Sep 2003 21:50:06 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A608BBC7@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Route-Record AVP in responses Thread-Index: AcNxX9reO5gasdR7RNSk1LBBIwZ57QAEbu/AAAJsdLA= From: To: , Cc: X-OriginalArrivalTime: 02 Sep 2003 18:50:06.0447 (UTC) FILETIME=[06C0F7F0:01C37183] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John Loughney wrote: > Yes, and I am waiting on the simple fixes that don't get=20 > us into trouble ;) Let's see what changes would be needed... if we stick with the decision in issue 228 (no Route-Record AVPs in responses), Base needs these changes: - In section 2.10, delete the paragraph that starts=20 "Similarly, the local Diameter agent..." - In 10.2 (AVP occurrence table), change "0+" to "0" in cell (Route-Record,ACA). From editing point of view, the changes are small--but might get=20 us into trouble since it removes some functionality... (especially since the deleted paragraph also discusses some security issues). If we decide that responses DO have Route-Records, we need to change the following: - First we have to decide whether the Route-Record AVPs are=20 added to the response one-by-one (as it gets forwarded=20 back to the client), or if the server does it (by copying all the Route-Record AVPs from the request). While the latter was used in e.g. Base-05, IMHO the former seems much less problematic. - The former approach would mean adding a new paragraph to=20 Section 6.2.2 (after the first one): "A proxy or relay agent=20 MUST append a Route-Record AVP to all responses forwarded.=20 The AVP contains the identity of the peer the response was=20 received from." - In 10.1 (AVP occurrence table), change "0" to "0+" in=20 cells Route-Record X (RAA,ASA,STA) - Add "* [ Route-Record ]" to ABNFs (after Proxy-Info)=20 in 8.3.2 (RAA), 8.4.2 (STA), 8.5.2 (ASA) and 9.7.2 (ACA) (Either way, NASREQ needs changes as well. I can try to figure=20 out what they are when we decide which way to go.) Best regards, Pasi From owner-aaa-wg@merit.edu Wed Sep 3 03:07:01 2003 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 DAA09503 for ; Wed, 3 Sep 2003 03:07:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E20B9128C; Wed, 3 Sep 2003 03:06:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB1D291290; Wed, 3 Sep 2003 03:06: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 B72DB9128E for ; Wed, 3 Sep 2003 03:06:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81A595DDC1; Wed, 3 Sep 2003 03:06:01 -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 C08D35DD97 for ; Wed, 3 Sep 2003 03:06:00 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8375w417095 for ; Wed, 3 Sep 2003 10:05:59 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 3 Sep 2003 10:05:58 +0300 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 10:05:57 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Wed, 3 Sep 2003 10:05:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Route-Record AVP in responses Date: Wed, 3 Sep 2003 10:05:56 +0300 Message-ID: Thread-Topic: [AAA-WG]: Route-Record AVP in responses Thread-Index: AcNxX9reO5gasdR7RNSk1LBBIwZ57QAEbu/AAAJsdLAAG5lWsA== From: To: , Cc: X-OriginalArrivalTime: 03 Sep 2003 07:05:56.0864 (UTC) FILETIME=[D273F800:01C371E9] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pasi, These changes sound too big to make within the authors' 48 hour period, so I think we need to file these as a bug for the future. I think the list should discuss what is the best way to solve this. John > -----Original Message----- > From: ext [mailto:Pasi.Eronen@nokia.com] > Sent: 02 September, 2003 21:50 > To: Loughney John (NRC/Helsinki); jari.arkko@kolumbus.fi > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Route-Record AVP in responses >=20 >=20 >=20 > John Loughney wrote: > > Yes, and I am waiting on the simple fixes that don't get=20 > > us into trouble ;) >=20 > Let's see what changes would be needed... if we stick > with the decision in issue 228 (no Route-Record AVPs > in responses), Base needs these changes: >=20 > - In section 2.10, delete the paragraph that starts=20 > "Similarly, the local Diameter agent..." > - In 10.2 (AVP occurrence table), change "0+" to "0" > in cell (Route-Record,ACA). >=20 > From editing point of view, the changes are small--but might get=20 > us into trouble since it removes some functionality... (especially > since the deleted paragraph also discusses some security issues). >=20 > If we decide that responses DO have Route-Records, we > need to change the following: >=20 > - First we have to decide whether the Route-Record AVPs are=20 > added to the response one-by-one (as it gets forwarded=20 > back to the client), or if the server does it (by copying > all the Route-Record AVPs from the request). While the latter > was used in e.g. Base-05, IMHO the former seems much less > problematic. > - The former approach would mean adding a new paragraph to=20 > Section 6.2.2 (after the first one): "A proxy or relay agent=20 > MUST append a Route-Record AVP to all responses forwarded.=20 > The AVP contains the identity of the peer the response was=20 > received from." > - In 10.1 (AVP occurrence table), change "0" to "0+" in=20 > cells Route-Record X (RAA,ASA,STA) > - Add "* [ Route-Record ]" to ABNFs (after Proxy-Info)=20 > in 8.3.2 (RAA), 8.4.2 (STA), 8.5.2 (ASA) and 9.7.2 (ACA) >=20 > (Either way, NASREQ needs changes as well. I can try to figure=20 > out what they are when we decide which way to go.) >=20 > Best regards, > Pasi >=20 From owner-aaa-wg@merit.edu Thu Sep 4 17:04:43 2003 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 RAA22416 for ; Thu, 4 Sep 2003 17:04:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E9D391213; Thu, 4 Sep 2003 17:04:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E496D91220; Thu, 4 Sep 2003 17:04: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 F0C9091213 for ; Thu, 4 Sep 2003 17:04:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D4EAB5DDBD; Thu, 4 Sep 2003 17:04:33 -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 296E05DD8F for ; Thu, 4 Sep 2003 17:04:33 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h84KWdA21671; Thu, 4 Sep 2003 13:32:40 -0700 Date: Thu, 4 Sep 2003 13:32:39 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Diameter/DynAuth RADIUS translation In-Reply-To: <3F54A9FC.4000806@kolumbus.fi> Message-ID: References: <3F54A9FC.4000806@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The text sounds right. But I wonder if my head hurts because > I'm tired, or because a sequence diagram would make the issue > easier. The particular piece of text I had trouble with was > where STA, ASR, and RADIUS Access Request were mentioned in > the same sentence. Which direction are these messages sent? I got a bit lazy and didn't include as much detail in Section 9.2 as in Section 9.1. I'll rework it. From owner-aaa-wg@merit.edu Fri Sep 5 00:18:26 2003 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 AAA18442 for ; Fri, 5 Sep 2003 00:18:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 139839121D; Fri, 5 Sep 2003 00:18:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFE7D9121E; Fri, 5 Sep 2003 00:18: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 8139D9121D for ; Fri, 5 Sep 2003 00:17:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 63A535DD9B; Fri, 5 Sep 2003 00:17:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id B1DA35DDE3 for ; Fri, 5 Sep 2003 00:17:49 -0400 (EDT) Received: (cpmta 21702 invoked from network); 4 Sep 2003 21:17:16 -0700 Received: from 66.30.106.11 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 4 Sep 2003 21:17:16 -0700 X-Sent: 5 Sep 2003 04:17:16 GMT Message-Id: <5.2.1.1.2.20030905001618.03328ce0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 05 Sep 2003 00:17:06 -0400 To: From: David Mitton Subject: Re: [AAA-WG]: AVP type mismatches in NASREQ-12 Cc: In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222C5@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 On 8/12/2003 11:33 AM +0300, Pasi.Eronen@nokia.com wrote: >AVP type mismatches in NASREQ-12 >Submitter name: Pasi Eronen >Submitter email address: pasi.eronen@nokia.com >Date first submitted: August 12, 2003 >Reference: >Document: NASREQ-12 >Comment type: T/E >Priority: 1 >Section: various >Rationale/Explanation of issue: > >When reviewing NASREQ-12, I found a couple of cases where the AVP >type specified doesn't match the description of the corresponding >RADIUS attribute in RFC 2865/2868/etc.: > >These two are obviously editorial mistakes: > >- Framed-IPX-Network should be Unsigned32 instead of UTF8String > (it's not UTF-8 or human-readable, and it's always 4 octets) > >- Tunnel-Client-Auth-Id should be UTF8String instead of Unsigned32 > (it's a string, and RFC2868 says it should be UTF-8) > >These are not that important: > >- Tunnel-Server-Auth-Id should be UTF8String instead of OctetString > (RFC2868 says that it should be UTF-8) > >- Tunnel-Private-Group-Id should be OctetString instead of UTF8String > (RFC2868 says that it can be anything) > >Best regards, >Pasi These are all accepted and corrected. From owner-aaa-wg@merit.edu Fri Sep 5 11:18:00 2003 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 LAA00158 for ; Fri, 5 Sep 2003 11:18:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F0C291234; Fri, 5 Sep 2003 11:16:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F31479124C; Fri, 5 Sep 2003 11:16: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 EAE2A91234 for ; Fri, 5 Sep 2003 11:16:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D759A5DDB8; Fri, 5 Sep 2003 11:16:46 -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 348AD5DD8C for ; Fri, 5 Sep 2003 11:16:46 -0400 (EDT) Received: (cpmta 21472 invoked from network); 5 Sep 2003 08:16:44 -0700 Received: from 66.30.106.11 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.71) with SMTP; 5 Sep 2003 08:16:44 -0700 X-Sent: 5 Sep 2003 15:16:44 GMT Message-Id: <5.2.1.1.2.20030905111131.02e68bd0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 05 Sep 2003 11:12:59 -0400 To: , , From: David Mitton Subject: RE: [AAA-WG]: Route-Record AVP in responses Cc: 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 9/3/2003 10:05 AM +0300, john.loughney@nokia.com wrote: >Hi Pasi, > >These changes sound too big to make within the authors' 48 hour >period, so I think we need to file these as a bug for the future. > >I think the list should discuss what is the best way to solve this. > >John > > > -----Original Message----- > > From: ext [mailto:Pasi.Eronen@nokia.com] > > Sent: 02 September, 2003 21:50 > > To: Loughney John (NRC/Helsinki); jari.arkko@kolumbus.fi > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Route-Record AVP in responses >... > > > > (Either way, NASREQ needs changes as well. I can try to figure > > out what they are when we decide which way to go.) So, should I ignore this for now too? Are there any minor fixups to make? Dave. From owner-aaa-wg@merit.edu Thu Sep 11 22:13:19 2003 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 WAA22373 for ; Thu, 11 Sep 2003 22:13:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D7159124E; Thu, 11 Sep 2003 22:13:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB2C691296; Thu, 11 Sep 2003 22:13: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 A4BBB9124E for ; Thu, 11 Sep 2003 22:13:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F7C95DDC4; Thu, 11 Sep 2003 22:13:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (h-66-167-171-107.STTNWAHO.covad.net [66.167.171.107]) by segue.merit.edu (Postfix) with ESMTP id CA9F65DDB8 for ; Thu, 11 Sep 2003 22:13:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C1eaG12140; Thu, 11 Sep 2003 18:40:37 -0700 Date: Thu, 11 Sep 2003 18:40:36 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Diameter/DynAuth RADIUS translation In-Reply-To: <3F54A9FC.4000806@kolumbus.fi> Message-ID: References: <3F54A9FC.4000806@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The text sounds right. But I wonder if my head hurts because > I'm tired, or because a sequence diagram would make the issue > easier. The particular piece of text I had trouble with was > where STA, ASR, and RADIUS Access Request were mentioned in > the same sentence. Which direction are these messages sent? How does this look? Section 9.2 "If the Diameter/RADIUS gateway supports [RADDynAuth], it may translate a Diameter Re-Authorization-Request (RAR) message to a RADIUS CoA-Request with a Service-Type value of "Authorization Only". It is possible that the NAS receiving this message will not support [RADDynAuth], in which case an ICMP Port Unreachable message will be returned to the Diameter/RADIUS gateway. However, even if the NAS supports [RADDynAuth], it may not support a Service-Type value of "Authorization Only" in a CoA-Request message. In this case it will respond with a CoA-Nak and (optionally) an Error-Cause attribute with value 405," Unsupported Service" and no Service-Type attribute. If a Diameter/RADIUS gateway receives such a packet, or an ICMP port unreachable message, or if it does not support [RADDynAuth], then it SHOULD reply to the AAA server with a Diameter Re-Authorization-Answer (RAA) message with a Result-Code AVP of "DIAMETER_COMMAND_UNSUPPORTED". If in response to a CoA-Request sent to the NAS, the Diameter/RADIUS gateway receives a RADIUS CoA-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated", this is translated to a Diameter Re-Authorization-Answer (RAA) with a Result-Code AVP of "DIAMETER_LIMITED_SUCCESS" sent to the AAA server. Subsequently, the Diameter/RADIUS gateway should receive a RADIUS Access-Request from the NAS, with a Service-Type of "Authorize Only". This is translated to a Diameter AA-Request with an Auth-Request-Type AVP of AUTHORIZE_ONLY, sent to the AAA server. The AAA server will then reply with a Diameter AA-Answer, which is translated to a RADIUS Access-Accept or Access-Reject, depending on the value of the Result-Code AVP. A Diameter/RADIUS gateway supporting [RADDynAuth] may translate a Diameter Session-Termination-Request (STR) message received from the AAA server to a RADIUS Disconnect-Request with a Service-Type value of "Authorization Only", sent to the NAS. It is possible that the NAS receiving this message will not support [RADDynAuth], in which case an ICMP Port Unreachable message will be returned to the Diameter/RADIUS gateway. Even if the NAS supports [RADDynAuth], it may not support a Service-Type value of "Authorization Only" in a Disconnect-Request message. In this case it will respond with a CoA-Nak and (optionally) an Error-Cause attribute with value 405," Unsupported Service" and no Service-Type attribute. If the Diameter/RADIUS gateway encounters these error conditions, or if it does not support [RADDynAuth], it sends a Diameter Re-Authorization-Answer (RAA) message with an Result-Code AVP of "DIAMETER_COMMAND_UNSUPPORTED" to the AAA server. If the NAS does support [RADDynAuth] and a Disconnect-Request message with a Service-Type value of "Authorize Only" it will typically reply with a RADIUS Disconnect-NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". A Diameter/RADIUS gateway supporting [RADDynAuth] translates this to a Diameter Session-Termination-Answer (STA) with a Result-Code AVP of "DIAMETER_LIMITED_SUCCESS", sent to the AAA Server. Subsequently, the Diameter/RADIUS gateway should receive a RADIUS Access-Request from the NAS, with a Service-Type of "Authorize Only". This is translated to a Diameter Abort-Session-Request (ASR), sent to the AAA server. The AAA server will then reply with a Diameter Abort-Session-Answer (ASA), which the Diameter/RADIUS gateway translates to a RADIUS Access-Reject sent to the NAS." From owner-aaa-wg@merit.edu Fri Sep 12 09:21:19 2003 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 JAA20510 for ; Fri, 12 Sep 2003 09:21:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 41CE89129C; Fri, 12 Sep 2003 09:21:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1978F9129D; Fri, 12 Sep 2003 09:21: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 1FD7A9129C for ; Fri, 12 Sep 2003 09:21:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 03BDF5DD96; Fri, 12 Sep 2003 09:21:10 -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 B5A825DD8F for ; Fri, 12 Sep 2003 09:21:09 -0400 (EDT) Received: (cpmta 1312 invoked from network); 12 Sep 2003 06:20:37 -0700 Received: from 216.192.77.7 (HELO djmlap.mitton.com) by smtp.mitton.com (209.228.32.66) with SMTP; 12 Sep 2003 06:20:37 -0700 X-Sent: 12 Sep 2003 13:20:37 GMT Message-Id: <5.2.1.1.2.20030912091834.038020c0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 12 Sep 2003 09:18:40 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Interim NASreq draft 13a Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk I had just pasted together a draft with most of the comments to-date. http://home.comcast.net/~dmitton/draft-ietf-aaa-diameter-nasreq-13a.txt I didn't get Bernard's new 9.2 until just now. This still needs some neaten up work. Dave. From owner-aaa-wg@merit.edu Wed Sep 17 02:21:03 2003 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 CAA18829 for ; Wed, 17 Sep 2003 02:21:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 755AE912F9; Wed, 17 Sep 2003 02:20:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 476DE912FA; Wed, 17 Sep 2003 02:20: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 601F0912F9 for ; Wed, 17 Sep 2003 02:20:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49D765DF61; Wed, 17 Sep 2003 02:20:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id B78E75DF45 for ; Wed, 17 Sep 2003 02:20:46 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by penguin-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8H6Kj31002768 for ; Wed, 17 Sep 2003 08:20:45 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Sep 2003 08:21:02 +0200 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Credit Control: Cost-Information AVP enhancement Date: Wed, 17 Sep 2003 08:20:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Cost-Information AVP enhancement Submitter name: Harri Hakala Submitter email address: harri.hakala@ericsson.com Date first submitted: September 17, 2003 Reference: Document: Diameter CCA-00 Comment type: T Priority: 2 Section: 5.8 Rationale/Explanation of issue: In Diameter CCA-00 the Cost-Information AVP can be used to return accumulated cost for session (always type of money) without taking a credit-reservation into account, that is it specifies how much the service has cost so far. In case of service price enquiry operation (e.g. for Advice Of Charge) the cost should often be returned as a cost rate (e.g. cost for the service is 1$/minutes) instead of money. With the current Cost-Information AVP structure cost per unit cannot be returned. Proposed changed: Section 5.8 Cost-Information AVP FROM: The Cost-Information AVP (AVP Code TBD) is of type Grouped and is used to return the cost information of a service in the Accounting- Answer command. The included Unit-Value AVP contains the cost estimate (always type of money) of the service in case of price enquiry or the accumulated cost estimation in the case of credit control session. The Currency-Code specifies in which currency the cost was given. ...... TO: The Cost-Information AVP (AVP Code TBD) is of type Grouped and is used to return the cost information of a service in the Accounting- Answer command. The included Unit-Value AVP contains the cost estimate (always type of money) of the service in case of price enquiry or the accumulated cost estimation in the case of credit control session. The Currency-Code specifies in which currency the cost was given. The Cost-Unit specifies the unit when the service cost is a cost per unit (e.g. cost for the service is 1$/minute). ..... CHANGE the AVP format in section 5.8 FROM ::=< AVP Header: TBD > { Unit-Value } { Currency-Code } TO ::=< AVP Header: TBD > { Unit-Value } { Currency-Code } [ Cost-Unit ] ADD 5.x Cost-Unit AVP 5.x Cost-Unit AVP The Cost-Unit AVP (AVP Code TBD) is of type UTF8String and specifies the applicable unit to the Cost-Information when the service cost is a cost per unit (e.g. cost of the service is 1$/minute). The Cost-Unit can be for instance minute, hour, day, KBytes, MBytes etc. From owner-aaa-wg@merit.edu Wed Sep 17 02:47:04 2003 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 CAA28779 for ; Wed, 17 Sep 2003 02:47:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1473F912FC; Wed, 17 Sep 2003 02:45:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7FB49130A; Wed, 17 Sep 2003 02:45: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 72E6A912FC for ; Wed, 17 Sep 2003 02:45:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 622E95DDFE; Wed, 17 Sep 2003 02:45:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id A3EE15DDE7 for ; Wed, 17 Sep 2003 02:45:47 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by albatross-ext.wise.edt.ericsson.se (8.12.9/8.12.9/WIREfire-1.7) with ESMTP id h8H6jkAv025516 for ; Wed, 17 Sep 2003 08:45:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 17 Sep 2003 08:46:03 +0200 Message-ID: From: "Harri Hakala (TU/LMF)" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Credit Control: Cost-Information AVP enhan cement Date: Wed, 17 Sep 2003 08:45:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, There is an editorial mistake in the text below, the command should be Credit-Control- Answer and not Accounting-Answer. Regards...........Harri > -----Original Message----- > From: Harri Hakala (TU/LMF) > Sent: 17. syyskuuta 2003 9:21 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter Credit Control: Cost-Information AVP > enhancement > > > Cost-Information AVP enhancement > Submitter name: Harri Hakala > Submitter email address: harri.hakala@ericsson.com > Date first submitted: September 17, 2003 > Reference: > Document: Diameter CCA-00 > Comment type: T > Priority: 2 > Section: 5.8 > Rationale/Explanation of issue: > > In Diameter CCA-00 the Cost-Information AVP can be used to return > accumulated cost for session (always type of money) without taking > a credit-reservation into account, that is it specifies how much > the service has cost so far. > > In case of service price enquiry operation (e.g. for Advice > Of Charge) the > cost should often be returned as a cost rate (e.g. cost for > the service is > 1$/minutes) instead of money. With the current > Cost-Information AVP structure > cost per unit cannot be returned. > > Proposed changed: > > Section 5.8 Cost-Information AVP > > FROM: > > The Cost-Information AVP (AVP Code TBD) is of type Grouped and is > used to return the cost information of a service in the Accounting- > Answer command. The included Unit-Value AVP contains the cost > estimate (always type of money) of the service in case of price > enquiry or the accumulated cost estimation in the case of credit > control session. > > The Currency-Code specifies in which currency the cost was given. > ...... > > TO: > The Cost-Information AVP (AVP Code TBD) is of type Grouped and is > used to return the cost information of a service in the Accounting- > Answer command. The included Unit-Value AVP contains the cost > estimate (always type of money) of the service in case of price > enquiry or the accumulated cost estimation in the case of credit > control session. > > The Currency-Code specifies in which currency the cost was given. > The Cost-Unit specifies the unit when the service cost is a > cost per unit (e.g. cost for the service is 1$/minute). > ..... > > CHANGE the AVP format in section 5.8 > > FROM > > ::=< AVP Header: TBD > > { Unit-Value } > { Currency-Code } > TO > > ::=< AVP Header: TBD > > { Unit-Value } > { Currency-Code } > [ Cost-Unit ] > > ADD 5.x Cost-Unit AVP > > 5.x Cost-Unit AVP > The Cost-Unit AVP (AVP Code TBD) is of type UTF8String > and specifies the applicable unit to the Cost-Information > when the service cost is a cost per unit (e.g. cost of > the service is 1$/minute). The Cost-Unit can be for > instance minute, hour, day, KBytes, MBytes etc. > From exim@www1.ietf.org Fri Sep 19 21:37:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01125 for ; Fri, 19 Sep 2003 21:37:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhBj020140 for ; Fri, 19 Sep 2003 21:36:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QK7D7Y020682 for aaa-archive@odin.ietf.org; Tue, 26 Aug 2003 16:07:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk5x-0005NQ-3C for aaa-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 16:07:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03896 for ; Tue, 26 Aug 2003 16:07:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rk5v-0000bd-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 16:07:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rk5u-0000bZ-00 for aaa-web-archive@ietf.org; Tue, 26 Aug 2003 16:07:10 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk5q-0005LP-Om; Tue, 26 Aug 2003 16:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rk4F-00059t-E6 for aaa@optimus.ietf.org; Tue, 26 Aug 2003 16:05:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03600 for ; Tue, 26 Aug 2003 16:05:22 -0400 (EDT) From: p.eo@spray.se Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rk4D-0000Wb-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:05:25 -0400 Received: from h114n1fls31o986.telia.com ([213.65.136.114] helo=RKC-RUMNR1) by ietf-mx with esmtp (Exim 4.12) id 19rk48-0000WQ-00 for Aaa@ietf.org; Tue, 26 Aug 2003 16:05:21 -0400 To: Date: Tue, 26 Aug 2003 22:02:45 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0815BF40" Message-Id: Subject: [Aaa] Re: Your application Sender: aaa-admin@ietf.org Errors-To: aaa-admin@ietf.org X-BeenThere: aaa@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Authentication, Authorization and Accounting List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0815BF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0815BF40 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: thank_you.pif, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0815BF40-- _______________________________________________ Aaa mailing list Aaa@ietf.org https://www1.ietf.org/mailman/listinfo/aaa From owner-aaa-wg@merit.edu Wed Sep 24 07:10:24 2003 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 HAA06900 for ; Wed, 24 Sep 2003 07:10:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7521891384; Wed, 24 Sep 2003 07:08:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C88CC91370; Wed, 24 Sep 2003 07: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 3066D91384 for ; Wed, 24 Sep 2003 07:08:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 17E095DE30; Wed, 24 Sep 2003 07:08:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from phoebe.eim.surrey.ac.uk (phoebe.eim.surrey.ac.uk [131.227.74.4]) by segue.merit.edu (Postfix) with ESMTP id 9E1005DE6B for ; Wed, 24 Sep 2003 07:07:59 -0400 (EDT) Received: from ccsrmclt03.ee.surrey.ac.uk ([131.227.86.163] helo=eim.surrey.ac.uk ident=ees2mg) by phoebe.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 1A27Qm-0002Y1-00; Wed, 24 Sep 2003 12:03:36 +0100 Message-ID: <3F717A05.A631407C@eim.surrey.ac.uk> Date: Wed, 24 Sep 2003 12:03:33 +0100 From: Michael Georgiades Organization: University of Surrey X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-17.7.x i686) X-Accept-Language: en, el MIME-Version: 1.0 To: Michael Georgiades Cc: Christos Politis Subject: [AAA-WG]: IST EVOLUTE International Workshop Content-Type: multipart/alternative; boundary="------------BE99B377F09C8F3F3A7F744D" X-Spam-Status: No, hits=0.6 required=5.5 tests=BAYES_30,HTML_20_30,USER_AGENT_MOZILLA_XM version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-Scanner: exiscan *1A27Qm-0002Y1-00*xyz3WIC5iiw* (SECM, UniS) Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------BE99B377F09C8F3F3A7F744D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ** Our apologies if you receive multiple copies of this CfP ** --------------------------------------------------------------------------------- IST EVOLUTE International Workshop Univeristy of Surrey, UK Guildford, Nov. 10, 2003 http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ --------------------------------------------------------------------------------- <<<<< CALL FOR SUBMISSIONS >>>> The International Workshop on Beyond 3G Evolution of Systems and Services is an event within the framework of the IST-2001-32449 EVOLUTE project, which is partly funded by the EU. The EVOLUTE Workshop, will take place on November 10th, 2003 in Guildford, UK. The Workshop will be hosted by the University of Surrey. The EVOLUTE Workshop will be structured along four tracks: Mobility Management for All-IP Network Infrastructures AAA and Multimedia Services for Next Generation Networks Business Models and Scenarios Testbeds and prototypes For more and detailed information on this Workshop, please visit the website at: http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ Thank you for your time in advance and welcome to Guildford! Sincerely, Organising Committee of IST EVOLUTE International Workshop CCSR, University of Surrey, UK http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/ --------------BE99B377F09C8F3F3A7F744D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
** Our apologies if you receive multiple copies of this CfP **

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

              IST EVOLUTE International Workshop
                        Univeristy of Surrey, UK
                        Guildford, Nov. 10, 2003
   http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/
---------------------------------------------------------------------------------

<<<<< CALL FOR SUBMISSIONS >>>>

The International Workshop on Beyond 3G Evolution of Systems and
Services is an event within the framework of the IST-2001-32449 EVOLUTE
project, which is partly funded by the EU. The EVOLUTE Workshop, will
take place on November 10th, 2003 in Guildford, UK.
The Workshop will be hosted by the University of Surrey.

The EVOLUTE Workshop will be structured along four tracks:

     Mobility Management for All-IP Network Infrastructures
     AAA and Multimedia Services for Next Generation Networks
     Business Models and Scenarios
     Testbeds and prototypes

For more and detailed information on this Workshop,
please visit the website at:
http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/

Thank you for your time in advance and welcome to Guildford!

Sincerely,

Organising Committee of IST EVOLUTE International Workshop
CCSR, University of Surrey, UK
http://www.ee.surrey.ac.uk/CCSR/IST/Evolute/Workshop/
  --------------BE99B377F09C8F3F3A7F744D-- From owner-aaa-wg@merit.edu Fri Sep 26 00:33:19 2003 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 AAA07495 for ; Fri, 26 Sep 2003 00:33:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6287191227; Fri, 26 Sep 2003 00:33:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3891791229; Fri, 26 Sep 2003 00:33: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 4296291227 for ; Fri, 26 Sep 2003 00:33:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E89D5DDFE; Fri, 26 Sep 2003 00:33:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id 8A5895DE26 for ; Fri, 26 Sep 2003 00:33:11 -0400 (EDT) Received: (cpmta 22234 invoked from network); 25 Sep 2003 21:33:10 -0700 Received: from 66.30.125.93 (HELO h000094929690.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 25 Sep 2003 21:33:10 -0700 X-Sent: 26 Sep 2003 04:33:10 GMT Message-Id: <5.2.1.1.2.20030926002611.034abec0@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Fri, 26 Sep 2003 00:32:51 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Interim NASreq draft 13b In-Reply-To: <5.2.1.1.2.20030912091834.038020c0@getmail.mitton.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Updated draft with Bernard's new 9.2. http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-13b.txt May still needs some neaten up work. I think I will add some sub-heads in section 9.1 & 9.2 Could those that commented please check to see it's acceptable. Thanks, Also, I'd like some input on what to do with Issue #424 Dave. From owner-aaa-wg@merit.edu Sat Sep 27 13:13:32 2003 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 NAA06549 for ; Sat, 27 Sep 2003 13:13:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B33D691288; Sat, 27 Sep 2003 13:13:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 88E0391289; Sat, 27 Sep 2003 13:13: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 9F79A91288 for ; Sat, 27 Sep 2003 13:13:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D33E5DF73; Sat, 27 Sep 2003 13:13: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 536B25DDB1 for ; Sat, 27 Sep 2003 13:13:22 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RGdKQ17304 for ; Sat, 27 Sep 2003 09:39:22 -0700 Date: Sat, 27 Sep 2003 09:39:20 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Plan for Diameter NASREQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The strawman -13 draft of Diameter NASREQ has been posted here: http://www.circularnetworks.com/draft-ietf-aaa-diameter-nasreq-13b.txt By default, unless comments from the WG indicate otherwise, the strawman will be submitted to the IETF archive very soon, and we will ask the IESG to consider NASREQ-13 as an IETF Proposed Standard. Since Diameter Base has been published as an RFC, changes to NASREQ which require corresponding changes to the Diameter Base document cannot be considered. From owner-aaa-wg@merit.edu Sat Sep 27 13:36:01 2003 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 NAA07025 for ; Sat, 27 Sep 2003 13:36:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76B2691289; Sat, 27 Sep 2003 13:35:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A5CB9128A; Sat, 27 Sep 2003 13:35: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 56C0591289 for ; Sat, 27 Sep 2003 13:35:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 444EA5DF2E; Sat, 27 Sep 2003 13:35:53 -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 C36705DEA5 for ; Sat, 27 Sep 2003 13:35:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8RH1wd18689 for ; Sat, 27 Sep 2003 10:01:58 -0700 Date: Sat, 27 Sep 2003 10:01:58 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk After looking at this, my conclusion is that Record-Route AVPs can be included either in requests or responses and that the lack of occurrence in the AVP tables in Diameter Base was a typo. I think this because the text in Base 2.10 seems to assume that Record-Route AVPs are in responses, and because they are allowed in Accounting-Responses. Based on this, it would appear that the issue is an inconsistency in Diameter Base, and that the NASREQ text assume Record-Route in responses is correct. Anyone else have an opinion in this? From owner-aaa-wg@merit.edu Sun Sep 28 02:20:52 2003 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 CAA09151 for ; Sun, 28 Sep 2003 02:20:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1886091299; Sun, 28 Sep 2003 02:19:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1F58912C2; Sun, 28 Sep 2003 02:18: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 D88B591299 for ; Sun, 28 Sep 2003 02:18:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3D2A5DDAE; Sun, 28 Sep 2003 02:18:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ran.psg.com (ip166.usw12.rb1.bel.nwlink.com [209.20.253.166]) by segue.merit.edu (Postfix) with ESMTP id 74A3A5DDA4 for ; Sun, 28 Sep 2003 02:18:54 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=ran.psg.com) by ran.psg.com with esmtp (Exim 4.22) id 1A3UtM-000AmK-CV for aaa-wg@merit.edu; Sat, 27 Sep 2003 23:18:48 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 27 Sep 2003 23:18:47 -0700 To: aaa wg Subject: [AAA-WG]: chair addition Message-Id: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit as we are in end game, to help get things finished and to lighten bernard's load a bit, john loughney has agreed to be a third co-chair for aaa. thanks, john! we're on the home stretch. as far as i understand, the tasks are o credit control, which is said to be under control o nasreq, which dave mitton has almost out the door o eap is said to be moving along well o cms, which seems to be dead, and o mipv4, which has 3gpp2 authors and 3gpp2 are the only folk who care. so if it doesn't finish, no sking off anyone else. so, please give john, bernard, and dave a hand and let's get this stuff out the door. randy From owner-aaa-wg@merit.edu Sun Sep 28 02:34:12 2003 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 CAA09481 for ; Sun, 28 Sep 2003 02:34:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECF089129A; Sun, 28 Sep 2003 02:34:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B86E8912A2; Sun, 28 Sep 2003 02:34: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 A87579129A for ; Sun, 28 Sep 2003 02:34:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D5AF5DD94; Sun, 28 Sep 2003 02:34:03 -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 67BB75DD91 for ; Sun, 28 Sep 2003 02:34:02 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8S6Y1614176 for ; Sun, 28 Sep 2003 09:34:01 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 28 Sep 2003 09:33:59 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 28 Sep 2003 09:34:01 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Sun, 28 Sep 2003 09:34:00 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Sun, 28 Sep 2003 09:33:59 +0300 Message-ID: Thread-Topic: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses Thread-Index: AcOFHdsOnD90eZhLTfatpmshAI+oAAAbHwww From: To: , X-OriginalArrivalTime: 28 Sep 2003 06:34:00.0541 (UTC) FILETIME=[809008D0:01C3858A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard, > After looking at this, my conclusion is that Record-Route AVPs can be > included either in requests or responses and that the lack of = occurrence > in the AVP tables in Diameter Base was a typo. I think this because = the > text in Base 2.10 seems to assume that Record-Route AVPs are in = responses, > and because they are allowed in Accounting-Responses. >=20 > Based on this, it would appear that the issue is an inconsistency in > Diameter Base, and that the NASREQ text assume Record-Route in = responses > is correct. >=20 > Anyone else have an opinion in this? I concur. The text about the Record-Route AVPs was written before my time (I think); I assume it was meant that these AVPs are assumed to be in responses. John=20 From owner-aaa-wg@merit.edu Mon Sep 29 06:32:36 2003 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 GAA03566 for ; Mon, 29 Sep 2003 06:32:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E18E5912D7; Mon, 29 Sep 2003 06:32:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3849912D8; Mon, 29 Sep 2003 06:32:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7943A912D7 for ; Mon, 29 Sep 2003 06:32:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 619765DDC7; Mon, 29 Sep 2003 06:32:30 -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 A4C965DD9E for ; Mon, 29 Sep 2003 06:32:29 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TAWSt02908 for ; Mon, 29 Sep 2003 13:32:28 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 13:32:24 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:32:24 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:32:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:32:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Small NASREQ nit Date: Mon, 29 Sep 2003 13:32:23 +0300 Message-ID: Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9A From: To: X-OriginalArrivalTime: 29 Sep 2003 10:32:23.0545 (UTC) FILETIME=[F83AFE90:01C38674] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Section 4.8: The Originating-Line-Info AVP (AVP Code 94 is of type OctetString and There should be a ')' after 94. John From owner-aaa-wg@merit.edu Mon Sep 29 06:34:48 2003 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 GAA03699 for ; Mon, 29 Sep 2003 06:34:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69113912D8; Mon, 29 Sep 2003 06:34:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3263A912D9; Mon, 29 Sep 2003 06:34: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 145B3912D8 for ; Mon, 29 Sep 2003 06:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01DA35DDFB; Mon, 29 Sep 2003 06:34:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 571275DDE3 for ; Mon, 29 Sep 2003 06:34:43 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TAYgt05359 for ; Mon, 29 Sep 2003 13:34:42 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 13:34:42 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:34:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:34:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Another NASREQ nit Date: Mon, 29 Sep 2003 13:34:37 +0300 Message-ID: Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9AAAAUdHA= From: To: , X-OriginalArrivalTime: 29 Sep 2003 10:34:38.0096 (UTC) FILETIME=[486DD900:01C38675] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi, Section 4.10: 4.10. Termination-Action AVP The Termination-Action AVP is of type Enumerated and indicates what action the NAS should take when the specified service is completed. This AVP SHOULD only be present in authorization responses. The following values are supported as listed in [RADIUSTypes]: -> Missing AVP code. John From owner-aaa-wg@merit.edu Mon Sep 29 07:02:17 2003 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 HAA04387 for ; Mon, 29 Sep 2003 07:02:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD6BE912D9; Mon, 29 Sep 2003 07:02:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0BE02912DA; Mon, 29 Sep 2003 07:02: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 B00B3912D9 for ; Mon, 29 Sep 2003 07:02:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96BD85DDDB; Mon, 29 Sep 2003 07:02:01 -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 E40395DDD5 for ; Mon, 29 Sep 2003 07:02:00 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TB20t07455 for ; Mon, 29 Sep 2003 14:02:00 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 14:02:00 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 14:01:59 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:57:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Conflict between NASREQ & EAP AVP values Date: Mon, 29 Sep 2003 13:55:30 +0300 Message-ID: Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9AAAAUdHAAALTMcA== From: To: X-OriginalArrivalTime: 29 Sep 2003 10:57:54.0610 (UTC) FILETIME=[88D0F920:01C38678] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, It seems that NASREQ & EAP have allocated the same AVP codes: NASREQ: Tunneling 401 CHAP-Auth 402 EAP:=09 Accounting-EAP-Auth-Method AVP AVP Code 401=20 EAP-Payload AVP AVP Code 402 My suggestion is that NASREQ keeps those values, and EAP marks its AVPs as TBD. John From owner-aaa-wg@merit.edu Mon Sep 29 07:02:59 2003 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 HAA04407 for ; Mon, 29 Sep 2003 07:02:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64BA3912FB; Mon, 29 Sep 2003 07:02:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 61706912DB; Mon, 29 Sep 2003 07: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 70F10912FB for ; Mon, 29 Sep 2003 07:02:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 528CE5DDEC; Mon, 29 Sep 2003 07:02:35 -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 A858F5DDD5 for ; Mon, 29 Sep 2003 07:02:34 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TB2Xt08259 for ; Mon, 29 Sep 2003 14:02:33 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 14:02:33 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 14:02:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 13:58:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Mobile IP command code conflicts Date: Mon, 29 Sep 2003 13:57:56 +0300 Message-ID: Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9AAAAUdHAAAMqikA== From: To: X-OriginalArrivalTime: 29 Sep 2003 10:58:05.0922 (UTC) FILETIME=[8F8F0C20:01C38678] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi all, It seems that Diameter base (RFC 3588) has allocated these values: 260 Vendor-Specific-Application-Id [RFC3588] 262 Redirect-Max-Cache-Time [RFC3588] while the current MIPv4 has allocated: Command-Name Abbreviation Code Section ----------------------------------------------------------- AA-Mobile-Node-Answer AMA 260 2.2 AA-Mobile-Node-Request AMR 260 2.1 Home-Agent-MIP-Answer HAA 262 2.4 Home-Agent-MIP-Request HAR 262 2.3 Suggest resolution, mark MIPv4 commands as TBD until MIPv4 is ready=20 for WG last call. John From owner-aaa-wg@merit.edu Mon Sep 29 07:03:26 2003 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 HAA04423 for ; Mon, 29 Sep 2003 07:03:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7633912F9; Mon, 29 Sep 2003 07:03:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0016C912F2; Mon, 29 Sep 2003 07: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 72958912E5 for ; Mon, 29 Sep 2003 07:02:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 508F75DDFB; Mon, 29 Sep 2003 07:02:51 -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 A6CD15DDEC for ; Mon, 29 Sep 2003 07:02:50 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TB2nt08535 for ; Mon, 29 Sep 2003 14:02:49 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 14:02:49 +0300 Received: from esebe007.NOE.Nokia.com ([172.21.138.47]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 14:02:48 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe007.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 14:02:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: RE: Mobile IP command code conflicts Date: Mon, 29 Sep 2003 13:58:53 +0300 Message-ID: Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9AAAAUdHAAAMqikAAAElhA From: To: X-OriginalArrivalTime: 29 Sep 2003 11:02:35.0852 (UTC) FILETIME=[307318C0:01C38679] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Ignore this mail, I looked at Diameter BASE AVPs, not command codes.=20 Mobile IPv4 should stay the same. sorry, John > -----Original Message----- > From: Loughney John (NRC/Helsinki)=20 > Sent: 29 September, 2003 13:58 > To: aaa-wg@merit.edu > Subject: Mobile IP command code conflicts >=20 >=20 > Hi all, >=20 > It seems that Diameter base (RFC 3588) has allocated these values: >=20 > 260 Vendor-Specific-Application-Id [RFC3588] > 262 Redirect-Max-Cache-Time [RFC3588] >=20 > while the current MIPv4 has allocated: >=20 > Command-Name Abbreviation Code Section > ----------------------------------------------------------- > AA-Mobile-Node-Answer AMA 260 2.2 > AA-Mobile-Node-Request AMR 260 2.1 > Home-Agent-MIP-Answer HAA 262 2.4 > Home-Agent-MIP-Request HAR 262 2.3 >=20 > Suggest resolution, mark MIPv4 commands as TBD until MIPv4 is ready=20 > for WG last call. >=20 > John >=20 From owner-aaa-wg@merit.edu Mon Sep 29 08:41:55 2003 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 IAA07221 for ; Mon, 29 Sep 2003 08:41:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E881791214; Mon, 29 Sep 2003 08:41:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B85F2912DA; Mon, 29 Sep 2003 08:41: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 7558D91214 for ; Mon, 29 Sep 2003 08:41:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 618255DE02; Mon, 29 Sep 2003 08:41:47 -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 A8DB45DDFB for ; Mon, 29 Sep 2003 08:41:46 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TCfjt11163 for ; Mon, 29 Sep 2003 15:41:45 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 29 Sep 2003 15:41:44 +0300 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 15:41:42 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 15:41:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Conflict between NASREQ & EAP AVP values Date: Mon, 29 Sep 2003 15:41:41 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3822@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: chair addition Thread-Index: AcOFiK262QvnZdKeRS+y1jUYKzp2twA7Cf9AAAAUdHAAALTMcAADtmSQ From: To: , X-OriginalArrivalTime: 29 Sep 2003 12:41:41.0842 (UTC) FILETIME=[08892B20:01C38687] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable John Loughney wrote: >=20 > Hi all, >=20 > It seems that NASREQ & EAP have allocated the same AVP codes: >=20 > NASREQ: > Tunneling 401 > CHAP-Auth 402 >=20 > EAP:=09 > Accounting-EAP-Auth-Method AVP AVP Code 401=20 > EAP-Payload AVP AVP Code 402 >=20 > My suggestion is that NASREQ keeps those values, and EAP=20 > marks its AVPs as TBD. I agree (EAP has other AVPs with TBD codes, so it's=20 no problem). Cheers, Pasi From owner-aaa-wg@merit.edu Mon Sep 29 09:01:52 2003 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 JAA08889 for ; Mon, 29 Sep 2003 09:01:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18B84912DA; Mon, 29 Sep 2003 09:01:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2B77912DB; Mon, 29 Sep 2003 09:01: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 2AB44912DA for ; Mon, 29 Sep 2003 09:01:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB06D5DDFC; Mon, 29 Sep 2003 09:01:25 -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 11C2C5DDEC for ; Mon, 29 Sep 2003 09:01:25 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8TD1Ot06031 for ; Mon, 29 Sep 2003 16:01:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 29 Sep 2003 16:01:23 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 16:01:22 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 29 Sep 2003 16:01:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Re: Issue 424: Record-Route AVP in Responses Date: Mon, 29 Sep 2003 16:01:21 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A61222FA@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses Thread-Index: AcOFHdrSS/MkzfwcQ7ejgQdJka+mCwBadXsQ From: To: , X-OriginalArrivalTime: 29 Sep 2003 13:01:21.0844 (UTC) FILETIME=[C7DF2F40:01C38689] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: >=20 > After looking at this, my conclusion is that Record-Route AVPs > can be included either in requests or responses and that the > lack of occurrence in the AVP tables in Diameter Base was a > typo. I think this because the text in Base 2.10 seems to > assume that Record-Route AVPs are in responses, and because > they are allowed in Accounting-Responses. >=20 > Based on this, it would appear that the issue is an > inconsistency in Diameter Base, and that the NASREQ text > assume Record-Route in responses is correct. >=20 > Anyone else have an opinion in this? Yes, I guess we could allow Route-Record AVPs in responses well. However, we still need to clarify how they get there... what would be the best way to get this specified? Having NASREQ update RFC3588? A new RFC that updates RFC3588? BTW, the current text in NASREQ isn't consistent with what IMHO would be the most logical way to add the Route-Records (proxies add them to responses one by one). But there isn't any clearly specified alternative it would be consistent with either... Best regards, Pasi From owner-aaa-wg@merit.edu Mon Sep 29 10:17:21 2003 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 KAA17298 for ; Mon, 29 Sep 2003 10:17:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F22D9121D; Mon, 29 Sep 2003 10:17:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A081291220; Mon, 29 Sep 2003 10:17: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 BFAE89121D for ; Mon, 29 Sep 2003 10:16:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9407A5DDD5; Mon, 29 Sep 2003 10:16: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 DC36C5DDE1 for ; Mon, 29 Sep 2003 10:16:57 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8TDgn731810; Mon, 29 Sep 2003 06:42:50 -0700 Date: Mon, 29 Sep 2003 06:42:49 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A61222FA@esebe023.ntc.nokia.com> Message-ID: References: <052E0C61B69C3741AFA5FE88ACC775A61222FA@esebe023.ntc.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Yes, I guess we could allow Route-Record AVPs in responses well. > However, we still need to clarify how they get there... what > would be the best way to get this specified? Having NASREQ > update RFC3588? A new RFC that updates RFC3588? We could submit an errata for RFC 3588, since it is RFC 3588 that is internally inconsistent. Then we could clarify how they get there in NASREQ. > BTW, the current text in NASREQ isn't consistent with what IMHO > would be the most logical way to add the Route-Records (proxies > add them to responses one by one). But there isn't any clearly > specified alternative it would be consistent with either... Could you suggest new text? From owner-aaa-wg@merit.edu Tue Sep 30 03:12:03 2003 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 DAA10416 for ; Tue, 30 Sep 2003 03:12:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 25A2B9122F; Tue, 30 Sep 2003 03:11:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D766291232; Tue, 30 Sep 2003 03:11: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 4D4979122F for ; Tue, 30 Sep 2003 03:11:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 240425DDAD; Tue, 30 Sep 2003 03:11: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 B25F65DDD9 for ; Tue, 30 Sep 2003 03:11:36 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U7BX623744 for ; Tue, 30 Sep 2003 10:11:34 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 30 Sep 2003 10:11:33 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 10:11:33 +0300 Received: from esebe020.NOE.Nokia.com ([172.21.138.59]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 10:11:33 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe020.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 10:03:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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]: Re: Issue 424: Record-Route AVP in Responses Date: Tue, 30 Sep 2003 10:03:47 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C3828@esebe023.ntc.nokia.com> Thread-Topic: [AAA-WG]: Re: Issue 424: Record-Route AVP in Responses Thread-Index: AcOGlGbg6E3Nz/iuQfmVxnGogKXJ+wAjBnVQ From: To: , X-OriginalArrivalTime: 30 Sep 2003 07:03:47.0917 (UTC) FILETIME=[FEBF77D0:01C38720] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Bernard Aboba wrote: > > Yes, I guess we could allow Route-Record AVPs in responses well. > > However, we still need to clarify how they get there... what > > would be the best way to get this specified? Having NASREQ > > update RFC3588? A new RFC that updates RFC3588? >=20 > We could submit an errata for RFC 3588, since it is RFC 3588 that is > internally inconsistent. Then we could clarify how they get there in > NASREQ. >=20 > > BTW, the current text in NASREQ isn't consistent with what IMHO > > would be the most logical way to add the Route-Records (proxies > > add them to responses one by one). But there isn't any clearly > > specified alternative it would be consistent with either... >=20 > Could you suggest new text? Ok, here's a first attempt (I'd appreciate if somebody else could also check that these make sense and don't create more inconsistencies :-) Errata for RFC3588: o Section 6.2.2: add the following text after the first paragraph: "A proxy or relay agent MUST append a Route-Record AVP to all=20 responses forwarded. The AVP contains the identity of the peer=20 the response was received from." o Section 10.1: Update the AVP occurrence table to specify that RAA/ASA/STA messages can have zero or more Route-Record AVPs. Updates for NASREQ -13b: o Section 9.2: Remove the following list item: "4. Route-Record AVPs (in the proper order)" o Section 9.2: Remove the following bullet: "The Route-Record AVPs MUST be added to the Diameter message, in the same order they were present in the request. The gateway's position in the forwarding should be properly recorded." o Section 9.2: Replace the bullet=20 "The response's Origin-Host information is created from the=20 FQDN of the source IP address of the RADIUS message." with "The response's Origin-Host information is created from the FQDN of the source IP address of the RADIUS message. The same FQDN is also stored to a Route-Record AVP." o Section 10.1: Update AVP occurrence table to specify that AAA message can have zero or more Route-Record AVPs. A couple of related editorials/typos: o Section 9.3.3: Replace "...lookup on the source address and NAS-IP-Address attributes..."=20 with=20 "...lookup on the source address and NAS-IPv6-Address attribute..." o Section 9.3.3: Add to end of last paragraph =20 "...other action is taken." (seems this was chopped off at some point) (BTW, while figuring out these changes, I found a couple of other inconsistencies in the RADIUS-Diameter translation. I'll post these in a separate message.) Best regards, Pasi From owner-aaa-wg@merit.edu Tue Sep 30 04:25:06 2003 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 EAA12055 for ; Tue, 30 Sep 2003 04:25:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ED03B9120C; Tue, 30 Sep 2003 04:24:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4D8B91232; Tue, 30 Sep 2003 04:24: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 575759120C for ; Tue, 30 Sep 2003 04:24:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 41C325DE11; Tue, 30 Sep 2003 04:24:57 -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 15B7E5DDCD for ; Tue, 30 Sep 2003 04:24:56 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.6) with ESMTP id h8U8Ott27925 for ; Tue, 30 Sep 2003 11:24:55 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 30 Sep 2003 11:24:54 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 11:24:54 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 11:24:54 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 30 Sep 2003 11:24:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.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: [AAA-WG]: Identities in RADIUS translation Date: Tue, 30 Sep 2003 11:24:53 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A6010C382A@esebe023.ntc.nokia.com> Thread-Topic: Identities in RADIUS translation Thread-Index: AcOHLFMUniW1QM1JQWuF/++dEfaSaQ== From: To: X-OriginalArrivalTime: 30 Sep 2003 08:24:54.0330 (UTC) FILETIME=[535B29A0:01C3872C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: quoted-printable Identities in RADIUS translation Submitter name: Pasi Eronen Submitter email address: pasi.eronen@nokia.com Date first submitted: September 30, 2003 Reference:=20 Document: NASREQ 13b Comment type: T Priority: 1 Section: 9.1-9.3 Rationale/Explanation of issue: While digging the Route-Record issue, I found several possible problems in RADIUS translation (NASREQ -13b), related to handling of Origin-Host/Realm and Destination-Host/Real AVPs... 1. Section 9.1 says that: "If the Diameter Command-Code is set to AA-Answer and the Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the gateway must send a RADIUS Access-Challenge with the Diameter Session-Id and the Origin-Host AVPs encapsulated in the RADIUS State attribute, with the prefix "Diameter/". This is necessary in order to ensure that the Translation Agent that will receive the subsequent RADIUS Access-Request will have access to the Session Identifier, and be able to set the Destination-Host to the correct value.=20 Since both Session-Id and Origin-Host are placed into a single State attribute (only one is allowed), they probably need to be separated somehow. Can we assume that Origin-Host=20 doesn't contain any "/" characters? (likely to be true, although in theory FQDN can contain just about anything) (A minor note: since only one State attribute is allowed in RADIUS, this breaks if the AA-Answer already contains a State AVP. But since the State AVP should be used only by translation agents, this should occur only if we=20 have multiple translation steps.) 2. The State attribute above stores the value needed for=20 Destination-Host, but what about Destination-Realm? Currently it's taken from the User-Name attribute... and if the=20 Origin-Realm in AA-Answer is always guaranteed to be the same=20 as the Destination-Realm in AA-Request, then it should work. But is this guaranteed?=20 (If it isn't, maybe we need to store the realm in State attribute as well?) 3. Earlier Section 9.1 also says that "If the RADIUS request contained a State attribute, and the prefix of the data is "Diameter/", the data following the prefix contains the Diameter Session-Id. If no such attributes are present, and the RADIUS command is an Access-Request, a new Session-Id is created. The Session-Id is included in the Session-Id AVP. This isn't in sync with the text above... the State attribute can also contain the value for Destination-Host. 4. Also in Section 9.1: "The Diameter Origin-Host and Origin-Realm AVPs MUST be created and added using the information from an FQDN corresponding to the NAS-IP-Address attribute (preferred if available), and/or the NAS-Identifier attribute. (Note that the RADIUS NAS-Identifier is not required to be an FQDN)" This text clearly suggests that Origin-Host should contain=20 the NAS identity, while the text in Section 9.3 says it=20 should be the translation agent's own identity. The former seems IMHO more logical (and when forwarding a RADIUS response to Diameter AA-Answer, the Origin-Host there is the RADIUS server/proxy identity, not translation agent)... but maybe there are some problems with this approach? A related issue: If this is the NAS identity (e.g. resolved from NAS-IP-Address), how is the Origin-Realm chosen? Do we use the translation agent's own realm or what? 5. Just after the text quoted above (also in 9.1) "The AAA protocol specified in the identity would be set to "RADIUS"." Origin-Host/Origin-Realm have type DiameterIdentity, not DiameterURI, so they don't have a protocol field. Just delete this sentence. 6. Section 9.2 says that (when translating a RADIUS response to Diameter AA-Answer) "The response's Origin-Host information is created from the FQDN of the source IP address of the RADIUS message." What about Origin-Realm? Do we use the translation agent's own realm? Best regards, Pasi From owner-aaa-wg@merit.edu Tue Sep 30 11:56:37 2003 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 LAA28094 for ; Tue, 30 Sep 2003 11:56:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1C5691256; Tue, 30 Sep 2003 11:56:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D5C391257; Tue, 30 Sep 2003 11:56: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 526AD91256 for ; Tue, 30 Sep 2003 11:56:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A15D5DDB9; Tue, 30 Sep 2003 11:56:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from localhost.localdomain (ua78d26hel.dial.kolumbus.fi [62.248.153.78]) by segue.merit.edu (Postfix) with ESMTP id 53A5A5DDE8 for ; Tue, 30 Sep 2003 11:56:22 -0400 (EDT) Received: from kolumbus.fi (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h8UFqXtd022179; Tue, 30 Sep 2003 18:52:33 +0300 Message-ID: <3F79A6C1.8060103@kolumbus.fi> Date: Tue, 30 Sep 2003 18:52:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 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]: Re: Issue 424: Record-Route AVP in Responses References: <052E0C61B69C3741AFA5FE88ACC775A6010C3828@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C3828@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: > Bernard Aboba wrote: > > >>>Yes, I guess we could allow Route-Record AVPs in responses well. >>>However, we still need to clarify how they get there... what >>>would be the best way to get this specified? Having NASREQ >>>update RFC3588? A new RFC that updates RFC3588? >> >>We could submit an errata for RFC 3588, since it is RFC 3588 that is >>internally inconsistent. Then we could clarify how they get there in >>NASREQ. >> >> >>>BTW, the current text in NASREQ isn't consistent with what IMHO >>>would be the most logical way to add the Route-Records (proxies >>>add them to responses one by one). But there isn't any clearly >>>specified alternative it would be consistent with either... >> >>Could you suggest new text? > > > Ok, here's a first attempt (I'd appreciate if somebody else could > also check that these make sense and don't create more > inconsistencies :-) > > Errata for RFC3588: > > o Section 6.2.2: add the following text after the first paragraph: > > "A proxy or relay agent MUST append a Route-Record AVP to all > responses forwarded. The AVP contains the identity of the peer > the response was received from." Ok. > o Section 10.1: Update the AVP occurrence table to specify that > RAA/ASA/STA messages can have zero or more Route-Record AVPs. Ok, but not sufficient. Also necessary to do the following: - Add "* [ Route-Record ]" to Section 8.3.2 (RAA), 8.4.2 (STA), and 8.5.2 (ASA). - Update 10.2 the AVP occurrence table to say that ACA command also can have Route-Record AVPs. - Add "* [ Route-Record ]" to Section 9.7.2. Question: are there any other commands (maybe in other documents) that would need this update? Note that your language requires adding the AVPs to all responses. > Updates for NASREQ -13b: > > o Section 9.2: Remove the following list item: > > "4. Route-Record AVPs (in the proper order)" > > o Section 9.2: Remove the following bullet: > > "The Route-Record AVPs MUST be added to the Diameter message, in > the same order they were present in the request. The gateway's > position in the forwarding should be properly recorded." > > o Section 9.2: Replace the bullet > > "The response's Origin-Host information is created from the > FQDN of the source IP address of the RADIUS message." > > with > > "The response's Origin-Host information is created from the FQDN > of the source IP address of the RADIUS message. The same FQDN > is also stored to a Route-Record AVP." > > o Section 10.1: Update AVP occurrence table to specify that > AAA message can have zero or more Route-Record AVPs. Ok. > A couple of related editorials/typos: > > o Section 9.3.3: Replace > > "...lookup on the source address and NAS-IP-Address > attributes..." > > with > > "...lookup on the source address and NAS-IPv6-Address attribute..." > > o Section 9.3.3: Add to end of last paragraph > > "...other action is taken." > > (seems this was chopped off at some point) Ok. --Jari From owner-aaa-wg@merit.edu Tue Sep 30 12:27:32 2003 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 MAA00312 for ; Tue, 30 Sep 2003 12:27:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1C58891257; Tue, 30 Sep 2003 12:27:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D60B491259; Tue, 30 Sep 2003 12:27: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 9122591257 for ; Tue, 30 Sep 2003 12:27:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79ECF5DD9E; Tue, 30 Sep 2003 12:27:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from localhost.localdomain (ua78d26hel.dial.kolumbus.fi [62.248.153.78]) by segue.merit.edu (Postfix) with ESMTP id A23145DDEC for ; Tue, 30 Sep 2003 12:27:22 -0400 (EDT) Received: from kolumbus.fi (argon [127.0.0.1]) by localhost.localdomain (8.12.8/8.12.8) with ESMTP id h8UGNXtd022240; Tue, 30 Sep 2003 19:23:39 +0300 Message-ID: <3F79AE05.2030209@kolumbus.fi> Date: Tue, 30 Sep 2003 19:23:33 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Identities in RADIUS translation References: <052E0C61B69C3741AFA5FE88ACC775A6010C382A@esebe023.ntc.nokia.com> In-Reply-To: <052E0C61B69C3741AFA5FE88ACC775A6010C382A@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: > While digging the Route-Record issue, I found several possible > problems in RADIUS translation (NASREQ -13b), related to > handling of Origin-Host/Realm and Destination-Host/Real AVPs... > > 1. Section 9.1 says that: > > "If the Diameter Command-Code is set to AA-Answer and the > Result-Code AVP is set to DIAMETER_MULTI_ROUND_AUTH, the > gateway must send a RADIUS Access-Challenge with the > Diameter Session-Id and the Origin-Host AVPs encapsulated > in the RADIUS State attribute, with the prefix > "Diameter/". This is necessary in order to ensure that the > Translation Agent that will receive the subsequent RADIUS > Access-Request will have access to the Session Identifier, > and be able to set the Destination-Host to the correct > value. > > Since both Session-Id and Origin-Host are placed into a > single State attribute (only one is allowed), they probably > need to be separated somehow. Can we assume that Origin-Host > doesn't contain any "/" characters? (likely to be true, although > in theory FQDN can contain just about anything) If fqdn has a "/", then that node would work pretty badly as a http server. Unfortunately, I was unable to find the RFC that defines FQDNs, to check if there's some truly illegal char, such as '\0'. > (A minor note: since only one State attribute is > allowed in RADIUS, this breaks if the AA-Answer already contains > a State AVP. But since the State AVP should be used only > by translation agents, this should occur only if we > have multiple translation steps.) Theoretically, you could append the contents of the original state avp to the data needed by the translation agent. > 2. The State attribute above stores the value needed for > Destination-Host, but what about Destination-Realm? Currently > it's taken from the User-Name attribute... and if the > Origin-Realm in AA-Answer is always guaranteed to be the same > as the Destination-Realm in AA-Request, then it should work. > But is this guaranteed? I am not sure. The spec does not say. What if there are multiple realms served by one home server? > (If it isn't, maybe we need to store the realm in State > attribute as well?) That would seem prudent. Other opinions? > 3. Earlier Section 9.1 also says that > > "If the RADIUS request contained a State attribute, and > the prefix of the data is "Diameter/", the data following > the prefix contains the Diameter Session-Id. If no such > attributes are present, and the RADIUS command is an > Access-Request, a new Session-Id is created. The > Session-Id is included in the Session-Id AVP. > > This isn't in sync with the text above... the State attribute > can also contain the value for Destination-Host. Yes. > 4. Also in Section 9.1: > > "The Diameter Origin-Host and Origin-Realm AVPs MUST be > created and added using the information from an FQDN > corresponding to the NAS-IP-Address attribute (preferred > if available), and/or the NAS-Identifier attribute. (Note > that the RADIUS NAS-Identifier is not required to be an > FQDN)" > > This text clearly suggests that Origin-Host should contain > the NAS identity, while the text in Section 9.3 says it > should be the translation agent's own identity. > > The former seems IMHO more logical (and when forwarding a Agreed. > RADIUS response to Diameter AA-Answer, the Origin-Host there > is the RADIUS server/proxy identity, not translation > agent)... but maybe there are some problems with this > approach? > > A related issue: If this is the NAS identity (e.g. resolved > from NAS-IP-Address), how is the Origin-Realm chosen? > Do we use the translation agent's own realm or what? > > 5. Just after the text quoted above (also in 9.1) > > "The AAA protocol specified in the identity would be > set to "RADIUS"." > > Origin-Host/Origin-Realm have type DiameterIdentity, not > DiameterURI, so they don't have a protocol field. Just > delete this sentence. Ok. --Jari From owner-aaa-wg@merit.edu Tue Sep 30 18:24:25 2003 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19235 for ; Tue, 30 Sep 2003 18:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7E2B791295; Tue, 30 Sep 2003 18:21:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 396F1912A3; Tue, 30 Sep 2003 18:21:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 943D191295 for ; Tue, 30 Sep 2003 18:21:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 803625DDE1; Tue, 30 Sep 2003 18:21:29 -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 826255DDC0 for ; Tue, 30 Sep 2003 18:21:28 -0400 (EDT) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id h8UMLQF1007955 for ; Wed, 1 Oct 2003 07:21:26 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id h8UMLQCe010491 for ; Wed, 1 Oct 2003 07:21:26 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id HAA10490 ; Wed, 1 Oct 2003 07:21:26 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id HAA03437; Wed, 1 Oct 2003 07:21:26 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id HAA10226; Wed, 1 Oct 2003 07:21:25 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id h8UMLPOn020848 for ; Wed, 1 Oct 2003 07:21:25 +0900 (JST) Received: from steelhead ([159.119.168.148]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HM100NUJSRN4F@tsbpo1.po.toshiba.co.jp> for aaa-wg@merit.edu; Wed, 1 Oct 2003 07:21:24 +0900 (JST) Received: from yohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1A4SqD-0004Ka-00 for ; Tue, 30 Sep 2003 15:19:33 -0700 Date: Tue, 30 Sep 2003 15:19:33 -0700 From: Yoshihiro Ohba Subject: [AAA-WG]: Type conflict in Mobile IPv4 application To: aaa-wg@merit.edu Message-id: <20030930221933.GA16626@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.4i Sender: owner-aaa-wg@merit.edu Precedence: bulk Section 4.0 of draft-ietf-aaa-diameter-mobileip-14.txt says that MIP-Host-Agent-Host AVP is of type DiameterIdentity: MIP-Home-Agent- 348 4.11 DiamIdent | M | P | | V | N | Host | | | | | | On the other hand, in Section 4.11 the same AVP is defined as type Grouped: MIP-Home-Agent-Host ::= < AVP Header: 348 > { Destination-Realm } { Destination-Host } * [ AVP ] Which is correct? Yoshihiro Ohba