From owner-aaa-wg@merit.edu Fri Feb 1 02:05:19 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28982 for ; Fri, 1 Feb 2002 02:05:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34B9091316; Fri, 1 Feb 2002 02:03:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3D7991323; Fri, 1 Feb 2002 02:03:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D03C591316 for ; Fri, 1 Feb 2002 02:03:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id A95725DDC7; Fri, 1 Feb 2002 02:03:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 0E13C5DD95 for ; Fri, 1 Feb 2002 02:03:13 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1173GZ27385 for ; Fri, 1 Feb 2002 09:03:16 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 1 Feb 2002 09:03:11 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Feb 2002 09:03:11 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 09:03:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: ISSUE Date: Fri, 1 Feb 2002 09:03:11 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF27184211FC3@trebe002.NOE.Nokia.com> Thread-Topic: Separation of the prepaid and postpaid accounting sessions Thread-Index: AcGqHs3smmD6gBYOEdasmgAIx3n1qgAzv0nQ From: To: X-OriginalArrivalTime: 01 Feb 2002 07:03:11.0793 (UTC) FILETIME=[82E2E210:01C1AAEE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA28982 Description of issue: Separation of the prepaid and postpaid accounting sessions Submitter name: Juha-Pekka Koskinen Submitter email address: juha-pekka.koskinen@nokia.com Date first submitted: January 31, 2002 Reference: draft-hakala-diameter-credit-control-01.txt Document: Base (draft-ietf-aaa-diameter-08.txt) Comment type: T Priority: 1 Section: 9.5 and 9.8.1 Rationale/Explanation of issue: There are two different kind of accounting sessions used for charging purposes. The postpaid accounting session is established to transfer CDRs (Charging Data Records) from client to server. These CDRs are used for billing purposes, typically once a month. The transfer of the CDRs is not critical task from the communication session point of view. The CDRs could be transferred only when the communication session has been disconnected, so the actual postpaid accounting session doesn't need to be fully completed simultaneously with the communication session. The prepaid accounting session is established to transfer charging information from client to server for rating purposes. The cost of the communication session is calculated and according to these calculations money is reserved from subcribers account. If there is no credit left in subscribers account or the credit is used during the communication session, the prepaid accounting session will be terminated. That termination will also cause the termination of the communication session. Requested change: Proposal As these two accounting sessions has different logic, it would be very useful to specify new values used in Accounting-Record-Type AVP (Chapter 9.8.1): EVENT_PREPAID 5 An Accounting Event Prepaid record is used to indicate that one-time prepaid event has occured (meaning that the start and end of the event are simultaneous). This record contains all information relevant to service and granted threshold. START_PREPAID 6 An Accounting Start Prepaid record is used to indicate that a prepaid service will have measurable length. An Accounting Start Prepaid record is used to initiate that money reservation will be needed for this session. This record contains all information that is relevant to determine cost of the service and granted threshold. UPDATE_PREPAID 7 An Accounting Update Prepaid record is used to indicate that a prepaid service will need more credit to continue. It is also used when service (client) need to update itself tariff of the ongoing accounting session. This record contains all information that is relevant to determine cost of the service and granted threshold. STOP_PREPAID 8 An Accounting Stop Prepaid record is sent to terminate and prepaid accounting session. This record also contains unused amount of the granted threshold. Also the chapter 9.5 should have following structure: 9.5 Accounting Records In all accounting records the Session-Id and User-Name AVPs MUST be present. If strong authentication across agents is required, as described in [11], the CMS-Signed-Data AVP may be used to authenticate the Accounting Data and Service Specific AVPs. It is not typically necessary that the CMS-Signed-Data AVP cover any additional AVPs, but it is permitted as long as the AVPs protected are defined to have their 'P' bit set. 9.5.1 Postpaid Accounting Records Different types of postpaid accounting records are sent depending on the actual type of accounted postpaid service and the accounting server's directions for interim accounting. If the accounted postpaid service is a one- time event, meaning that the start and stop of the event are simultaneous, then the Accounting-Record-Type AVP MUST be present and set to the value EVENT_RECORD. If the postpaid accounted service is of a measurable length, then the AVP MUST use the values START_RECORD, STOP_RECORD, and possibly, INTERIM_RECORD. If the accounting server has directed interim accounting to be enabled for the session, but no interim interval was specified, two accounting records MUST be generated for each service of type session. When the initial Accounting-Request is sent for a given session is sent, the Accounting-Record-Type AVP MUST be set to the value START_RECORD. When the last Accounting-Request is sent, the value MUST be STOP_RECORD. If a specified interim interval exists, the Diameter client MUST produce additional records between the START_RECORD and STOP_RECORD, marked INTERIM_RECORD. The production of these records is directed both by Accounting-Interim-Interval as well as any re-authentication or re-authorization of the session. The Diameter client MUST overwrite any previous interim accounting records that are locally stored for delivery, if a new record is being generated for the same session. This ensures that only one pending interim record can exist on an access device for any given session. A particular value of Accounting-Sub-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD, or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORD, and a single STOP_RECORD. A particular Diameter application specification MUST define the type of sequences that MUST be used. 9.5.2 Prepaid Accounting Records Different types of prepaid accounting records are sent depending on the actual type of accounted prepaid service and the accounting server's directions for interim accounting. If the accounted prepaid service is a one- time event, meaning that the start and stop of the event are simultaneous, then the Accounting-Record-Type AVP MUST be present and set to the value EVENT_PREPAID. If the prepaid accounted service is of a measurable length, then the AVP MUST use the values START_PREPAID, STOP_PREPAID, and possibly, UPDATE_PREPAID. When the accounting server has granted threshold value to used for the session, but the granted threshold is not used completely or the client's tariff doesn't change, two accounting records MUST be generated for each service of type session. When the initial Accounting-Request for a given session is sent, the Accounting-Record-Type AVP MUST be set to the value START_PREPAID. When the last Accounting-Request is sent, the value MUST be STOP_PREPAID. When granted threshold value is used up or the client's tariff will change, the Diameter client MUST produce additional records between the START_PREPAID and STOP_PREPAID records, marked UPDATE_PREPAID. The production of these records is directed both by Accounting-Interim-Interval, application specific AVP concerning granted threshold as well as any re-authentication or re-authorization of the session. The Diameter client MUST produce UPDATE_PREPAID record when granted threshold is used up. A particular value of Accounting-Sub-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_PREPAID, or several records starting with one having the value START_PREPAID, followed by zero or more UPDATE_PREPAID, and a single STOP_PREPAID. A particular Diameter application specification MUST define the type of sequences that MUST be used. From owner-aaa-wg@merit.edu Fri Feb 1 02:14:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02901 for ; Fri, 1 Feb 2002 02:14:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE77791228; Fri, 1 Feb 2002 02:14:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 964EF91229; Fri, 1 Feb 2002 02:14:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7BCB791228 for ; Fri, 1 Feb 2002 02:14:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 615625DDC9; Fri, 1 Feb 2002 02:14:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id C60FB5DD95 for ; Fri, 1 Feb 2002 02:14:08 -0500 (EST) Received: from gwzpc (tokyo-vpn-client8.cisco.com [10.70.84.8]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA15853; Thu, 31 Jan 2002 23:14:02 -0800 (PST) Reply-To: From: "Glen Zorn" To: , Subject: RE: [AAA-WG]: ISSUE Date: Thu, 31 Jan 2002 23:13:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <0AA9E01B31168E42A308714A6EF27184211FC3@trebe002.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit juha-pekka.koskinen@nokia.com [mailto:juha-pekka.koskinen@nokia.com] writes: Ok, I'll go out on a limb here and call this a new feature (not just new, but application-specific) and suggest that it be immediately rejected by the WG Chairs. > Description of issue: Separation of the prepaid and postpaid > accounting sessions > Submitter name: Juha-Pekka Koskinen > Submitter email address: juha-pekka.koskinen@nokia.com > Date first submitted: January 31, 2002 > Reference: draft-hakala-diameter-credit-control-01.txt > Document: Base (draft-ietf-aaa-diameter-08.txt) > Comment type: T > Priority: 1 > Section: 9.5 and 9.8.1 > Rationale/Explanation of issue: > > There are two different kind of accounting sessions used for > charging purposes. > > The postpaid accounting session is established to transfer CDRs > (Charging Data Records) from client to server. These CDRs are > used for billing purposes, typically once a month. The transfer > of the CDRs is not critical task from the communication session > point of view. The CDRs could be transferred only when the > communication session has been disconnected, so the actual > postpaid accounting session doesn't need to be fully completed > simultaneously with the communication session. > > The prepaid accounting session is established to transfer > charging information from client to server for rating purposes. > The cost of the communication session is calculated and according > to these calculations money is reserved from subcribers account. > If there is no credit left in subscribers account or the credit > is used during the communication session, the prepaid accounting > session will be terminated. That termination will also cause the > termination of the communication session. > > Requested change: > Proposal > > As these two accounting sessions has different logic, it would be > very useful to specify new values used in Accounting-Record-Type > AVP (Chapter 9.8.1): > > EVENT_PREPAID 5 > An Accounting Event Prepaid record is used to indicate that > one-time prepaid event has occured (meaning that the start and > end of the event are simultaneous). This record contains all > information relevant to service and granted threshold. > > START_PREPAID 6 > An Accounting Start Prepaid record is used to indicate > that a prepaid service will have measurable length. An Accounting > Start Prepaid record is used to initiate that money reservation > will be needed for this session. This record contains all > information that is relevant to determine cost of the service and > granted threshold. > > UPDATE_PREPAID 7 > An Accounting Update Prepaid record is used to indicate > that a prepaid service will need more credit to continue. It is > also used when service (client) need to update itself tariff of > the ongoing accounting session. This record contains all > information that is relevant to determine cost of the service and > granted threshold. > > STOP_PREPAID 8 > An Accounting Stop Prepaid record is sent to terminate and > prepaid accounting session. This record also contains unused > amount of the granted threshold. > > Also the chapter 9.5 should have following structure: > > 9.5 Accounting Records > > In all accounting records the Session-Id and User-Name AVPs MUST be > present. If strong authentication across agents is required, as > described in [11], the CMS-Signed-Data AVP may be used to > authenticate the Accounting Data and Service Specific AVPs. It is not > typically necessary that the CMS-Signed-Data AVP cover any additional > AVPs, but it is permitted as long as the AVPs protected are defined > to have their 'P' bit set. > > 9.5.1 Postpaid Accounting Records > > Different types of postpaid accounting records are sent > depending on the > actual type of accounted postpaid service and the accounting server's > directions for interim accounting. If the accounted postpaid > service is a one- > time event, meaning that the start and stop of the event are > simultaneous, then the Accounting-Record-Type AVP MUST be present and > set to the value EVENT_RECORD. > > If the postpaid accounted service is of a measurable length, > then the AVP MUST > use the values START_RECORD, STOP_RECORD, and possibly, > INTERIM_RECORD. If the accounting server has directed interim > accounting to be enabled for the session, but no interim interval was > specified, two accounting records MUST be generated for each service > of type session. When the initial Accounting-Request is sent for a > given session is sent, the Accounting-Record-Type AVP MUST be set to > the value START_RECORD. When the last Accounting-Request is sent, the > value MUST be STOP_RECORD. > > If a specified interim interval exists, the Diameter client MUST > produce additional records between the START_RECORD and STOP_RECORD, > marked INTERIM_RECORD. The production of these records is directed > both by Accounting-Interim-Interval as well as any re-authentication > or re-authorization of the session. The Diameter client MUST > overwrite any previous interim accounting records that are locally > stored for delivery, if a new record is being generated for the same > session. This ensures that only one pending interim record can exist > on an access device for any given session. > > A particular value of Accounting-Sub-Session-Id MUST appear only in > one sequence of accounting records from a DIAMETER client, except for > the purposes of retransmission. The one sequence that is sent MUST > be either one record with Accounting-Record-Type AVP set to the value > EVENT_RECORD, or several records starting with one having the value > START_RECORD, followed by zero or more INTERIM_RECORD, and a single > STOP_RECORD. A particular Diameter application specification MUST > define the type of sequences that MUST be used. > > 9.5.2 Prepaid Accounting Records > > Different types of prepaid accounting records are sent depending on the > actual type of accounted prepaid service and the accounting server's > directions for interim accounting. If the accounted prepaid > service is a one- > time event, meaning that the start and stop of the event are > simultaneous, then the Accounting-Record-Type AVP MUST be present and > set to the value EVENT_PREPAID. > > If the prepaid accounted service is of a measurable length, > then the AVP MUST > use the values START_PREPAID, STOP_PREPAID, and possibly, > UPDATE_PREPAID. When the accounting server has granted threshold value > to used for the session, but the granted threshold is not used > completely or the > client's tariff doesn't change, two accounting records MUST be > generated for each > service of type session. When the initial Accounting-Request for a > given session is sent, the Accounting-Record-Type AVP MUST be set to > the value START_PREPAID. When the last Accounting-Request is sent, the > value MUST be STOP_PREPAID. > > When granted threshold value is used up or the client's tariff > will change, > the Diameter client MUST produce additional records between > the START_PREPAID and > STOP_PREPAID records, marked UPDATE_PREPAID. The production of > these records is directed > both by Accounting-Interim-Interval, application specific AVP > concerning granted > threshold as well as any re-authentication or re-authorization > of the session. The > Diameter client MUST produce UPDATE_PREPAID record when > granted threshold is used up. > > A particular value of Accounting-Sub-Session-Id MUST appear only in > one sequence of accounting records from a DIAMETER client, except for > the purposes of retransmission. The one sequence that is sent MUST > be either one record with Accounting-Record-Type AVP set to the value > EVENT_PREPAID, or several records starting with one having the value > START_PREPAID, followed by zero or more UPDATE_PREPAID, and a single > STOP_PREPAID. A particular Diameter application specification MUST > define the type of sequences that MUST be used. > From owner-aaa-wg@merit.edu Fri Feb 1 02:31:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03070 for ; Fri, 1 Feb 2002 02:31:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 01E959122A; Fri, 1 Feb 2002 02:30:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C00C291315; Fri, 1 Feb 2002 02:30:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C5EA49122A for ; Fri, 1 Feb 2002 02:30:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 934B35DDC9; Fri, 1 Feb 2002 02:30:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DB5755DD95 for ; Fri, 1 Feb 2002 02:30:28 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA24795; Thu, 31 Jan 2002 23:13:38 -0800 (PST) (envelope-from aboba@internaut.com) Date: Thu, 31 Jan 2002 23:13:38 -0800 (PST) From: Bernard Aboba To: Glen Zorn Cc: juha-pekka.koskinen@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: ISSUE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Ok, I'll go out on a limb here and call this a new feature (not just new, > but application-specific) and suggest that it be immediately rejected by the > WG Chairs. One of the beauties of AAA is that Accounting focusses on providing estimates of resource consumption. The usage of that information or the purpose of the transfer is immaterial, yet many types of service can still be provided. This includes prepaid, postpaid, and even unpaid (guest) service. Before this Issue will be considered, I would like to understand why this functionality cannot already be provided within the protocol as it exists. No evidence is provided in the issue report to justify the necessity of the change. Some comments below: > > The postpaid accounting session is established to transfer CDRs > > (Charging Data Records) from client to server. AAA does not transfer CDRs. It transfers binary accounting data which are used to create CDRs. > These CDRs are used for billing purposes, typically once a month. Discussion of billing practices is outside the scope of the AAA WG. > doesn't need to be completed simultaneously with the communication >session. It sounds like Diameter accounting should work just fine for this. So why is a change being proposed? > The prepaid accounting session is established to transfer > charging information from client to server for rating purposes. The reason for the transfer is not relevant to the protocol. > The cost of the communication session is calculated and according > to these calculations money is reserved from subcribers account. > If there is no credit left in subscribers account or the credit > is used during the communication session, the prepaid accounting > session will be terminated. That termination will also cause the > termination of the communication session. Seems to me that this effect could be achieved without any protocol changes. So why is a change necessary? From owner-aaa-wg@merit.edu Fri Feb 1 04:36:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08645 for ; Fri, 1 Feb 2002 04:36:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9C6DE91315; Fri, 1 Feb 2002 04:36:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5D8B991318; Fri, 1 Feb 2002 04:36:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F94191315 for ; Fri, 1 Feb 2002 04:36:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14AE05DE1D; Fri, 1 Feb 2002 04:36:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 2E9935DD95 for ; Fri, 1 Feb 2002 04:36:00 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id KAA24787; Fri, 1 Feb 2002 10:33:51 +0100 Message-ID: <3C5A6F58.4080001@ipunplugged.com> Date: Fri, 01 Feb 2002 11:35:04 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernard Aboba Cc: Glen Zorn , juha-pekka.koskinen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE References: 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: >>The cost of the communication session is calculated and according >>to these calculations money is reserved from subcribers account. >>If there is no credit left in subscribers account or the credit >>is used during the communication session, the prepaid accounting >>session will be terminated. That termination will also cause the >>termination of the communication session. >> > >Seems to me that this effect could be achieved without any protocol >changes. So why is a change necessary? > I don't see the need for the requested change either, but are you saying that it would be acceptable for an accounting server to start sending ASRs? j From owner-aaa-wg@merit.edu Fri Feb 1 05:06:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11833 for ; Fri, 1 Feb 2002 05:06:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 702BD91318; Fri, 1 Feb 2002 05:05:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2710A91319; Fri, 1 Feb 2002 05:05:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA5AE91318 for ; Fri, 1 Feb 2002 05:05:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 98D285DE27; Fri, 1 Feb 2002 05:05:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 3808F5DD95 for ; Fri, 1 Feb 2002 05:05:51 -0500 (EST) Received: from gwzpc (tokyo-vpn-client8.cisco.com [10.70.84.8]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id CAA16312; Fri, 1 Feb 2002 02:05:07 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Johan Johansson" , "Bernard Aboba" Cc: , Subject: RE: [AAA-WG]: ISSUE Date: Fri, 1 Feb 2002 02:05:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C5A6F58.4080001@ipunplugged.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Johan Johansson [mailto:johanj@ipunplugged.com] writes: > Bernard Aboba wrote: > > >>The cost of the communication session is calculated and according > >>to these calculations money is reserved from subcribers account. > >>If there is no credit left in subscribers account or the credit > >>is used during the communication session, the prepaid accounting > >>session will be terminated. That termination will also cause the > >>termination of the communication session. > >> > > > >Seems to me that this effect could be achieved without any protocol > >changes. So why is a change necessary? > > > I don't see the need for the requested change either, but are you saying > that it would be acceptable for an accounting server to start > sending ASRs? I can't find any place where the proposed change mentions sending an ASR: it appears to me that the Diameter "client" is responsible for terminating service (only reasonable, since it is known in advance how many "units" of service should be delivered). > > j > > > From owner-aaa-wg@merit.edu Fri Feb 1 05:09:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12074 for ; Fri, 1 Feb 2002 05:09:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB6D491319; Fri, 1 Feb 2002 05:08:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BADF99131A; Fri, 1 Feb 2002 05:08:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF55591319 for ; Fri, 1 Feb 2002 05:08:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id A00315DE29; Fri, 1 Feb 2002 05:08:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id EFED95DD95 for ; Fri, 1 Feb 2002 05:08:56 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id LAA25607; Fri, 1 Feb 2002 11:06:55 +0100 Message-ID: <3C5A7718.7080902@ipunplugged.com> Date: Fri, 01 Feb 2002 12:08:08 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020120 X-Accept-Language: en-us MIME-Version: 1.0 To: gwz@cisco.com Cc: Bernard Aboba , juha-pekka.koskinen@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE References: 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 Glen Zorn wrote: >Johan Johansson [mailto:johanj@ipunplugged.com] writes: > >>Bernard Aboba wrote: >> >>>>The cost of the communication session is calculated and according >>>>to these calculations money is reserved from subcribers account. >>>>If there is no credit left in subscribers account or the credit >>>>is used during the communication session, the prepaid accounting >>>>session will be terminated. That termination will also cause the >>>>termination of the communication session. >>>> >>>Seems to me that this effect could be achieved without any protocol >>>changes. So why is a change necessary? >>> >>I don't see the need for the requested change either, but are you saying >>that it would be acceptable for an accounting server to start >>sending ASRs? >> > >I can't find any place where the proposed change mentions sending an ASR: it >appears to me that the Diameter "client" is responsible for terminating >service (only reasonable, since it is known in advance how many "units" of >service should be delivered). > My question was prompted by Bernard's comment and not the suggested change. j From owner-aaa-wg@merit.edu Fri Feb 1 09:32:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23747 for ; Fri, 1 Feb 2002 09:32:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8B3FB9131D; Fri, 1 Feb 2002 09:32:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 520539131E; Fri, 1 Feb 2002 09:32:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 94DE09131D for ; Fri, 1 Feb 2002 09:32:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 09FF45DDD7; Fri, 1 Feb 2002 09:32:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id C661D5DDBF for ; Fri, 1 Feb 2002 09:32:01 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id HAA18663 for ; Fri, 1 Feb 2002 07:32:00 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA02602 for ; Fri, 1 Feb 2002 07:31:59 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 1 Feb 2002 08:31:58 -0600 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Tony Johansson'" , Bob Kopacz Cc: Mark Eklund , aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Fri, 1 Feb 2002 08:31:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Tony Johansson wrote: > However, there is no way for the AAAF2 to know from which domain > this MN is requesting to keep the HA... I thought Destination-Realm in HAR = Originating-Realm in AMR, no? If AAAF1 and AAAF2 are in the same domain, how bad would it be to assume that they share a key? We can then maybe adopt the mechanism used to convey the key from AAAH to MN, i.e. have AAAF2 send only the key material to AAAF1. Just a thought... -Panos > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Wednesday, January 30, 2002 9:18 PM > To: Bob Kopacz > Cc: Mark Eklund; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA > Key to FA > > > Hi Bob, > > Thanks for your comments I think we are getting somewhere here:) > > please find my comments embedded... > > Regards, > > Tony > > Bob Kopacz wrote: > > > Hi Tony, > > > > > From: Tony Johansson [tony.johansson@ericsson.com] > > > Sent: Monday, January 28, 2002 6:46 PM > > > To: Bob Kopacz > > > Cc: aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated > FA-HA Key to FA > > > > > > Hello Bob and All, > > > > > > I agree that it could be good to have a way of encrypting > the FA-HA Key as > > > you describe below, and even more for the case where you > move through a > > > third domain ( i.e. the AAAF1 and AAAF2 belongs to two > different networks). > > > However, I really think that we need to find a more > interoperability > > > approve approach. I'm not sure that we just can say that > the HAA-toAMA-Data > > > AVP is of type OctetString and may be used, to convey > the FA-HA key > > > information in some proprietary format and security > method which is > > > agreed-upon by all AAAF servers in the foreign network... > > > > > > You mention CMS security below and I agree, couldn't we > make use of the CMS > > > security for this case? > > > > Your idea to use CMS security is probably a better idea. A > proprietary > > solution wouldn't work very well inter-realm. And using > CMS is more in > > the spirit of the mobileip-draft, > > > where its one comment in section 5.0 > > about securing keys is "If the AAAH does not communicate > directly with the > > foreign agent, and it does not wish for intermediate proxies to have > > access to the session keys, they SHOULD be protected using the CMS > > security application." > > > > > > > > So, what about the following (I'm not a CMS security > expert, so please > > > correct me if this is not really possible or to complex...): > > > > > > Instead, make the HAA-toAMA-Data AVP of type grouped : > > > > > > HAA-toAMA-Data AVP ::= < AVP Header: TBD > > > > { Originating-Foriegn-Home-Key-Distr-Host } > > > { CMS-Encrypted-Data } > > > * [ AVP ] > > > > > > The CMS-Encrypted-Data AVP would contain the FA-HA Key > encrypted and the > > > Originating-Foriegn-Home-Key-Distr-Host AVP (lack of > better name:) would > > > contain the Host NAI of the AAAF2, see Figure below > > > > > > The message flow would then be the following: > > > > > > (Please view in a fixed-width font such as Courier.) > > > > > > 1.amr-> 1.amr-> > > > FA --------> AAAF1 1------------> AAAH > > > <-6.ama | ^ <-4.ama | > > > | | | ^ > > > | | | | > > > 5.dsar | |5.dsaa 2.har |3.haa > > > | | | | > > > | | V | > > > | | | > > > <-2.har v | <-2.har | > > > HA <-------- AAAF2 <---------------/ > > > 3.haa-> 3.haa-> > > > > > > Thus, the AAAF2 would create the HAA-to-AMA AVP with its > Host name and the > > > FA-HA Key encrypted using its digital certificate. Upon > receiving the HAA > > > the AAAH would add the HAA-to-AMA AVP into the AMA. Upon > receipt of the AMA > > > the AAAF1 would identify the > Originating-Foriegn-Home-Key-Distr-Host AVP in > > > the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and > request for the > > > digital certificate, which the AAAF1 then would use to > decrypt the FA-HA > > > Key.... > > > > > > Could this be a way forward ? > > > > Here's some thoughts, but bear in mind my limited > understanding of CMS. > > > > (1) Maybe AAAF2 should initiate the security relationship > with AAAF1, > > rather than the other way around. That is, AAAF2 sends the > DSAR before > > responding with the HAA. My thinking here is, in the case > where the AAAH > > wants to secure its generated keys with the FA, it is the > sender of the > > CMS-secured data that initiates the DSAR. > > Right. Since it is the AAAF2 that will create the FA-HA Key > and also the one that > will decide if the key needs to be encrypted or not. However, > there is no way for > the AAAF2 to know from which domain this MN is requesting to > keep the HA (the > only thing the AAAF2 know is that it has no pending AMR for > this user from one of > its FAs). So, for the AAAF2 to really be able to decide if > the FA-HA key needs to > be encrypted or not it needs to know the originating domain. > > So, what about introduce the following new AVP: > > Originating-Foreign-AAA ::= < AVP Header: YYY > > { Origin-Realm } // = AAAF1's realm > { Origin-Host } // = AAAF1's host-name > > > The Originating-Foreign-AAA AVP would be added in the AMR by > the AAAF1 in the > case that the Home-Address-Allocatable-Only-in-Home-Realm > flag are set to > zero...(i.e. in all cases when the HA is not allocated in the > home domain). > > So, if the Originating-Foreign-AAA AVP is present in the AMR > the AAAH must copy > it into the HAR. The AAAF2 would then have the necessary info > for the above.. > > > > > > > > > (2) The above scheme requires the CMS big gun. In the > mobile-ip draft, > > the AAAH has the option of securing its generated keys via > CMS, or sending > > them in the clear. So maybe CMS should be an option for the > > AAAF2-generated key. That is, AAAF2 could send the > FA-HA-Key secured (per > > your proposal), or could instead just send a plain old > MIP-FA-to-HA-Key > > AVP if the AAAF2 didn't feel the need to secure the key. > > > > (3) In the above HAA-to-AMA-Data AVP, the diameter identity > of the AAAF2 > > is provided. If the AAAF1 wants to send a DSAR to AAAF2, > it might also be > > necessary to include AAAF2's realm in the HAA-to-AMA-Data > AVP, so that > > AAAF1 can fill in both the Destination-Realm and > Destination-Host of the > > DSAR, for routing. > > > > (4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck > of name. With > > the thought of minimizing the creation of new AVPs, could > we just use the > > "Origin-Host" and "Origin-Realm" AVPs as members of > HAA-to-AMA-Data? The > > idea is, when "Origin-Host" and "Origin-Realm" are members > of a grouped > > AVP, they represent the originator of that AVP. So AAAF2 > could fill in > > his identity as the Origin-Host member of HAA-to-AMA-Data. > > > > (5) Also in the interest of not unnecessarily creating new > AVPs, maybe > > just use the existing MIP-FA-to-HA-Key AVP instead of the new > > HAA-to-AMA-Data AVP. The idea here is that nowadays Diameter allows > > grouped AVPs to have variable member AVPs. So the > MIP-FA-to-HA-Key AVP > > could contain different sets of member AVPs that represent either > > encrypted or non-encrypted FA-HA information. That is, the > > MIP-FA-to-HA-Key AVP could be something like: > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // non-encrypted case > > { MIP-FA-to-HA-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // encrypted case > > { Origin-Realm } // = AAAF2's realm, > if necessary > > { Origin-Host } // = AAAF2's host, > if necessary > > { CMS-Encrypted-Data } > > //(or {MIP-Session-Key-Material}?) > > * [ AVP ] > > > > I don't think this would be such a good idea to try to reuse > that same AVP. I > think we need new grouped AVP for the encryption case since > we need a completely > new set of mandatory AVPs. So what about the following: > > MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY> > { CMS-Encrypted-Data } > * [ AVP ] > > The FA-HA key would be encrypted in the CMS-Encrypted-Data > AVP with AAAF1 SA. The > originator info is part of the CMS envelop-data header. So, I > don't think we need > to add an Origin-Realm AVP and an Origin-Host AVP. Upon > receiving the HAA the > AAAH only has to copy the MIP-Encrypted-FA-to-HA-Key AVP to > the AMA back to the > AAAF1 (i.e. in the same fashion as when the FA-HA Key is > distributed in clear > text, which is describe in the draft today). > > > > > > > > (6) If the AAAF2 wanted to send back a CMS-encrypted > version of the FA-HA > > key, then the single AMA sent from the AAAH to AAAF1 could > contain two > > sets of CMS-secured AVPs, with two different sources and > destinations. > > That is, the AMA could contain FA-HA key data, CMS-secured > between AAAF2 > > and AAAF1, and also could contain FA-MN key data, > CMS-secured betweeen > > AAAH and FA. Can CMS/AMAs piggyback stuff this way? > > > > > Comments please... > > > > > > Tony > > > > > > > > > > > > Bob Kopacz wrote: > > > > > > > Issue : Returning AAAF-Generated FA-HA Key to FA > > > > Submitter name: Bob Kopacz > > > > Submitter email address: BKopacz@InterlinkNetworks.com > > > > Date first submitted: 01-15-2002 > > > > Reference: > > > > Document: mobileip > > > > Comment type: Technical > > > > Priority: 1 > > > > Section: 2.2, 2.4, 5.4, 8.1, Issue#203 > > > > Rationale/Explanation of issue: > > > > > > > > [The following is based on some issue#203-related emails > > > > exchanged with Mark Eklund. The proposal I'm > contributing here > > > > is also Mark's, as I understand it] > > > > > > > > When the HA is in the foreign network and a FA-HA key is > > > > requested, the AAAF, rather than the AAAH, generates the key. > > > > > > > > Here's the diagram of the issue: > > > > > > > > amr-> amr-> > > > > FA --------> AAAF1 -------------> AAAH > > > > <-ama <-ama | > > > > | ^ > > > > | | > > > > har | haa > > > > | | > > > > V | > > > > | > > > > <-har <-har | > > > > HA <-------- AAAF2 <---------------/ > > > > haa-> haa-> > > > > > > > > In the above diagram, FA & HA & AAAF1 & AAAF2 are all > in the same > > > > visited network. AAAF1 and AAAF2 may be the same > server, or may > > > > be different servers. > > > > > > > > In the above diagram, AAAF2 generates the FA-HA key. > > > > > > > > The problem is that this key must somehow be returned > to the FA > > > > via AAAF1. The proposal here is to pass the key back > to the FA > > > > via the the HAA and AMA messages. AAAF2 may be > concerned about > > > > security, so may want the FA-HA key to be passed encrypted so > > > > that AAAH and intervening servers can't figure it > out, but AAAF1 > > > > can somehow decrypt it. > > > > > > > > The details are: > > > > > > > > 1. A new HAA-to-AMA-Data AVP, of type octetstring, is created. > > > > The purpose of this AVP is convey information from > the HA's AAAF > > > > (AAAF2) to the FA's AAAF (AAAF1). All AAAFs in that foreign > > > > realm MUST have an agreed upon format and security method for > > > > this AVP to be used. (It may be possible to use CMS security > > > > to somehow encrypt this AVP, but it is unclear just how, as it > > > > involves the AAAH copying a secure AVP from the HAA > to the AMA, > > > > and the AMA may carry both AAAH-FA and AAAF1-AAAF2 secured > > > > AVPs) > > > > > > > > 2. When the FA-HA key is generated by AAAF2, this key must > > > > somehow be conveyed to AAAF1. There are two ways to do this: > > > > a. Use the MIP-HAA-to-AMA-Data AVP, or > > > > b Have a common database among AAAFs in the foreign network, > > > > wherein AAAF2 may deposit the FA-HA key, which is > later retrieved > > > > by AAAF1, in a proprietary manner not described in > the Diameter > > > > documents. > > > > > > > > 3. If the HAA-to-AMA-Data AVP is present in the HAA, the AAAH > > > > treats it as opaque data and passes it in the AMA. > > > > > > > > 4, If AAAF1 receives the HAA-to-AMA-Data AVP in the AMA, AAAF1 > > > > will use this AVP to recreate the FA-HA key, and > replace this AVP > > > > by a MIP-FA-to-HA-Key AVP in the AMA sent to the FA. > > > > > > > > Requested change: > > > > > > > > This issues supercedes issue#203, which also addresses the > > > > problem of returning an AAAF-Generated FA-HA Key to > the FA, but > > > > didn't quite work in the case where there was a 2nd AAAF > > > > involved. > > > > > > > > In section 2.2. Add [HAA-to-AMA-Data] to the AMA ABNF. > > > > > > > > In section 2.4. Add [HAA-to-AMA-Data] to the HAA ABNF. > > > > > > > > In section 6, define the following new AVP: > > > > > > > > 6.x HAA-to-AMA-Data AVP > > > > > > > > The HAA-to-AMA-Data AVP (AVP Code TBD) is of type > OctetString and > > > > may be used, when the HA is allocated in the > foreign network and > > > > the HA's AAAF generates the FA-HA key, to convey > the FA-HA key > > > > information (in some proprietary format and > security method which > > > > is agreed-upon by all AAAF servers in the foreign > network) back > > > > to the FA's AAAF. > > > > > > > > In section 8.1. Add a row for the new HAA-to-AMA-Data > AVP, with these > > > > occurrence rules: AMR 0, AMA 0-1, HAR 0, HAA 0-1. > > > > > > > > Replace section 5.4 by > > > > > > > > If the home agent is in the home realm, then AAAH > has to generate > > > > the Foreign-Home session key. Otherwise, it is > generated by the > > > > AAAF receiving the HAR. > > > > > > > > If the AAAH generates the Foreign-Home session > key, then the AAAH > > > > includes the session key in the MIP-HA-to-FA-Key AVP, and > > > > includes the AVP as part of the HAR message sent > to the home > > > > agent. The corresponding session key that is to > be sent to the > > > > foreign agent is cached on the AAAH until the HAA > is received, at > > > > which time the AAAH adds the MIP-FA-to-HA Key AVP > to the AMA, > > > > using the SPI in the MIP-FA-to-HA-SPI. > > > > > > > > Upon receipt of the HAR, the home agent recovers > the Foreign-Home > > > > session key, allocates an SPI to be used with the key. The > > > > allocated SPI is included in the HAA's > MIP-FA-to-HA SPI AVP. > > > > > > > > If the AAAH doesn't generate the Foreign-Home > session key, then > > > > upon receipt of the HAA, the AAAH extracts and passes the > > > > MIP-FA-to-HA-SPI AVP (if present in the HAR) in > the AMA, and > > > > extracts and passes the HAA-to-AMA-Data AVP (if > present in the > > > > HAR) in the AMA. > > > > > > > > If the AAAF receives an AMA which contains a > HAA-to-AMA-Data AVP, > > > > the AAAF will recreate the FA-HA key, generate a > MIP-FA-to-HA-Key > > > > AVP, and pass the MIP-FA-to-HA-Key AVP to the FA. > > > > > > > > Alternatively, if the AAAF generates the > Foreign-Home session > > > > key, the AAAFs in the foreign network may have a > common database > > > > among AAAFs, wherein the HA's AAAF may deposit > the FA-HA key, > > > > which is later retrieved by the FA's AAAF, in a > proprietary > > > > manner not described in the Diameter documents. > From owner-aaa-wg@merit.edu Fri Feb 1 10:27:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26668 for ; Fri, 1 Feb 2002 10:27:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EA9749120C; Fri, 1 Feb 2002 10:27:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B477791321; Fri, 1 Feb 2002 10:27:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B87729120C for ; Fri, 1 Feb 2002 10:27:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E7E15DE1B; Fri, 1 Feb 2002 10:27:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7939F5DDD5 for ; Fri, 1 Feb 2002 10:27:21 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id CB5817A; Fri, 1 Feb 2002 10:27:20 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "Mark Eklund" , Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Fri, 1 Feb 2002 10:26:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C58B759.B84185CC@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > From: "Tony Johansson" > To: "Bob Kopacz" > Cc: "Mark Eklund" ; > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > Date: Wednesday, January 30, 2002 10:20 PM > > Hi Bob, > > Thanks for your comments I think we are getting somewhere here:) I agree. > please find my comments embedded... > > Regards, > > Tony > > Bob Kopacz wrote: > > > Hi Tony, > > > > > From: Tony Johansson [tony.johansson@ericsson.com] > > > Sent: Monday, January 28, 2002 6:46 PM > > > To: Bob Kopacz > > > Cc: aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > > > > > Hello Bob and All, > > > > > > I agree that it could be good to have a way of encrypting the FA-HA Key as > > > you describe below, and even more for the case where you move through a > > > third domain ( i.e. the AAAF1 and AAAF2 belongs to two different networks). > > > However, I really think that we need to find a more interoperability > > > approve approach. I'm not sure that we just can say that the HAA-toAMA-Data > > > AVP is of type OctetString and may be used, to convey the FA-HA key > > > information in some proprietary format and security method which is > > > agreed-upon by all AAAF servers in the foreign network... > > > > > > You mention CMS security below and I agree, couldn't we make use of the CMS > > > security for this case? > > > > Your idea to use CMS security is probably a better idea. A proprietary > > solution wouldn't work very well inter-realm. And using CMS is more in > > the spirit of the mobileip-draft, > > > where its one comment in section 5.0 > > about securing keys is "If the AAAH does not communicate directly with the > > foreign agent, and it does not wish for intermediate proxies to have > > access to the session keys, they SHOULD be protected using the CMS > > security application." > > > > > > > So, what about the following (I'm not a CMS security expert, so please > > > correct me if this is not really possible or to complex...): > > > > > > Instead, make the HAA-toAMA-Data AVP of type grouped : > > > > > > HAA-toAMA-Data AVP ::= < AVP Header: TBD > > > > { Originating-Foriegn-Home-Key-Distr-Host } > > > { CMS-Encrypted-Data } > > > * [ AVP ] > > > > > > The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the > > > Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would > > > contain the Host NAI of the AAAF2, see Figure below > > > > > > The message flow would then be the following: > > > > > > (Please view in a fixed-width font such as Courier.) > > > > > > 1.amr-> 1.amr-> > > > FA --------> AAAF1 1------------> AAAH > > > <-6.ama | ^ <-4.ama | > > > | | | ^ > > > | | | | > > > 5.dsar | |5.dsaa 2.har |3.haa > > > | | | | > > > | | V | > > > | | | > > > <-2.har v | <-2.har | > > > HA <-------- AAAF2 <---------------/ > > > 3.haa-> 3.haa-> > > > > > > Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and the > > > FA-HA Key encrypted using its digital certificate. Upon receiving the HAA > > > the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the AMA > > > the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP in > > > the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the > > > digital certificate, which the AAAF1 then would use to decrypt the FA-HA > > > Key.... > > > > > > Could this be a way forward ? > > > > Here's some thoughts, but bear in mind my limited understanding of CMS. > > > > (1) Maybe AAAF2 should initiate the security relationship with AAAF1, > > rather than the other way around. That is, AAAF2 sends the DSAR before > > responding with the HAA. My thinking here is, in the case where the AAAH > > wants to secure its generated keys with the FA, it is the sender of the > > CMS-secured data that initiates the DSAR. > > Right. Since it is the AAAF2 that will create the FA-HA Key and also the one that > will decide if the key needs to be encrypted or not. However, there is no way for > the AAAF2 to know from which domain this MN is requesting to keep the HA (the > only thing the AAAF2 know is that it has no pending AMR for this user from one of > its FAs). So, for the AAAF2 to really be able to decide if the FA-HA key needs to > be encrypted or not it needs to know the originating domain. > > So, what about introduce the following new AVP: > > Originating-Foreign-AAA ::= < AVP Header: YYY > > { Origin-Realm } // = AAAF1's realm > { Origin-Host } // = AAAF1's host-name > > > The Originating-Foreign-AAA AVP would be added in the AMR by the AAAF1 in the > case that the Home-Address-Allocatable-Only-in-Home-Realm flag are set to > zero...(i.e. in all cases when the HA is not allocated in the home domain). > > So, if the Originating-Foreign-AAA AVP is present in the AMR the AAAH must copy > it into the HAR. The AAAF2 would then have the necessary info for the above.. This seems like a good idea. > > > > > > (2) The above scheme requires the CMS big gun. In the mobile-ip draft, > > the AAAH has the option of securing its generated keys via CMS, or sending > > them in the clear. So maybe CMS should be an option for the > > AAAF2-generated key. That is, AAAF2 could send the FA-HA-Key secured (per > > your proposal), or could instead just send a plain old MIP-FA-to-HA-Key > > AVP if the AAAF2 didn't feel the need to secure the key. But it is still ok for the AAAF2 to send the plain old MIP-FA-to-HA-Key AVP if he doesn't feel the need for encryption? > > (3) In the above HAA-to-AMA-Data AVP, the diameter identity of the AAAF2 > > is provided. If the AAAF1 wants to send a DSAR to AAAF2, it might also be > > necessary to include AAAF2's realm in the HAA-to-AMA-Data AVP, so that > > AAAF1 can fill in both the Destination-Realm and Destination-Host of the > > DSAR, for routing. > > > > (4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck of name. With > > the thought of minimizing the creation of new AVPs, could we just use the > > "Origin-Host" and "Origin-Realm" AVPs as members of HAA-to-AMA-Data? The > > idea is, when "Origin-Host" and "Origin-Realm" are members of a grouped > > AVP, they represent the originator of that AVP. So AAAF2 could fill in > > his identity as the Origin-Host member of HAA-to-AMA-Data. > > > > (5) Also in the interest of not unnecessarily creating new AVPs, maybe > > just use the existing MIP-FA-to-HA-Key AVP instead of the new > > HAA-to-AMA-Data AVP. The idea here is that nowadays Diameter allows > > grouped AVPs to have variable member AVPs. So the MIP-FA-to-HA-Key AVP > > could contain different sets of member AVPs that represent either > > encrypted or non-encrypted FA-HA information. That is, the > > MIP-FA-to-HA-Key AVP could be something like: > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // non-encrypted case > > { MIP-FA-to-HA-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // encrypted case > > { Origin-Realm } // = AAAF2's realm, if necessary > > { Origin-Host } // = AAAF2's host, if necessary > > { CMS-Encrypted-Data } > > //(or {MIP-Session-Key-Material}?) > > * [ AVP ] > > > > I don't think this would be such a good idea to try to reuse that same AVP. I > think we need new grouped AVP for the encryption case since we need a completely > new set of mandatory AVPs. So what about the following: > > MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY> > { CMS-Encrypted-Data } > * [ AVP ] > > The FA-HA key would be encrypted in the CMS-Encrypted-Data AVP with AAAF1 SA. The > originator info is part of the CMS envelop-data header. So, I don't think we need > to add an Origin-Realm AVP and an Origin-Host AVP. Upon receiving the HAA the > AAAH only has to copy the MIP-Encrypted-FA-to-HA-Key AVP to the AMA back to the > AAAF1 (i.e. in the same fashion as when the FA-HA Key is distributed in clear > text, which is describe in the draft today). (1) One more worry: the key lifetime. Currently this is a single MIP-Key-Lifetime AVP which contains the lifetime that applies to all the keys. a. Retaining this notion would mean that the AAAH and AAAF2 would have to agree on the key lifetime, presumably the AAAH would specify the key lifetime and the AAAF2 would have to accept that as applying to the AAAF2-generated keys. b. Would it make sense for the AAAF2 to specify the key-lifetime for the keys that he generates? And if so, the AAAF2 could feed this information back to AAAF1/FA by including the MIP-Key-Lifetime AVP as a member of the MIP-FA-to-HA-Key/MIP-Encrypted-FA-to-HA-Key AVPs. Note that the MIP-Key-Lifetime AVP is currently disallowed in the HAA message, so if the AAAH doesn't generate any keys, the AAAF2 couldn't convey the MIP-Key-Lifetime AVP for the FA-HA key, at least not as a "standalone" (non-member) AVP. (2) Also, section 1.2 of the mobile-ip draft says: "The expiration time of the authorization (and session keys, if allocated by the AAA server) is communicated through the Authorization-Lifetime AVP in the AA-Mobile- Node-Answer from the AAAH." Now that we have the MIP-Key-Lifetime AVP, it is probably not true that the Authorization-Lifetime AVP indicates the expiration time of the session keys, right? So the sentence should be rephrased to remove the parenthesized phrase. (3) Also, the sentence in section 5.0 that mentions CMS-securing the keys should expand to include AAAH and/or AAAF2: "If the AAAH does not communicate directly with the foreign agent, and it does not wish for intermediate proxies to have access to the session keys, they SHOULD be protected using the CMS security application." > > > > > > > (6) If the AAAF2 wanted to send back a CMS-encrypted version of the FA-HA > > key, then the single AMA sent from the AAAH to AAAF1 could contain two > > sets of CMS-secured AVPs, with two different sources and destinations. > > That is, the AMA could contain FA-HA key data, CMS-secured between AAAF2 > > and AAAF1, and also could contain FA-MN key data, CMS-secured betweeen > > AAAH and FA. Can CMS/AMAs piggyback stuff this way? This is still unclear to me. I will have to talk with a coworker that understands CMS much better than me. > > > Comments please... > > > > > > Tony > > > Bob K. From owner-aaa-wg@merit.edu Fri Feb 1 14:57:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10391 for ; Fri, 1 Feb 2002 14:57:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4DC339133A; Fri, 1 Feb 2002 14:57:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B06F9133B; Fri, 1 Feb 2002 14:57:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCEE09133A for ; Fri, 1 Feb 2002 14:57:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1B865DE2E; Fri, 1 Feb 2002 14:57:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 6300B5DDA4 for ; Fri, 1 Feb 2002 14:57:37 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g11JvQS29800; Fri, 1 Feb 2002 13:57:26 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g11JvPO14544; Fri, 1 Feb 2002 13:57:25 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA08929; Fri, 1 Feb 2002 13:57:25 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA06224; Fri, 1 Feb 2002 13:57:23 -0600 (CST) Message-ID: <3C5AF2A9.84DD3B92@ericsson.com> Date: Fri, 01 Feb 2002 11:55:21 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Panagiotis-PTHOMAS1 Cc: Bob Kopacz , Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Thomas, Thomas Panagiotis-PTHOMAS1 wrote: > Hi, > > Tony Johansson wrote: > > However, there is no way for the AAAF2 to know from which domain > > this MN is requesting to keep the HA... > > I thought Destination-Realm in HAR = Originating-Realm in AMR, no? Well, in the HAR sent from the AAAH to the AAAF2, there is no info for the AAAF2 telling from which domain the MN is issuing the request. So, if the AAAF1 is in foreign1.com issuing AMR to AAAH in home.com, which then issues the HAR to AAAF2 in foreign2.com. Upon receiving the HAR the AAAF2 wouldn't know that the MN is in foriegn1.com.... > > > If AAAF1 and AAAF2 are in the same domain We still need a mechanism for the AAAF2 to know if AAAF1 is in the same domain. So, I think we need a something like the Originating-Foreign-AAA AVP. Regards, Tony From owner-aaa-wg@merit.edu Fri Feb 1 19:40:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15090 for ; Fri, 1 Feb 2002 19:40:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E14189135F; Fri, 1 Feb 2002 19:39:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A838391365; Fri, 1 Feb 2002 19:39:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2124E9135F for ; Fri, 1 Feb 2002 19:39:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 055C55DE2F; Fri, 1 Feb 2002 19:39:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id DA5FE5DDA4 for ; Fri, 1 Feb 2002 19:39:12 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id 40562400203 for ; Fri, 1 Feb 2002 16:39:12 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA06653 for ; Fri, 1 Feb 2002 16:40:01 -0800 (PST) Date: Fri, 1 Feb 2002 16:40:00 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: [AAA-WG]: HA-FA key in Mobile IP Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, Section 4.5 in the Diameter Mobile IP Application draft states: If the FA's local policy allows it to receive AAA session keys, and it it does have any exisiting keys with the HA, it may set the FA-HA-Key request flag (in the feature vector). The word "any" seems to imply that for every HA that it talks to, the FA can maintain a single key and use it whenever it communicates with that HA (irrespective of the MN involved). And to be in sync with the FA, the HA should also maintain a single HA-FA key for each FA and use it whenever it communicates with the FA (irrespective of the MN involved) At the same time, the phrase "AAA Session Key" seems to imply that the HA-FA key is session specific. That is, the FA will maintain a seperate HA-FA key for each session (MN), irrespective of whether the FA has a key to the same HA that was obtained via some other MN. Thus the HA-FA key used to create or verify the authenticator will depend on the MN in question. And to be in sync with the FA, the HA will need to maintain session specific HA-FA keys, irrespective of whether the HA has a key to the same FA that was obtained via some other MN. Thus the HA-FA key used to create or verify the authenticator will depend on the MN in question. Are both interpretations correct? If so, then it does seem possible that the implementor of the HA follows one of them and the FA implementor the other. This will lead to unnecessary authentication failures between the HA and FA, which can be prevented by making one interpretation the standard. But if only of the above interpretations is correct, I am guessing it is the first one. But can we make it more explicit? thanks! Siva From owner-aaa-wg@merit.edu Fri Feb 1 19:54:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15221 for ; Fri, 1 Feb 2002 19:54:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF0F59135D; Fri, 1 Feb 2002 19:54:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 960F491360; Fri, 1 Feb 2002 19:54:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 661139135D for ; Fri, 1 Feb 2002 19:54:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 434B25DE35; Fri, 1 Feb 2002 19:54:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 01E775DE31 for ; Fri, 1 Feb 2002 19:54:21 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g120sLh26069; Fri, 1 Feb 2002 18:54:21 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g120sLj16189; Fri, 1 Feb 2002 18:54:21 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA07600; Fri, 1 Feb 2002 18:54:20 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA12442; Fri, 1 Feb 2002 18:54:19 -0600 (CST) Message-ID: <3C5B383F.1623201D@ericsson.com> Date: Fri, 01 Feb 2002 16:52:16 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob Please find my comments embedded... Bob Kopacz wrote: > Hi Tony, > > > From: "Tony Johansson" > > To: "Bob Kopacz" > > Cc: "Mark Eklund" ; > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > Date: Wednesday, January 30, 2002 10:20 PM > > > > Hi Bob, > > > > Thanks for your comments I think we are getting somewhere here:) > > I agree. > > > please find my comments embedded... > > > > Regards, > > > > Tony > > > > Bob Kopacz wrote: > > > > > Hi Tony, > > > > > > > From: Tony Johansson [tony.johansson@ericsson.com] > > > > Sent: Monday, January 28, 2002 6:46 PM > > > > To: Bob Kopacz > > > > Cc: aaa-wg@merit.edu > > > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > > > > > > > > Hello Bob and All, > > > > > > > > I agree that it could be good to have a way of encrypting the FA-HA Key as > > > > you describe below, and even more for the case where you move through a > > > > third domain ( i.e. the AAAF1 and AAAF2 belongs to two different > networks). > > > > However, I really think that we need to find a more interoperability > > > > approve approach. I'm not sure that we just can say that the > HAA-toAMA-Data > > > > AVP is of type OctetString and may be used, to convey the FA-HA key > > > > information in some proprietary format and security method which is > > > > agreed-upon by all AAAF servers in the foreign network... > > > > > > > > You mention CMS security below and I agree, couldn't we make use of the > CMS > > > > security for this case? > > > > > > Your idea to use CMS security is probably a better idea. A proprietary > > > solution wouldn't work very well inter-realm. And using CMS is more in > > > the spirit of the mobileip-draft, > > > > > where its one comment in section 5.0 > > > about securing keys is "If the AAAH does not communicate directly with the > > > foreign agent, and it does not wish for intermediate proxies to have > > > access to the session keys, they SHOULD be protected using the CMS > > > security application." > > > > > > > > > > So, what about the following (I'm not a CMS security expert, so please > > > > correct me if this is not really possible or to complex...): > > > > > > > > Instead, make the HAA-toAMA-Data AVP of type grouped : > > > > > > > > HAA-toAMA-Data AVP ::= < AVP Header: TBD > > > > > { Originating-Foriegn-Home-Key-Distr-Host } > > > > { CMS-Encrypted-Data } > > > > * [ AVP ] > > > > > > > > The CMS-Encrypted-Data AVP would contain the FA-HA Key encrypted and the > > > > Originating-Foriegn-Home-Key-Distr-Host AVP (lack of better name:) would > > > > contain the Host NAI of the AAAF2, see Figure below > > > > > > > > The message flow would then be the following: > > > > > > > > (Please view in a fixed-width font such as Courier.) > > > > > > > > 1.amr-> 1.amr-> > > > > FA --------> AAAF1 1------------> AAAH > > > > <-6.ama | ^ <-4.ama | > > > > | | | ^ > > > > | | | | > > > > 5.dsar | |5.dsaa 2.har |3.haa > > > > | | | | > > > > | | V | > > > > | | | > > > > <-2.har v | <-2.har | > > > > HA <-------- AAAF2 <---------------/ > > > > 3.haa-> 3.haa-> > > > > > > > > Thus, the AAAF2 would create the HAA-to-AMA AVP with its Host name and the > > > > FA-HA Key encrypted using its digital certificate. Upon receiving the HAA > > > > the AAAH would add the HAA-to-AMA AVP into the AMA. Upon receipt of the > AMA > > > > the AAAF1 would identify the Originating-Foriegn-Home-Key-Distr-Host AVP > in > > > > the HAA-to-AMA AVP and issue a DSAR to the AAAF2 and request for the > > > > digital certificate, which the AAAF1 then would use to decrypt the FA-HA > > > > Key.... > > > > > > > > Could this be a way forward ? > > > > > > Here's some thoughts, but bear in mind my limited understanding of CMS. > > > > > > (1) Maybe AAAF2 should initiate the security relationship with AAAF1, > > > rather than the other way around. That is, AAAF2 sends the DSAR before > > > responding with the HAA. My thinking here is, in the case where the AAAH > > > wants to secure its generated keys with the FA, it is the sender of the > > > CMS-secured data that initiates the DSAR. > > > > Right. Since it is the AAAF2 that will create the FA-HA Key and also the one > that > > will decide if the key needs to be encrypted or not. However, there is no way > for > > the AAAF2 to know from which domain this MN is requesting to keep the HA (the > > only thing the AAAF2 know is that it has no pending AMR for this user from one > of > > its FAs). So, for the AAAF2 to really be able to decide if the FA-HA key needs > to > > be encrypted or not it needs to know the originating domain. > > > > So, what about introduce the following new AVP: > > > > Originating-Foreign-AAA ::= < AVP Header: YYY > > > { Origin-Realm } // = AAAF1's realm > > { Origin-Host } // = AAAF1's host-name > > > > > > The Originating-Foreign-AAA AVP would be added in the AMR by the AAAF1 in the > > case that the Home-Address-Allocatable-Only-in-Home-Realm flag are set to > > zero...(i.e. in all cases when the HA is not allocated in the home domain). > > > > So, if the Originating-Foreign-AAA AVP is present in the AMR the AAAH must > copy > > it into the HAR. The AAAF2 would then have the necessary info for the above.. > > This seems like a good idea. > > > > > > > > > > (2) The above scheme requires the CMS big gun. In the mobile-ip draft, > > > the AAAH has the option of securing its generated keys via CMS, or sending > > > them in the clear. So maybe CMS should be an option for the > > > AAAF2-generated key. That is, AAAF2 could send the FA-HA-Key secured (per > > > your proposal), or could instead just send a plain old MIP-FA-to-HA-Key > > > AVP if the AAAF2 didn't feel the need to secure the key. > > But it is still ok for the AAAF2 to send the plain old > MIP-FA-to-HA-Key AVP if he doesn't feel the need for encryption? For all other keys the AAAH is the KDC and will decide if those keys should be encrypted or not. So, like in this case when the AAAF2 is the KDC for the FA-HA key I don't see why we should reasoning in any other same way. Thus, it's up to the AAAF2 to decide if the FA-HA key need to be encrypted or not. > > > > > (3) In the above HAA-to-AMA-Data AVP, the diameter identity of the AAAF2 > > > is provided. If the AAAF1 wants to send a DSAR to AAAF2, it might also be > > > necessary to include AAAF2's realm in the HAA-to-AMA-Data AVP, so that > > > AAAF1 can fill in both the Destination-Realm and Destination-Host of the > > > DSAR, for routing. > > > > > > (4) "Originating-Foriegn-Home-Key-Distr-Host" is one heck of name. With > > > the thought of minimizing the creation of new AVPs, could we just use the > > > "Origin-Host" and "Origin-Realm" AVPs as members of HAA-to-AMA-Data? The > > > idea is, when "Origin-Host" and "Origin-Realm" are members of a grouped > > > AVP, they represent the originator of that AVP. So AAAF2 could fill in > > > his identity as the Origin-Host member of HAA-to-AMA-Data. > > > > > > (5) Also in the interest of not unnecessarily creating new AVPs, maybe > > > just use the existing MIP-FA-to-HA-Key AVP instead of the new > > > HAA-to-AMA-Data AVP. The idea here is that nowadays Diameter allows > > > grouped AVPs to have variable member AVPs. So the MIP-FA-to-HA-Key AVP > > > could contain different sets of member AVPs that represent either > > > encrypted or non-encrypted FA-HA information. That is, the > > > MIP-FA-to-HA-Key AVP could be something like: > > > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // non-encrypted case > > > { MIP-FA-to-HA-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > // encrypted case > > > { Origin-Realm } // = AAAF2's realm, if necessary > > > { Origin-Host } // = AAAF2's host, if necessary > > > { CMS-Encrypted-Data } > > > //(or {MIP-Session-Key-Material}?) > > > * [ AVP ] > > > > > > > I don't think this would be such a good idea to try to reuse that same AVP. I > > think we need new grouped AVP for the encryption case since we need a > completely > > new set of mandatory AVPs. So what about the following: > > > > MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY> > > { CMS-Encrypted-Data } > > * [ AVP ] > > > > The FA-HA key would be encrypted in the CMS-Encrypted-Data AVP with AAAF1 SA. > The > > originator info is part of the CMS envelop-data header. So, I don't think we > need > > to add an Origin-Realm AVP and an Origin-Host AVP. Upon receiving the HAA the > > AAAH only has to copy the MIP-Encrypted-FA-to-HA-Key AVP to the AMA back to > the > > AAAF1 (i.e. in the same fashion as when the FA-HA Key is distributed in clear > > text, which is describe in the draft today). > > (1) One more worry: the key lifetime. Currently this is a single > MIP-Key-Lifetime AVP which contains the lifetime that applies to all > the keys. > > a. Retaining this notion would mean that the AAAH and AAAF2 > would have to agree on the key lifetime, presumably the AAAH would > specify the key lifetime and the AAAF2 would have to accept that as > applying to the AAAF2-generated keys. IMHO, I think this is the right way. Since the AAAH is the owner of the MN, I don't see why we should complicate things even more by letting the AAAF2 decide on another time for the FA-HA key. > > > b. Would it make sense for the AAAF2 to specify the key-lifetime for > the keys that he generates? And if so, the AAAF2 could feed this > information back to AAAF1/FA by including the MIP-Key-Lifetime AVP > as a member of the MIP-FA-to-HA-Key/MIP-Encrypted-FA-to-HA-Key AVPs. > > Note that the MIP-Key-Lifetime AVP is currently disallowed in the > HAA message, so if the AAAH doesn't generate any keys, the AAAF2 > couldn't convey the MIP-Key-Lifetime AVP for the FA-HA key, at > least not as a "standalone" (non-member) AVP. > > (2) Also, section 1.2 of the mobile-ip draft says: > > "The expiration time of the > authorization (and session keys, if allocated by the AAA server) is > communicated through the Authorization-Lifetime AVP in the AA-Mobile- > Node-Answer from the AAAH." > > Now that we have the MIP-Key-Lifetime AVP, it is probably not true > that the Authorization-Lifetime AVP indicates the expiration time of > the session keys, right? So the sentence should be rephrased to > remove the parenthesized phrase. Yes I agree, could you please submit a new issue for this. So, we don't forget it. > > > (3) Also, the sentence in section 5.0 that mentions CMS-securing the > keys should expand to include AAAH and/or AAAF2: > > "If the AAAH does not communicate directly with the > foreign agent, and it does not wish for intermediate proxies to have > access to the session keys, they SHOULD be protected using the CMS > security application." Yes, I'm working on some proposed text, which will cover this. I hope to have the proposal ready later today. Regards, /Tony From owner-aaa-wg@merit.edu Fri Feb 1 20:35:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15851 for ; Fri, 1 Feb 2002 20:35:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38CC391230; Fri, 1 Feb 2002 20:34:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AD3491360; Fri, 1 Feb 2002 20:34:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA53F91230 for ; Fri, 1 Feb 2002 20:34:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7BBE5DDD7; Fri, 1 Feb 2002 20:34:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 836F15DDA4 for ; Fri, 1 Feb 2002 20:34:45 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g121Yih07426; Fri, 1 Feb 2002 19:34:44 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g121Yij26367; Fri, 1 Feb 2002 19:34:44 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA10855; Fri, 1 Feb 2002 19:34:44 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA13080; Fri, 1 Feb 2002 19:34:41 -0600 (CST) Message-ID: <3C5B41B6.F840604F@ericsson.com> Date: Fri, 01 Feb 2002 17:32:38 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: <3C5B383F.1623201D@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, Tony Johansson wrote: > > > > > > > But it is still ok for the AAAF2 to send the plain old > > MIP-FA-to-HA-Key AVP if he doesn't feel the need for encryption? > > For all other keys the AAAH is the KDC and will decide if those keys should be > encrypted or not. So, like in this case when the AAAF2 is the KDC for the FA-HA key > I don't see why we should reasoning in any other same way. Thus, it's up to the > AAAF2 to decide if the FA-HA key need to be encrypted or not. Hmmm, sorry for the confusing text that I just sent out in the previous mail :) What I meant to say is simply "yes" /Tony From owner-aaa-wg@merit.edu Mon Feb 4 04:33:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17277 for ; Mon, 4 Feb 2002 04:33:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6A2CF91218; Mon, 4 Feb 2002 04:32:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2478391257; Mon, 4 Feb 2002 04:32:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4241391218 for ; Mon, 4 Feb 2002 04:32:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18B0F5DDA0; Mon, 4 Feb 2002 04:32:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 617115DD8C for ; Mon, 4 Feb 2002 04:32:30 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g149WUZ19967 for ; Mon, 4 Feb 2002 11:32:30 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Feb 2002 11:32:24 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Feb 2002 11:32:22 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Feb 2002 11:32:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE Date: Mon, 4 Feb 2002 11:32:22 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF27184211FC8@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE Thread-Index: AcGq8lIzu+o684jKS6uHC8goHw5SCQCXStSw From: To: Cc: , X-OriginalArrivalTime: 04 Feb 2002 09:32:22.0759 (UTC) FILETIME=[D9512770:01C1AD5E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA17277 Hi, The purpose of this issue was to raise discussion if the Diameter accounting (as a part of the base protocol) is sufficient to meet ip multimedia requirements. The made proposal based (loosely) to drafts: draft-olsson-ip-multimedia-charging-reqs-00.txt (unfortunately missing from the reference -field) and draft-hakala-diameter-credit-control-01.txt. These two drafts includes some basic requirements and considerations which should/may also, in my estimation, affect to the base protocol accounting part. Here is my answers to your comments (I must apology that I may have 3GPP perspective): If the Diameter is going to be the charging protocol selected by the 3GPP for IP Multimedia the "estimation" is not the best possible expression. If this is interpreted literally there might be some problems to fit Diameter to 3GPP charging architecture. Overall, the proposed changes could also be seen as application-specific if wanted. But it could be useful to change also the Diameter base protocol especially the required changes are not huge ones. As the accounting part already defines Accounting-Record-Type values and the difference of the On-line and Off-line charging is described in draft-olsson-ip-multimedia-charging-reqs-00.txt, it would be consistent to have also "rest" of the Accounting-Record-Types included to accounting part of the Diameter base. Well, I might be totally wrong but at least this issue was discussed... br, JPK -----Original Message----- From: ext Bernard Aboba [mailto:aboba@internaut.com] Sent: 01. February 2002 9:14 To: Glen Zorn Cc: Koskinen Juha-Pekka (NET/Tampere); aaa-wg@merit.edu Subject: RE: [AAA-WG]: ISSUE > Ok, I'll go out on a limb here and call this a new feature (not just new, > but application-specific) and suggest that it be immediately rejected by the > WG Chairs. One of the beauties of AAA is that Accounting focusses on providing estimates of resource consumption. The usage of that information or the purpose of the transfer is immaterial, yet many types of service can still be provided. This includes prepaid, postpaid, and even unpaid (guest) service. Before this Issue will be considered, I would like to understand why this functionality cannot already be provided within the protocol as it exists. No evidence is provided in the issue report to justify the necessity of the change. Some comments below: > > The postpaid accounting session is established to transfer CDRs > > (Charging Data Records) from client to server. AAA does not transfer CDRs. It transfers binary accounting data which are used to create CDRs. > These CDRs are used for billing purposes, typically once a month. Discussion of billing practices is outside the scope of the AAA WG. > doesn't need to be completed simultaneously with the communication >session. It sounds like Diameter accounting should work just fine for this. So why is a change being proposed? > The prepaid accounting session is established to transfer > charging information from client to server for rating purposes. The reason for the transfer is not relevant to the protocol. > The cost of the communication session is calculated and according > to these calculations money is reserved from subcribers account. > If there is no credit left in subscribers account or the credit > is used during the communication session, the prepaid accounting > session will be terminated. That termination will also cause the > termination of the communication session. Seems to me that this effect could be achieved without any protocol changes. So why is a change necessary? From owner-aaa-wg@merit.edu Mon Feb 4 06:01:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18401 for ; Mon, 4 Feb 2002 06:01:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0A54791257; Mon, 4 Feb 2002 06:01:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D05B591258; Mon, 4 Feb 2002 06:00:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5B7791257 for ; Mon, 4 Feb 2002 06:00:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CA6A5DDA6; Mon, 4 Feb 2002 06:00:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id AE9BD5DD8C for ; Mon, 4 Feb 2002 06:00:57 -0500 (EST) Received: from ipunplugged.com ([213.100.60.208]) by fep02-svc.swip.net with ESMTP id <20020204110056.QGKV9420.fep02-svc.swip.net@ipunplugged.com> for ; Mon, 4 Feb 2002 12:00:56 +0100 Message-ID: <3C5E780D.9000706@ipunplugged.com> Date: Mon, 04 Feb 2002 12:01:17 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: [AAA-WG]: CMS sec 1.6 - interpretation of "MUST belong to the same realm" 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 To give more context, the section entitled "Who can authorize users" states that: ...note that one of praticipants of a DSA (specifically the one in the home network) MUST belong to the same realm as the user being authorized (the realm portion of the Network Access Identifier found in the User-Name AVP)... I suppose that the intent is not to make it impossible for an isp to serve more than one realm per server, so does this mean that the server will need an X.509 certificate for every realm it serves (as defined by having an ACTION_LOCAL route for that realm)? j From owner-aaa-wg@merit.edu Mon Feb 4 08:51:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22170 for ; Mon, 4 Feb 2002 08:51:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CFB5C9121A; Mon, 4 Feb 2002 08:51:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BAC991258; Mon, 4 Feb 2002 08:51:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DA139121A for ; Mon, 4 Feb 2002 08:51:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D61A5DDB9; Mon, 4 Feb 2002 08:51:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 896885DDB2 for ; Mon, 4 Feb 2002 08:51:20 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g14DpJC12767 for ; Mon, 4 Feb 2002 14:51:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Feb 04 14:50:54 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 14:51:18 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F946F5@efijont102> From: "Harri Hakala (LMF)" To: "'Bernard Aboba'" Cc: Glen Zorn , juha-pekka.koskinen@nokia.com, aaa-wg@merit.edu Subject: FW: [AAA-WG]: ISSUE Date: Mon, 4 Feb 2002 14:50:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I try explain why in my opinion a little more functionality is needed to support 'real time accounting'. I don't think that we need to add any new accounting record types to the protocol to provide this support, only a few additional AVPs are needed. I have used definitions 'non real time accounting' and 'real time accounting' and I mean by this: Non real time accounting: the collecting information on resource usage, so that the collecting information does not affect, in real time, the service rendered. Real time accounting: the collecting information on resource usage, so that the collecting information can affect, in real time, the service rendered and therefore directly interacts with the session/service control. To support real time accounting (or credit control or prepaid or..) the first accounting message MUST be sent before the accounting client allows any service to the end user. This is allowed according to base protocol (or ?) but there is need for statement that if real time accounting will be used the initial accounting message must be sent and its response must be received before service is offered to the end user. There services which can use different kind of accounting controlling units. Some services can be charged based on used time or data volume. There is also services which can be charged based on number of events or amount of money. Client needs provide information what kind of units (time, volume, event, money ...) it will use and the amount of the needed units in initial accounting message. I think that this information is missing from the base protocol accounting, if real time accounting is required. There is need for a new AVP (Service Unit Type), which contains the requested unit type and possibly also the requested unit amount. The Accounting Server should then inform the client when it must send next accounting message (either INTERIM or STOP) This is supported already now in base protocol, but there is need some minor improvements. The Accounting-Interim-Interval AVP from the base protocol with improvements (defining the Unit type) can be used for this, or it is also possible to use a new AVP, Granted-Service-Unit. This AVP contains the amount of units that the Client can provide to the end user until a new Accounting Request must be sent. If the returned Granted-Service-Unit contains the final units for the service (i.e. no more credit left), an indication must be returned to client that after these units have expired, the Client is responsible for terminating the service and sending the final accounting record (STOP) to accounting server. To able to support real time accounting we need to add a new AVP (Final-Unit-Indication AVP) to Answer command to indicate that the answer command contains the final units for the service. In my opinion this is missing from the base protocol. Also to be able to support real-time accounting the interim accounting information must be non-cumulative. This purpose a new AVP is needed to accounting request commands, Used-Service-Unit. This AVP contains the amount of used units since the previous Accounting-answer command. By adding these new AVPs to Diameter accounting it will support both non real time and real time accounting. An option is also to create a diameter application that can be used for real time cost and credit control. We have made a proposal for this kind of application, called Diameter Credit Control Application. http://search.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-01.txt In this draft also previous mentioned AVPs are defined. Best Regards......Harri -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: 1. helmikuuta 2002 9:14 To: Glen Zorn Cc: juha-pekka.koskinen@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: ISSUE > Ok, I'll go out on a limb here and call this a new feature (not just new, > but application-specific) and suggest that it be immediately rejected by the > WG Chairs. One of the beauties of AAA is that Accounting focusses on providing estimates of resource consumption. The usage of that information or the purpose of the transfer is immaterial, yet many types of service can still be provided. This includes prepaid, postpaid, and even unpaid (guest) service. Before this Issue will be considered, I would like to understand why this functionality cannot already be provided within the protocol as it exists. No evidence is provided in the issue report to justify the necessity of the change. Some comments below: > > The postpaid accounting session is established to transfer CDRs > > (Charging Data Records) from client to server. AAA does not transfer CDRs. It transfers binary accounting data which are used to create CDRs. > These CDRs are used for billing purposes, typically once a month. Discussion of billing practices is outside the scope of the AAA WG. > doesn't need to be completed simultaneously with the communication >session. It sounds like Diameter accounting should work just fine for this. So why is a change being proposed? > The prepaid accounting session is established to transfer > charging information from client to server for rating purposes. The reason for the transfer is not relevant to the protocol. > The cost of the communication session is calculated and according > to these calculations money is reserved from subcribers account. > If there is no credit left in subscribers account or the credit > is used during the communication session, the prepaid accounting > session will be terminated. That termination will also cause the > termination of the communication session. Seems to me that this effect could be achieved without any protocol changes. So why is a change necessary? From owner-aaa-wg@merit.edu Mon Feb 4 09:16:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22907 for ; Mon, 4 Feb 2002 09:16:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFCD891258; Mon, 4 Feb 2002 09:16:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF9C491259; Mon, 4 Feb 2002 09:16:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7691491258 for ; Mon, 4 Feb 2002 09:16:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E5125DDB6; Mon, 4 Feb 2002 09:16:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id BA1E05DDB2 for ; Mon, 4 Feb 2002 09:16:43 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g14EGgU23077 for ; Mon, 4 Feb 2002 14:16:42 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Mon, 4 Feb 2002 14:12:05 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA28978; Mon, 4 Feb 2002 14:16:40 GMT Message-ID: <3C5E980E.2E6F6289@baltimore.ie> Date: Mon, 04 Feb 2002 14:17:50 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: aaa-wg Subject: Re: [AAA-WG]: CMS sec 1.6 - interpretation of "MUST belong to the same realm" References: <3C5E780D.9000706@ipunplugged.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Quoting a bit more from 1.6: "The realm of the participants is found in the subjectAltName field of the Diameter server's X.509 certificate." subjectAltName is an ASN.1 "SEQUENCE OF" - the result is that a single certificate can include many names, from the same or different realms. All you need to do is find a single CA that'll create such a certificate, but that's out of scope of Diameter (though not, I believe, a big deal technically). Anything in the draft to the contrary would, IMHO, be a bug. Stephen. Johan Johansson wrote: > > To give more context, the section entitled "Who can authorize users" > states that: > > ...note that one of praticipants of a DSA (specifically the one in the > home network) MUST belong to the same realm as the user being authorized > (the realm portion of the Network Access Identifier found in the > User-Name AVP)... > > I suppose that the intent is not to make it impossible for an isp to > serve more than one realm per server, so does this mean that the server > will need an X.509 certificate for every realm it serves (as defined by > having an ACTION_LOCAL route for that realm)? > > j -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Mon Feb 4 14:22:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03638 for ; Mon, 4 Feb 2002 14:22:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25C2E91201; Mon, 4 Feb 2002 14:22:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EBF5C9125C; Mon, 4 Feb 2002 14:22:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EDCD891201 for ; Mon, 4 Feb 2002 14:22:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D31415DDD1; Mon, 4 Feb 2002 14:22:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id F2BB25DDCE for ; Mon, 4 Feb 2002 14:22:32 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g14JMWC08847; Mon, 4 Feb 2002 20:22:32 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g14JMUr6004691; Mon, 4 Feb 2002 21:22:30 +0200 (EET) Message-ID: <3C5EDF76.28D75A9E@lmf.ericsson.se> Date: Mon, 04 Feb 2002 21:22:30 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references References: <200201291942.OAA05013@knox6039.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Mark Eklund wrote: > > When Jari did the work of determining Normative vs Informative, he > couldn't find the following references referenced in the body of the > base draft. Do we leave them in, or drop them from the base? > > My vote, drop 4, 5, 6, 14, and 19 from the base (keep in CMS if it > makes sense). I have no opinion on 39, and 48. > No mention in the draft. > [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. > 677-680. > > No mention in the draft. > [48] P. V. Mockapetris, "Domain names - implementation and specifica- > tion," RFC 1035, November 1987. 39 should simply be dropped. There isn't even a title... 48 might fit to the dns discovery part on the first mention of DNS... Jari From owner-aaa-wg@merit.edu Mon Feb 4 14:46:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04221 for ; Mon, 4 Feb 2002 14:46:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AAF59125D; Mon, 4 Feb 2002 14:45:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E8CC9125E; Mon, 4 Feb 2002 14:45:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C5559125D for ; Mon, 4 Feb 2002 14:45:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BB575DDD2; Mon, 4 Feb 2002 14:45:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id E891E5DDCE for ; Mon, 4 Feb 2002 14:45:30 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g14JYNa23578 for ; Mon, 4 Feb 2002 14:34:23 -0500 Message-ID: <3C5EE23E.4AC00CB5@interlinknetworks.com> Date: Mon, 04 Feb 2002 14:34:22 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Why include transport-security in DiameterIdentity? Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id OAA04221 transport-security ("none" or "TLS") was added to the DiameterIdentity octetstring in the latest draft of the Diameter base protocol. Why was this added? The text below is from section 4.4: Since multiple Diameter processes on a single host cannot listen for incoming connections on the same port on a given protocol, the DiameterIdentity of any process is guaranteed to be unique. The FQDN, port, and transport fields in the DiameterIdentity already uniquely identify a specific Diameter process running on a host. Isn't the purpose of the DiameterIdentity to uniquely identify a Diameter node (and not to provide additional information about connections)? Section 4.4 also states: Unless a Diameter node is sitting on the border of two routing domains (e.g. private and public), a Diameter node MUST advertise the same identity on all connections... If a Diameter node MUST advertise the same identity on all connections and it supports TLS and non-TLS connections, what should it advertise for transport-security? Please tell me why we're better off with transport-security of none or TLS included in the DiameterIdentity. Thanks, Don From owner-aaa-wg@merit.edu Mon Feb 4 16:46:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06590 for ; Mon, 4 Feb 2002 16:46:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 61A499125C; Mon, 4 Feb 2002 16:46:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B5B691260; Mon, 4 Feb 2002 16:46:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9998F9125C for ; Mon, 4 Feb 2002 16:46:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 773F95DDC4; Mon, 4 Feb 2002 16:46:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id D2CA15DD9F for ; Mon, 4 Feb 2002 16:46:04 -0500 (EST) Received: from ipunplugged.com ([213.100.60.208]) by fep04-svc.swip.net with ESMTP id <20020204214603.CRMA21921.fep04-svc.swip.net@ipunplugged.com> for ; Mon, 4 Feb 2002 22:46:03 +0100 Message-ID: <3C5F0F40.3060709@ipunplugged.com> Date: Mon, 04 Feb 2002 22:46:24 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: Re: [AAA-WG]: Why include transport-security in DiameterIdentity? References: <3C5EE23E.4AC00CB5@interlinknetworks.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 There was an attempt at discussing this a couple of months ago but the discussion just fizzled. Personally I agree with you completely. I think the opposing view was that with the transport parameter you would need no additional configuration to contact a diameter node. If you are not allowed to advertise more than one uri an entire either all nodes in a diameter network use TLS or no nodes do. TLS or not is IMO a property of a connection between two nodes and not inherent in the node itself. j Don Zick wrote: >transport-security ("none" or "TLS") was added to the DiameterIdentity >octetstring in the latest draft of the Diameter base protocol. Why was >this added? The text below is from section 4.4: > > Since multiple Diameter processes on a single host cannot > listen for incoming connections on the same port on a given > protocol, the DiameterIdentity of any process is guaranteed to > be unique. > >The FQDN, port, and transport fields in the DiameterIdentity already >uniquely identify a specific Diameter process running on a host. Isn't >the purpose of the DiameterIdentity to uniquely identify a Diameter node >(and not to provide additional information about connections)? > >Section 4.4 also states: > > Unless a Diameter node is sitting on the border of two routing > domains (e.g. private and public), a Diameter node MUST > advertise the same identity on all connections... > >If a Diameter node MUST advertise the same identity on all connections >and it supports TLS and non-TLS connections, what should it advertise >for transport-security? > >Please tell me why we're better off with transport-security of none or >TLS included in the DiameterIdentity. > >Thanks, >Don > From owner-aaa-wg@merit.edu Mon Feb 4 17:01:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06804 for ; Mon, 4 Feb 2002 17:01:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 316C391260; Mon, 4 Feb 2002 17:00:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F366291261; Mon, 4 Feb 2002 17:00:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 57A1391260 for ; Mon, 4 Feb 2002 17:00:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E0265DDDC; Mon, 4 Feb 2002 17:00:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id AA82B5DDC4 for ; Mon, 4 Feb 2002 17:00:45 -0500 (EST) Received: (qmail 13244 invoked by uid 507); 4 Feb 2002 22:00:42 -0000 Date: Mon, 4 Feb 2002 16:00:40 -0600 From: David Frascone To: Don Zick Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Why include transport-security in DiameterIdentity? Message-ID: <20020204220040.GB12431@newman.frascone.com> Mail-Followup-To: Don Zick , aaa-wg@merit.edu References: <3C5EE23E.4AC00CB5@interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C5EE23E.4AC00CB5@interlinknetworks.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk I think it's even a bigger problem than that. When you advertise your diameter identity, do you always use the parameters based on how the connection was made? It seems a little redundant. For example: A peer connects to another server via tcp w/o TLS. Do you advertise your tcp parameters? Or tls or sctp? If not, then why send your diameter identity at all? The server knows how to connect to you. With the exception of the port, all that is already included in the message. Perhaps you should be allowed to list several Origin-Host fields in some order of priority? That way, you could advertise all your possible contact scenarios, and peers could choose to re-connect with a more appropriate connection. i.e. Original connection via tcp, new connection via SCTP with TLS enabled. On Monday, 04 Feb 2002, Don Zick wrote: > transport-security ("none" or "TLS") was added to the DiameterIdentity > octetstring in the latest draft of the Diameter base protocol. Why was > this added? The text below is from section 4.4: > > Since multiple Diameter processes on a single host cannot > listen for incoming connections on the same port on a given > protocol, the DiameterIdentity of any process is guaranteed to > be unique. > > The FQDN, port, and transport fields in the DiameterIdentity already > uniquely identify a specific Diameter process running on a host. Isn't > the purpose of the DiameterIdentity to uniquely identify a Diameter node > (and not to provide additional information about connections)? > > Section 4.4 also states: > > Unless a Diameter node is sitting on the border of two routing > domains (e.g. private and public), a Diameter node MUST > advertise the same identity on all connections... > > If a Diameter node MUST advertise the same identity on all connections > and it supports TLS and non-TLS connections, what should it advertise > for transport-security? > > Please tell me why we're better off with transport-security of none or > TLS included in the DiameterIdentity. > > Thanks, > Don > From owner-aaa-wg@merit.edu Mon Feb 4 17:55:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07694 for ; Mon, 4 Feb 2002 17:55:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B1EC91261; Mon, 4 Feb 2002 17:55:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4904391262; Mon, 4 Feb 2002 17:55:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05F9C91261 for ; Mon, 4 Feb 2002 17:55:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF5CB5DDA5; Mon, 4 Feb 2002 17:55:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 7DC735DD9F for ; Mon, 4 Feb 2002 17:55:08 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g14Mt0h19964; Mon, 4 Feb 2002 16:55:00 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g14MsxC11154; Mon, 4 Feb 2002 16:54:59 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA12522; Mon, 4 Feb 2002 16:54:59 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA19425; Mon, 4 Feb 2002 16:54:58 -0600 (CST) Message-ID: <3C5F10C4.F06A184@ericsson.com> Date: Mon, 04 Feb 2002 14:52:52 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: Thomas Panagiotis-PTHOMAS1 , Bob Kopacz , Mark Eklund Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: <3C5AF2A9.84DD3B92@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here is proposed text for the handling of the FA-HA Key based on the discussion last week. Comments, please... Regards, /Tony ----------------------------------------------------------------------------------- * New text to section - 1.4 Allocation of Home Agent in Foreign Network "The Diameter Mobile IP application allows a Home Agent to be allocated in a foreign network, as required in [3, 16]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent- Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero. When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-Agent-Host AVP contains the identity of the home agent that would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. In the event that the mobile node requests a home agent in the foreign network, and the AAAF authorizes its use, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. This could happen when the AAA request is sent to "extend" a mobile node's current session. When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a home agent for the mobile node, then the AAAH must decide whether its local policy would allow the user to have a Home Agent in the foreign network. If so, and after checking authorization from the data in the AMR message, the AAAH sends the HAR message to the AAAF that does not contain the MIP-Home-Agent-Address, but includes the Destination-Host AVP set to the value of the AMR's MIP-Candidate-Home-Agent-Host AVP. If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the AAAH back to the foreign realm will not necessarily be received by the same AAAF which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message to the HAR message. In cases when another AAAF, which may not reside in the same domain, receives the HAR, thus the new AAAF will use the MIP-Originating-Foreign-AAA-AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not." * Section 2.1 and section 2.3, add [ MIP-Originating-Foreign-AAA ] to ABNF * Section 2.2 and 2.4, add [ MIP-Encrypted-FA-to-HA-Key ] to ABNF * Add MIP-Originating-Foreign-AAA in section 4 as: "4.11 MIP-Originating-Foreign-AAA AVP The MIP-Originating-Foreign-AAA AVP (AVP Code ZZZ) if of type Grouped, and contains the identity of the AAAF which issues the AMR to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If present in the AMR, the AAAH MUST copy the MIP-Originating-Foreign-AAA AVP into the HAR. MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > { Origin-Realm } { Origin-Host } * [ AVP ]" * New text to section - 5.4 Distributing the Foreign-Home Session Key " If the home agent is in the home realm, then the AAAH has to generate the Foreign-Home session key. Otherwise, it is generated by AAAF. In the cases when the AAAH generates the Foreign-Home session key, the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and includes the AVP as part of the HAR message sent to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAH until the HAA is received. Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, allocates an SPI to be used with the key. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. In the cases when the AAAF generates the Foreign-Home session key (home agent in foreign domain), the AAAF will, upon receipt of the HAR message, generate the Foreign-Home session key and include the session key in the MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAF until the HAA is received. Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the Foreign-Home session key destined for the foreign agent needs to be encrypted. If the session key needs to be encrypted, the AAAF will include a MIP-Encrypted-FA-to-HA Key AVP, which will include the MIP-FA-to-HA Key AVP, protected using the CMS application [9] with the AAAF as originator and the recipient copied from the MIP-Originating-Foreign-AAA AVP. The MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the originator and the recipient supports the CMS application. Upon reception of the HAA, the AAAH will copy the MIP-FA-to-HA Key AVP or the MIP-Encrypted-FA-to-HA Key AVP into the AMA. If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, the AAAF MUST decrypt the AVP using the CMS application [9]. If a Foreign-Home session key was present in the AMA, the foreign agent MUST include the Mobile-Foreign authentication extension in the Registration Reply, using the newly distributed key. " * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as: " 6.3 MIP-Encrypted-FA-to-HA-Key AVP The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped, and contains the Foreign Agent's session key encrypted in a CMS- Encrypted-Data AVP [9]. Its Data field has the following ABNF grammar: MIP-FA-to-HA-Key ::= < AVP Header: YYY > { CMS-Encrypted-Data } * [ AVP ] " From owner-aaa-wg@merit.edu Mon Feb 4 18:03:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07847 for ; Mon, 4 Feb 2002 18:03:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2508591262; Mon, 4 Feb 2002 18:02:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E510991263; Mon, 4 Feb 2002 18:02:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F94A91262 for ; Mon, 4 Feb 2002 18:02:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C5575DDCE; Mon, 4 Feb 2002 18:02:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id D821D5DDA5 for ; Mon, 4 Feb 2002 18:02:34 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g14MjWa24639; Mon, 4 Feb 2002 17:45:32 -0500 Message-ID: <3C5F0F0B.499929F4@interlinknetworks.com> Date: Mon, 04 Feb 2002 17:45:31 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson , aaa-wg Subject: Re: [AAA-WG]: Why include transport-security in DiameterIdentity? References: <3C5EE23E.4AC00CB5@interlinknetworks.com> <3C5F0F40.3060709@ipunplugged.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id SAA07847 Thanks for some explanation of the rationale for adding transport-security. I hadn't thought of 'discovering' a Diameter node by examining its DiameterIdentity. Section 5.2 of the base draft (Diameter Peer Discovery) describes a variety of ways in which a Diameter node can discover its peers. The base draft does not to my knowledge suggest that peers can be discovered by examining DiameterIdentity strings that are seen by a Diameter node. Given that there are other (better) ways to discover peers, I think that the protocol can be simplified by removing transport-security from the DiameterIdentity. The DiameterIdentity can then simply be used to uniquely identify a Diameter node. Johan Johansson wrote: > There was an attempt at discussing this a couple of months ago but the > discussion just fizzled. Personally I agree with you completely. I think > the opposing view was that with the transport parameter you would need > no additional configuration to contact a diameter node. > > If you are not allowed to advertise more than one uri an entire either > all nodes in a diameter network use TLS or no nodes do. TLS or not is > IMO a property of a connection between two nodes and not inherent in the > node itself. > > j > > Don Zick wrote: > > >transport-security ("none" or "TLS") was added to the DiameterIdentity > >octetstring in the latest draft of the Diameter base protocol. Why was > >this added? The text below is from section 4.4: > > > > Since multiple Diameter processes on a single host cannot > > listen for incoming connections on the same port on a given > > protocol, the DiameterIdentity of any process is guaranteed to > > be unique. > > > >The FQDN, port, and transport fields in the DiameterIdentity already > >uniquely identify a specific Diameter process running on a host. Isn't > >the purpose of the DiameterIdentity to uniquely identify a Diameter node > >(and not to provide additional information about connections)? > > > >Section 4.4 also states: > > > > Unless a Diameter node is sitting on the border of two routing > > domains (e.g. private and public), a Diameter node MUST > > advertise the same identity on all connections... > > > >If a Diameter node MUST advertise the same identity on all connections > >and it supports TLS and non-TLS connections, what should it advertise > >for transport-security? > > > >Please tell me why we're better off with transport-security of none or > >TLS included in the DiameterIdentity. > > > >Thanks, > >Don > > From owner-aaa-wg@merit.edu Mon Feb 4 23:06:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13441 for ; Mon, 4 Feb 2002 23:06:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DCC5491220; Mon, 4 Feb 2002 23:06:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B0CC891221; Mon, 4 Feb 2002 23:06:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A47DC91220 for ; Mon, 4 Feb 2002 23:06:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 871E25DDC3; Mon, 4 Feb 2002 23:06:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 6E7E45DDB2 for ; Mon, 4 Feb 2002 23:06:08 -0500 (EST) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id 57E2A7A; Mon, 4 Feb 2002 23:06:07 -0500 (EST) Message-ID: <000401c1adfa$6ab412e0$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Tony Johansson" , Cc: "Thomas Panagiotis-PTHOMAS1" , "Mark Eklund" References: <3C5AF2A9.84DD3B92@ericsson.com> <3C5F10C4.F06A184@ericsson.com> Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Mon, 4 Feb 2002 23:05:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's a little feedback. > From: "Tony Johansson" > To: > Cc: "Thomas Panagiotis-PTHOMAS1" ; > "Bob Kopacz" ; > "Mark Eklund" > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA > Date: Monday, February 04, 2002 5:55 PM > > All, > > Here is proposed text for the handling of the FA-HA Key based on the discussion > last week. > > Comments, please... > > Regards, > > /Tony > > ----------------------------------------------------------------------------------- > > * New text to section - 1.4 Allocation of Home Agent in Foreign Network > > "The Diameter Mobile IP application allows a Home Agent to be allocated in a > foreign network, as required in [3, 16]. When a foreign agent detects that the > mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in > the Registration Request message, it MUST add a MIP-Feature-Vector AVP with > the Home-Agent- Requested flag set to one. If the home agent address is equal > to 255.255.255.255, then the foreign agent also MUST set the > Home-Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the > Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the Home-Agent-Requested flag set > to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, > the AAAF MAY set the Foreign-Home-Agent-Available flag in the > MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign > a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the > MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The > MIP-Candidate-Home-Agent-Host AVP contains the identity of the home agent that > would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > contains the identity of the AAAF. > > In the event that the mobile node requests a home agent in the foreign network, > and the AAAF authorizes its use, the AAAF MUST set the > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. This could > happen when the AAA request is sent to "extend" a mobile node's current > session. > > When the AAAH receives an AMR message, it first checks the authentication data > supplied by the mobile node, according to the MIP-Reg-Request AVP and > MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If > the AMR indicates that the AAAF has offered to allocate a home agent for the > mobile node, then the AAAH must decide whether its local policy would allow > the user to have a Home Agent in the foreign network. If so, and after checking > authorization from the data in the AMR message, the AAAH sends the HAR message > to the AAAF that does not contain the MIP-Home-Agent-Address, but includes the > Destination-Host AVP set to the value of the AMR's > MIP-Candidate-Home-Agent-Host AVP. > > If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the > AAAH back to the foreign realm will not necessarily be received by the same > AAAF which sent the AMR. Therefore the AAAH MUST always copy the > MIP-Originating-Foreign-AAA-AVP from the AMR message to the HAR message. In > cases when another AAAF, which may not reside in the same domain, receives the > HAR, thus the new AAAF will use the MIP-Originating-Foreign-AAA-AVP for policy > decisions, such as determining if the FA-HA Key should be encrypted or not." > > > * Section 2.1 and section 2.3, add [ MIP-Originating-Foreign-AAA ] to ABNF > > * Section 2.2 and 2.4, add [ MIP-Encrypted-FA-to-HA-Key ] to ABNF > > * Add MIP-Originating-Foreign-AAA in section 4 as: > > "4.11 MIP-Originating-Foreign-AAA AVP > > The MIP-Originating-Foreign-AAA AVP (AVP Code ZZZ) if of type > Grouped, and contains the identity of the AAAF which issues the AMR > to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used in > cases when the home agent is or may be allocated in a foreign domain. If > present > in the AMR, the AAAH MUST copy the MIP-Originating-Foreign-AAA AVP > into the HAR. > > MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > > { Origin-Realm } > { Origin-Host } > * [ AVP ]" > > > * New text to section - 5.4 Distributing the Foreign-Home Session Key > > " If the home agent is in the home realm, then the AAAH has to generate the > Foreign-Home session key. Otherwise, it is generated by AAAF. > > In the cases when the AAAH generates the Foreign-Home session key, the AAAH > includes the session key in the MIP-HA-to-FA-Key AVP, and includes the AVP as > part of the HAR message sent to the home agent. The corresponding session key > that is to be sent to the foreign agent is cached in the AAAH until the HAA is > received. > > Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, > allocates an SPI to be used with the key. The allocated SPI is included in the > HAA's MIP-FA-to-HA SPI AVP. > > Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, using the SPI > in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. > > In the cases when the AAAF generates the Foreign-Home session key (home agent > in foreign domain), the AAAF will, upon receipt of the HAR message, generate > the Foreign-Home session key and include the session key in the > MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent. > The corresponding session key that is to be sent to the foreign agent is cached > in the AAAF until the HAA is received. You may want to mention that it is the AAAH that decides the key lifetime for all of the keys, even if the FA-HA key is generated by the destination AAAF. > Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, using the > SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the Foreign-Home session > key destined for the foreign agent needs to be encrypted. > > If the session key needs to be encrypted, the AAAF will include a > MIP-Encrypted-FA-to-HA Key AVP, which will include the MIP-FA-to-HA Key AVP, > protected using the CMS application [9] with the AAAF as originator and the > recipient copied from the MIP-Originating-Foreign-AAA AVP. The > MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the originator and the > recipient supports the CMS application. (1) How does the destination AAAF know if the origin AAAF supports the CMS application? It seems there are two ways: (a) When the destination AAAF sends his DSAR, it is unsuccessful, or (b) the origin AAAF can signal that it doesn't support the CMS security application by NOT sending the MIP-Originating-Foreign-AAA AVP, thus not inviting a DSA. (2) However, since both of the AAAFs are servers, isn't it a requirement that they support the CMS application? Section 1 "Introduction" of the CMS draft says that "Diameter servers: MUST support DSA messages; MAY support PDS messages" (3) In order to allow the two AAAF's to set up a security assocation, the CMS draft needs a minor editing change, to remove a restriction. Section 1.6 "Who can authorize users" of the CMS security draft says that "However, it is important to note that one of participants of a DSA (specifically the one in the home network) MUST belong to the same realm as the user being authorized (the realm portion of the Network Access Identifier found in the User-Name AVP), otherwise an answer is returned with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED." Neither of the AAAFs is in the home realm, but my understanding is that CMS would still work. (4) Did you want to say that the AAAF, after receiving the HAA from the HA but before sending the HAA to the AAAH, sets up the DSA with the originating AAAF, if the FA-HA key needs to be encrypted? > Upon reception of the HAA, the AAAH will copy the MIP-FA-to-HA Key AVP or the > MIP-Encrypted-FA-to-HA Key AVP into the AMA. > > If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, the AAAF MUST > decrypt the AVP using the CMS application [9]. > > If a Foreign-Home session key was present in the AMA, the foreign agent MUST > include the Mobile-Foreign authentication extension in the Registration Reply, > using the newly distributed key. " > > > * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as: > > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped, > and contains the Foreign Agent's session key encrypted in a CMS- > Encrypted-Data AVP [9]. Its Data field has the following ABNF > grammar: > > MIP-FA-to-HA-Key ::= < AVP Header: YYY > ^^^^^^^^^^^^^^^^ MIP-Encrypted-FA-to-HA-Key > { CMS-Encrypted-Data } > * [ AVP ] " > > > > > From owner-aaa-wg@merit.edu Tue Feb 5 08:44:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29568 for ; Tue, 5 Feb 2002 08:44:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 34DA391210; Tue, 5 Feb 2002 08:44:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AE0C91224; Tue, 5 Feb 2002 08:44:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0CC4191210 for ; Tue, 5 Feb 2002 08:44:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEF2C5DDE1; Tue, 5 Feb 2002 08:44:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 55F2C5DDA3 for ; Tue, 5 Feb 2002 08:44:02 -0500 (EST) Received: (qmail 20422 invoked by uid 507); 5 Feb 2002 13:44:01 -0000 Date: Tue, 5 Feb 2002 07:43:59 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: DNS SRV Issues Message-ID: <20020205134359.GA20249@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk In draft-ietf-aaa-diameter-08.txt, Section 5.2, item 3, it defines how to use DNS SRV to lookup diameter peers. However, there is no way to specify security when locating a peer. (And, you need to know in advance if the peer is using TLS). So, I prepose the following text be added to the base draft to clarify using DNS SRV. _diameter._tls_sctp.domain.org _diameter._tls_tcp.domain.org Right now, there is just: _diameter._tcp.domain.org _diameter._sctp.domain.org I have not looked into CMS closely, but there might be more additions for CMS. Since IPSEC is done at the ip layer, I think we can ignore that. (The tunnel has to be set up by administrators prior to any connections being made) Later, -Dave From owner-aaa-wg@merit.edu Tue Feb 5 10:04:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02566 for ; Tue, 5 Feb 2002 10:04:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A961F91269; Tue, 5 Feb 2002 10:04:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 753859126A; Tue, 5 Feb 2002 10:04:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B85291269 for ; Tue, 5 Feb 2002 10:04:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68F8A5DDF3; Tue, 5 Feb 2002 10:04:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 318C25DDEF for ; Tue, 5 Feb 2002 10:04:15 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B8E707A; Tue, 5 Feb 2002 10:04:14 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , Cc: "Thomas Panagiotis-PTHOMAS1" , "Mark Eklund" Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Tue, 5 Feb 2002 10:03:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C5F10C4.F06A184@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, A few more comments. Again bear in mind my CMS limitations. > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped, > and contains the Foreign Agent's session key encrypted in a CMS- > Encrypted-Data AVP [9]. Its Data field has the following ABNF > grammar: > > MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY > > { CMS-Encrypted-Data } > * [ AVP ] " > > (1) I think the way that CMS works is that the CMS-Encrypted-Data AVP is a standalone AVP (not a member of a grouped AVP). When the destination decrypts the CMS-Encrypted-Data AVP, one or more AVPs are revealed. In this case, when the originating AAAF decrypts the CMS-Encrypted-Data AVP, he will find a MIP-FA-to-HA-Key AVP. So instead of returning a MIP-Encrypted-FA-to-HA-Key AVP in the HAA, the destination AAAF would return a CMS-Encrypted-Data AVP. (2) Therefore do we even need the new MIP-Encrypted-FA-to-HA-Key AVP? The only reason I can think of why we might need it would be this: I have a recollection (which may be wrong so I may be all wet here) that CMS pre-defines which AVPs are to be encrypted and which are not. If so, then we might need a MIP-Encrypted-FA-to-HA-Key AVP, but its member AVPs would be the same as the MIP-FA-to-HA-Key AVP. The rule would be that the MIP-FA-to-HA-Key AVP wouldn't be encrypted, and the MIP-Encrypted-FA-to-HA-Key AVP would be encrypted. But I'd rather not have to manufacture a AVP for this purpose, I'd rather have the originating AAAF decrypt the CMS-Encrypted-Data AVP and say "Gosh, look, a MIP-FA-to-HA-Key AVP, I know just what to do with this". (3) In the case where the originating AAAF and the destination AAAF are the same server, and the AAAF wants to encrypt the FA-HA-key, then the same mechanism would be used to return the encrypted key to himself, but the setup of the security association with himself could be skipped. That is, the destination AAAF would encrypt the FA-HA-key with his public key in the HAA, and the originating (same) AAAF would decrypt the FA-HA-key with his private key. True? (4) The node which sends the CMS-Encrypted-Data (destination AAAF) is not the same as the node which originates the AMA (AAAH). Are there any assumptions/requirements in CMS that the originator of a message's CMS-Encrypted-Data AVP be the same as the originator of the message? Bob K. From owner-aaa-wg@merit.edu Tue Feb 5 10:45:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04808 for ; Tue, 5 Feb 2002 10:45:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 345EA9126D; Tue, 5 Feb 2002 10:44:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 044B49126F; Tue, 5 Feb 2002 10:44:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E61B69126D for ; Tue, 5 Feb 2002 10:44:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id C2F005DDB8; Tue, 5 Feb 2002 10:44:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by segue.merit.edu (Postfix) with ESMTP id 8B6825DDB0 for ; Tue, 5 Feb 2002 10:44:43 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g15Fibr28806; Tue, 5 Feb 2002 10:44:39 -0500 Message-Id: <200202051544.g15Fibr28806@minotaur.nge.isi.edu> To: David Frascone Cc: aaa-wg@merit.edu Reply-To: mankin@isi.edu Subject: Re: [AAA-WG]: DNS SRV Issues - More of them In-reply-to: Your message of Tue, 05 Feb 2002 07:43:59 -0600. <20020205134359.GA20249@newman.frascone.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 05 Feb 2002 10:44:37 -0500 From: Allison Mankin Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, David, Good issues! The SRV text in the Diameter base was modeled on SRV text that had been reviewed for SIP by the IESG. However, a re-review of sip-srv has caused major changes. SIP and Diameter are the first major uses of SRV to try to get published, so there's some discovery of the issues going on by the ADs too. A new sip draft contains the results of the new review. The algorithm is to use a NAPTR lookup (RFC 2915) to get the transport service and then use SRV on the NAPTR result to get a choice of servers ready to provide that srevice. I am sure the IESG will require a version of this from Diameter as well. It has been reviewed by the DNS folks in IESG and found satisfactory. It is draft-ietf-sip-srv-04.txt. sip-srv includes TLS(tcp) as a transport in the NAPTR design, but several of us have pointed out that this is insecure. The problem is the ease of bid-down from TLS use to use of an unsecured transport. DNSSEC is not out there, and will only deploy slowly. It is too easy for the reply from the DNS to be altered so that TLS is not chosen by the client. This is an insecure way to treat the TLS secure channel. So they have just gotten my AD comments about changing to another approach - it also involves the question of the special TLS port. It turns out that this usage is not accepted by IESG (though not for security reasons) and so my guidance to Pat earlier that it was fine was not correct. I suggest to Diameter (as well as SIP) a form of same-port TLS use where the URI provides the reference integrity: sips: in the SIP case. There is a TLS issue with failovers too - there does needs to be memory in the packets that TLS was in use and required for that hop, so that a TLS connection can be tried during a failover...from both directions for the hop. Allison From owner-aaa-wg@merit.edu Tue Feb 5 13:46:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13344 for ; Tue, 5 Feb 2002 13:46:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64C9991277; Tue, 5 Feb 2002 13:45:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C88491279; Tue, 5 Feb 2002 13:45:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0A07D91277 for ; Tue, 5 Feb 2002 13:45:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id DDEC65DDE8; Tue, 5 Feb 2002 13:45:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id BAD375DD99 for ; Tue, 5 Feb 2002 13:45:34 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA29141 for ; Tue, 5 Feb 2002 11:45:32 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA03366 for ; Tue, 5 Feb 2002 11:45:31 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 5 Feb 2002 12:45:30 -0600 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Tony Johansson'" , aaa-wg@merit.edu Cc: Thomas Panagiotis-PTHOMAS1 , Bob Kopacz , Mark Eklund Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Tue, 5 Feb 2002 12:45:28 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, Tony Johansson wrote: > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA-AVP > from the AMR message to the HAR message. In cases when another AAAF, which > may not reside in the same domain, receives the HAR, ... Could you please explain in which scenarios does an AAAF, that "does not reside in the same domain", receive the HAR message? Isn't the Origin-Realm in the received AMR set to the realm of the first AAAF? Why can't AAAH set the HAR's Destination-Realm to the same value, thus routing the message back to the same domain? Thanks, -Panos > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Monday, February 04, 2002 4:53 PM > To: aaa-wg@merit.edu > Cc: Thomas Panagiotis-PTHOMAS1; Bob Kopacz; Mark Eklund > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA > Key to FA > > > All, > > Here is proposed text for the handling of the FA-HA Key based > on the discussion > last week. > > > Comments, please... > > Regards, > > /Tony > > -------------------------------------------------------------- > --------------------- > > * New text to section - 1.4 Allocation of Home Agent in > Foreign Network > > "The Diameter Mobile IP application allows a Home Agent to be > allocated in a > foreign network, as required in [3, 16]. When a foreign agent > detects that the > mobile node has a home agent address equal to 0.0.0.0 or > 255.255.255.255 in > the Registration Request message, it MUST add a > MIP-Feature-Vector AVP with > the Home-Agent- Requested flag set to one. If the home agent > address is equal > to 255.255.255.255, then the foreign agent also MUST set the > Home-Address-Allocatable-Only-in-Home-Realm flag equal to > one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the > Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the > Home-Agent-Requested flag set > to one, and the Home-Address-Allocatable-Only-in-Home-Realm > flag equal to zero, > the AAAF MAY set the Foreign-Home-Agent-Available flag in the > MIP-Feature-Vector AVP to inform the AAAH that it is willing > and able to assign > a Home Agent for the Mobile Node. When doing so, the AAAF > MUST include the > MIP-Candidate-Home-Agent-Host AVP and the > MIP-Originating-Foreign-AAA-AVP. The > MIP-Candidate-Home-Agent-Host AVP contains the identity of > the home agent that > would be assigned to the mobile node and the > MIP-Originating-Foreign-AAA AVP > contains the identity of the AAAF. > > In the event that the mobile node requests a home agent in > the foreign network, > and the AAAF authorizes its use, the AAAF MUST set the > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector > AVP. This could > happen when the AAA request is sent to "extend" a mobile > node's current > session. > > When the AAAH receives an AMR message, it first checks the > authentication data > supplied by the mobile node, according to the MIP-Reg-Request AVP and > MIP-MN-AAA-Auth AVP, and determines whether to authorize the > mobile node. If > the AMR indicates that the AAAF has offered to allocate a > home agent for the > mobile node, then the AAAH must decide whether its local > policy would allow > the user to have a Home Agent in the foreign network. If so, > and after checking > authorization from the data in the AMR message, the AAAH > sends the HAR message > to the AAAF that does not contain the MIP-Home-Agent-Address, > but includes the > Destination-Host AVP set to the value of the AMR's > MIP-Candidate-Home-Agent-Host AVP. > > If the HA hasn't yet been allocated by the foreign domain, > the HAR sent by the > AAAH back to the foreign realm will not necessarily be > received by the same > AAAF which sent the AMR. Therefore the AAAH MUST always copy the > MIP-Originating-Foreign-AAA-AVP from the AMR message to the > HAR message. In > cases when another AAAF, which may not reside in the same > domain, receives the > HAR, thus the new AAAF will use the > MIP-Originating-Foreign-AAA-AVP for policy > decisions, such as determining if the FA-HA Key should be > encrypted or not." > > > * Section 2.1 and section 2.3, add [ > MIP-Originating-Foreign-AAA ] to ABNF > > * Section 2.2 and 2.4, add [ MIP-Encrypted-FA-to-HA-Key ] to ABNF > > * Add MIP-Originating-Foreign-AAA in section 4 as: > > "4.11 MIP-Originating-Foreign-AAA AVP > > The MIP-Originating-Foreign-AAA AVP (AVP Code ZZZ) if of type > Grouped, and contains the identity of the AAAF which issues the AMR > to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST > only be used in > cases when the home agent is or may be allocated in a > foreign domain. If > present > in the AMR, the AAAH MUST copy the MIP-Originating-Foreign-AAA AVP > into the HAR. > > MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > > { Origin-Realm } > { Origin-Host } > * [ AVP ]" > > > * New text to section - 5.4 Distributing the Foreign-Home > Session Key > > " If the home agent is in the home realm, then the AAAH has > to generate the > Foreign-Home session key. Otherwise, it is generated by AAAF. > > In the cases when the AAAH generates the Foreign-Home session > key, the AAAH > includes the session key in the MIP-HA-to-FA-Key AVP, and > includes the AVP as > part of the HAR message sent to the home agent. The > corresponding session key > that is to be sent to the foreign agent is cached in the AAAH > until the HAA is > received. > > Upon receipt of the HAR, the home agent recovers the > Foreign-Home session key, > allocates an SPI to be used with the key. The allocated SPI > is included in the > HAA's MIP-FA-to-HA SPI AVP. > > Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key > AVP, using the SPI > in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. > > In the cases when the AAAF generates the Foreign-Home session > key (home agent > in foreign domain), the AAAF will, upon receipt of the HAR > message, generate > the Foreign-Home session key and include the session key in the > MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to > the home agent. > The corresponding session key that is to be sent to the > foreign agent is cached > in the AAAF until the HAA is received. > > Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA > Key AVP, using the > SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the > Foreign-Home session > key destined for the foreign agent needs to be encrypted. > > If the session key needs to be encrypted, the AAAF will include a > MIP-Encrypted-FA-to-HA Key AVP, which will include the > MIP-FA-to-HA Key AVP, > protected using the CMS application [9] with the AAAF as > originator and the > recipient copied from the MIP-Originating-Foreign-AAA AVP. The > MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the > originator and the > recipient supports the CMS application. > > Upon reception of the HAA, the AAAH will copy the > MIP-FA-to-HA Key AVP or the > MIP-Encrypted-FA-to-HA Key AVP into the AMA. > > If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, > the AAAF MUST > decrypt the AVP using the CMS application [9]. > > If a Foreign-Home session key was present in the AMA, the > foreign agent MUST > include the Mobile-Foreign authentication extension in the > Registration Reply, > using the newly distributed key. " > > > * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as: > > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of > type Grouped, > and contains the Foreign Agent's session key encrypted in a CMS- > Encrypted-Data AVP [9]. Its Data field has the following ABNF > grammar: > > MIP-FA-to-HA-Key ::= < AVP Header: YYY > > { CMS-Encrypted-Data } > * [ AVP ] " > > > > > From owner-aaa-wg@merit.edu Tue Feb 5 14:02:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13970 for ; Tue, 5 Feb 2002 14:02:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C92A891279; Tue, 5 Feb 2002 14:01:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94F879127A; Tue, 5 Feb 2002 14:01:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EE66E91279 for ; Tue, 5 Feb 2002 14:01:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id CDD275DDB8; Tue, 5 Feb 2002 14:01:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 9B2F15DD99 for ; Tue, 5 Feb 2002 14:01:42 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g15J1Wh03577; Tue, 5 Feb 2002 13:01:32 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g15J1WU09169; Tue, 5 Feb 2002 13:01:32 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA07627; Tue, 5 Feb 2002 13:01:32 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA08168; Tue, 5 Feb 2002 13:01:30 -0600 (CST) Message-ID: <3C602B8C.430661B5@ericsson.com> Date: Tue, 05 Feb 2002 10:59:24 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu, Thomas Panagiotis-PTHOMAS1 , Mark Eklund Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: <3C5AF2A9.84DD3B92@ericsson.com> <3C5F10C4.F06A184@ericsson.com> <000401c1adfa$6ab412e0$f6512844@sanarb01.mi.comcast.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > > > > If the session key needs to be encrypted, the AAAF will include a > > MIP-Encrypted-FA-to-HA Key AVP, which will include the MIP-FA-to-HA Key AVP, > > protected using the CMS application [9] with the AAAF as originator and the > > recipient copied from the MIP-Originating-Foreign-AAA AVP. The > > MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the originator and the > > recipient supports the CMS application. > > (1) How does the destination AAAF know if the origin AAAF supports the CMS > application? It seems there are two ways: (a) When the destination AAAF > sends his DSAR, it is unsuccessful, Right, that was the idea since the AAAF supports DSA messages (as you mention in bullet 2 below). Thus, the destination AAAF would check if security association and encryption can be establish between the two AAAF nodes. > or (b) the origin AAAF can signal that > it doesn't support the CMS security application by NOT sending the > MIP-Originating-Foreign-AAA AVP, thus not inviting a DSA. > > > (2) However, since both of the AAAFs are servers, isn't it a requirement > that they support the CMS application? Section 1 "Introduction" of the > CMS draft says that "Diameter servers: MUST support DSA messages; MAY > support PDS messages" See above.. > > > (3) In order to allow the two AAAF's to set up a security assocation, the > CMS draft needs a minor editing change, to remove a restriction. Section > 1.6 "Who can authorize users" of the CMS security draft says that > "However, it is important to note that one of participants of a DSA > (specifically the one in the home network) MUST belong to the same realm > as the user being authorized (the realm portion of the Network Access > Identifier found in the User-Name AVP), otherwise an answer is returned > with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED." Neither > of the AAAFs is in the home realm, but my understanding is that CMS would > still work. Hmmm, you are right. So could we change the text in the CMS application so that any two nodes can set up security associations? > > > (4) Did you want to say that the AAAF, after receiving the HAA from the HA > but before sending the HAA to the AAAH, sets up the DSA with the > originating AAAF, if the FA-HA key needs to be encrypted? Yes, I will make the text more explicit. > > > > Upon reception of the HAA, the AAAH will copy the MIP-FA-to-HA Key AVP or the > > MIP-Encrypted-FA-to-HA Key AVP into the AMA. > > > > If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, the AAAF MUST > > decrypt the AVP using the CMS application [9]. > > > > If a Foreign-Home session key was present in the AMA, the foreign agent MUST > > include the Mobile-Foreign authentication extension in the Registration Reply, > > using the newly distributed key. " > > > > > > * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as: > > > > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped, > > and contains the Foreign Agent's session key encrypted in a CMS- > > Encrypted-Data AVP [9]. Its Data field has the following ABNF > > grammar: > > > > MIP-FA-to-HA-Key ::= < AVP Header: YYY > > ^^^^^^^^^^^^^^^^ > MIP-Encrypted-FA-to-HA-Key > Check. > > > { CMS-Encrypted-Data } > > * [ AVP ] " > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Feb 5 14:17:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14639 for ; Tue, 5 Feb 2002 14:17:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6558B9127B; Tue, 5 Feb 2002 14:17:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 445629127A; Tue, 5 Feb 2002 14:17:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A80079127B for ; Tue, 5 Feb 2002 14:17:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 383B15DDF4; Tue, 5 Feb 2002 14:17:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 0AEBB5DDF3 for ; Tue, 5 Feb 2002 14:17:08 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g15JGkS29088; Tue, 5 Feb 2002 13:16:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g15JGkU13134; Tue, 5 Feb 2002 13:16:46 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA09210; Tue, 5 Feb 2002 13:16:45 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA08486; Tue, 5 Feb 2002 13:16:44 -0600 (CST) Message-ID: <3C602F1D.CCDCA7D4@ericsson.com> Date: Tue, 05 Feb 2002 11:14:38 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Panagiotis-PTHOMAS1 Cc: aaa-wg@merit.edu, Bob Kopacz , Mark Eklund Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thomas, Thomas Panagiotis-PTHOMAS1 wrote: > Hi Tony, > > Tony Johansson wrote: > > Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA-AVP > > from the AMR message to the HAR message. In cases when another AAAF, which > > may not reside in the same domain, receives the HAR, ... > > Could you please explain in which scenarios does an AAAF, that "does not > reside in the same domain", receive the HAR message? Isn't the Origin-Realm > in the received AMR set to the realm of the first AAAF? Why can't AAAH set > the HAR's Destination-Realm to the same value, thus routing the message > back to the same domain? Please, look at section 1.4 and the text below and above Figure 7....... /Tony > > > Thanks, > > -Panos > > > -----Original Message----- > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > Sent: Monday, February 04, 2002 4:53 PM > > To: aaa-wg@merit.edu > > Cc: Thomas Panagiotis-PTHOMAS1; Bob Kopacz; Mark Eklund > > Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA > > Key to FA > > > > > > All, > > > > Here is proposed text for the handling of the FA-HA Key based > > on the discussion > > last week. > > > > > > Comments, please... > > > > Regards, > > > > /Tony > > > > -------------------------------------------------------------- > > --------------------- > > > > * New text to section - 1.4 Allocation of Home Agent in > > Foreign Network > > > > "The Diameter Mobile IP application allows a Home Agent to be > > allocated in a > > foreign network, as required in [3, 16]. When a foreign agent > > detects that the > > mobile node has a home agent address equal to 0.0.0.0 or > > 255.255.255.255 in > > the Registration Request message, it MUST add a > > MIP-Feature-Vector AVP with > > the Home-Agent- Requested flag set to one. If the home agent > > address is equal > > to 255.255.255.255, then the foreign agent also MUST set the > > Home-Address-Allocatable-Only-in-Home-Realm flag equal to > > one. If the home > > agent address is set to 0.0.0.0, the foreign agent MUST set the > > Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > > > When the AAAF receives an AMR message with the > > Home-Agent-Requested flag set > > to one, and the Home-Address-Allocatable-Only-in-Home-Realm > > flag equal to zero, > > the AAAF MAY set the Foreign-Home-Agent-Available flag in the > > MIP-Feature-Vector AVP to inform the AAAH that it is willing > > and able to assign > > a Home Agent for the Mobile Node. When doing so, the AAAF > > MUST include the > > MIP-Candidate-Home-Agent-Host AVP and the > > MIP-Originating-Foreign-AAA-AVP. The > > MIP-Candidate-Home-Agent-Host AVP contains the identity of > > the home agent that > > would be assigned to the mobile node and the > > MIP-Originating-Foreign-AAA AVP > > contains the identity of the AAAF. > > > > In the event that the mobile node requests a home agent in > > the foreign network, > > and the AAAF authorizes its use, the AAAF MUST set the > > Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector > > AVP. This could > > happen when the AAA request is sent to "extend" a mobile > > node's current > > session. > > > > When the AAAH receives an AMR message, it first checks the > > authentication data > > supplied by the mobile node, according to the MIP-Reg-Request AVP and > > MIP-MN-AAA-Auth AVP, and determines whether to authorize the > > mobile node. If > > the AMR indicates that the AAAF has offered to allocate a > > home agent for the > > mobile node, then the AAAH must decide whether its local > > policy would allow > > the user to have a Home Agent in the foreign network. If so, > > and after checking > > authorization from the data in the AMR message, the AAAH > > sends the HAR message > > to the AAAF that does not contain the MIP-Home-Agent-Address, > > but includes the > > Destination-Host AVP set to the value of the AMR's > > MIP-Candidate-Home-Agent-Host AVP. > > > > If the HA hasn't yet been allocated by the foreign domain, > > the HAR sent by the > > AAAH back to the foreign realm will not necessarily be > > received by the same > > AAAF which sent the AMR. Therefore the AAAH MUST always copy the > > MIP-Originating-Foreign-AAA-AVP from the AMR message to the > > HAR message. In > > cases when another AAAF, which may not reside in the same > > domain, receives the > > HAR, thus the new AAAF will use the > > MIP-Originating-Foreign-AAA-AVP for policy > > decisions, such as determining if the FA-HA Key should be > > encrypted or not." > > > > > > * Section 2.1 and section 2.3, add [ > > MIP-Originating-Foreign-AAA ] to ABNF > > > > * Section 2.2 and 2.4, add [ MIP-Encrypted-FA-to-HA-Key ] to ABNF > > > > * Add MIP-Originating-Foreign-AAA in section 4 as: > > > > "4.11 MIP-Originating-Foreign-AAA AVP > > > > The MIP-Originating-Foreign-AAA AVP (AVP Code ZZZ) if of type > > Grouped, and contains the identity of the AAAF which issues the AMR > > to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST > > only be used in > > cases when the home agent is or may be allocated in a > > foreign domain. If > > present > > in the AMR, the AAAH MUST copy the MIP-Originating-Foreign-AAA AVP > > into the HAR. > > > > MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > > > { Origin-Realm } > > { Origin-Host } > > * [ AVP ]" > > > > > > * New text to section - 5.4 Distributing the Foreign-Home > > Session Key > > > > " If the home agent is in the home realm, then the AAAH has > > to generate the > > Foreign-Home session key. Otherwise, it is generated by AAAF. > > > > In the cases when the AAAH generates the Foreign-Home session > > key, the AAAH > > includes the session key in the MIP-HA-to-FA-Key AVP, and > > includes the AVP as > > part of the HAR message sent to the home agent. The > > corresponding session key > > that is to be sent to the foreign agent is cached in the AAAH > > until the HAA is > > received. > > > > Upon receipt of the HAR, the home agent recovers the > > Foreign-Home session key, > > allocates an SPI to be used with the key. The allocated SPI > > is included in the > > HAA's MIP-FA-to-HA SPI AVP. > > > > Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key > > AVP, using the SPI > > in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. > > > > In the cases when the AAAF generates the Foreign-Home session > > key (home agent > > in foreign domain), the AAAF will, upon receipt of the HAR > > message, generate > > the Foreign-Home session key and include the session key in the > > MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to > > the home agent. > > The corresponding session key that is to be sent to the > > foreign agent is cached > > in the AAAF until the HAA is received. > > > > Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA > > Key AVP, using the > > SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the > > Foreign-Home session > > key destined for the foreign agent needs to be encrypted. > > > > If the session key needs to be encrypted, the AAAF will include a > > MIP-Encrypted-FA-to-HA Key AVP, which will include the > > MIP-FA-to-HA Key AVP, > > protected using the CMS application [9] with the AAAF as > > originator and the > > recipient copied from the MIP-Originating-Foreign-AAA AVP. The > > MIP-Encrypted-FA-to-HA Key AVP MUST only be used if both the > > originator and the > > recipient supports the CMS application. > > > > Upon reception of the HAA, the AAAH will copy the > > MIP-FA-to-HA Key AVP or the > > MIP-Encrypted-FA-to-HA Key AVP into the AMA. > > > > If the MIP-Encrypted-FA-to-HA Key AVP was present in the AMA, > > the AAAF MUST > > decrypt the AVP using the CMS application [9]. > > > > If a Foreign-Home session key was present in the AMA, the > > foreign agent MUST > > include the Mobile-Foreign authentication extension in the > > Registration Reply, > > using the newly distributed key. " > > > > > > * Add MIP-Encrypted-FA-to-HA-Key AVP in section 6 as: > > > > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of > > type Grouped, > > and contains the Foreign Agent's session key encrypted in a CMS- > > Encrypted-Data AVP [9]. Its Data field has the following ABNF > > grammar: > > > > MIP-FA-to-HA-Key ::= < AVP Header: YYY > > > { CMS-Encrypted-Data } > > * [ AVP ] " > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Feb 5 14:31:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15468 for ; Tue, 5 Feb 2002 14:31:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 672B19127A; Tue, 5 Feb 2002 14:30:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED7849127C; Tue, 5 Feb 2002 14:30:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 127949127A for ; Tue, 5 Feb 2002 14:30:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id F08875DDF6; Tue, 5 Feb 2002 14:20:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DC8EF5DDF2 for ; Tue, 5 Feb 2002 14:20:29 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 39CB96C; Tue, 5 Feb 2002 14:20:29 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: , "Thomas Panagiotis-PTHOMAS1" , "Mark Eklund" Subject: RE: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA Date: Tue, 5 Feb 2002 14:19:50 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C602B8C.430661B5@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > > > > (3) In order to allow the two AAAF's to set up a security assocation, the > > CMS draft needs a minor editing change, to remove a restriction. Section > > 1.6 "Who can authorize users" of the CMS security draft says that > > "However, it is important to note that one of participants of a DSA > > (specifically the one in the home network) MUST belong to the same realm > > as the user being authorized (the realm portion of the Network Access > > Identifier found in the User-Name AVP), otherwise an answer is returned > > with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED." Neither > > of the AAAFs is in the home realm, but my understanding is that CMS would > > still work. > > Hmmm, you are right. So could we change the text in the CMS > application so that any two nodes can set up security associations? To my understanding, yes. My take on the "one of participants ... MUST belong to [the user's home realm]" is that this is not a CMS protocol restriction, but is a comment by an editor who, at the time, probably didn't envision a case such as yours, where both ends of the security association are outside of the home realm. This is an aside, but being one of low CMS IQ, it SEEMS that any node can send another node CMS-secured data without first setting up a security association, as long as the CMS-originating node knows the CMS-destination's public key. The destination node would just go ahead and successfully decrypt the data using his private key. Bob K. From owner-aaa-wg@merit.edu Tue Feb 5 14:39:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15802 for ; Tue, 5 Feb 2002 14:39:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D06879127C; Tue, 5 Feb 2002 14:39:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A455D9127D; Tue, 5 Feb 2002 14:39:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9208A9127C for ; Tue, 5 Feb 2002 14:39:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 753755DDF8; Tue, 5 Feb 2002 14:39:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ihemail2.firewall.lucent.com (ihemail2.lucent.com [192.11.222.163]) by segue.merit.edu (Postfix) with ESMTP id 9C6A25DD99 for ; Tue, 5 Feb 2002 14:39:01 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by ihemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g15Jcxj07280 for ; Tue, 5 Feb 2002 14:38:59 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA15413; Tue, 5 Feb 2002 13:38:59 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id NAA05281; Tue, 5 Feb 2002 13:38:59 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15438.60342.594264.150939@nwsgpc.ih.lucent.com> In-Reply-To: <3C4EBCA3.3B9A6D56@lmf.ericsson.se> References: <3C4C4AEA.AC19E09@ericsson.com> <3C4D40CF.FCDCACCD@lmf.ericsson.se> <3C4DF606.9E259DAC@ericsson.com> <3C4EBCA3.3B9A6D56@lmf.ericsson.se> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid From: Pete McCann To: Jari Arkko Cc: Tony Johansson , aaa-wg@merit.edu Subject: Re: [AAA-WG]:draft-johansson-aaa-diameter-mm-app-00.txt Date: Wed, 23 Jan 2002 10:58:30 -0600 (CST) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jari, Thanks for your comments on the draft - some replies below. Jari Arkko writes: > Tony Johansson wrote: > > > > - Capability AVPs that use Unsigned32. Given > > > that ls -l *-sip-* | wc -l is 149, I fear > > > the capability space may not be sufficient. > > > And why didn't you use the option-tag scheme > > > present in the SIP Supported etc headers? > > > > > > > I'm not really sure that I fully understand you. Can you elaborate this > > a little bit further. > > So, for instance, you have a SIP-Server-Capability AVP which > is of type Unsigned32. But what are the values? Ok, so you may > say that you'll provide some values in the future. But how is > this synced to what the SIP WG will do? Will 32 bits be enough? > > Note that in draft-ietf-sip-rfc2543bis-05.txt, section 21.2 a > concept of an "option-tag" is defined. This is a string of a specific > format that defines the capabilities of the SIP node. Couldn't > we use that? As the draft is written, all capabilities are operator-defined 32-bit numbers. We have been discussing among the co-authors a more general-purpose scheme for capabilities that allows e.g., both global and vendor-specific scope for the capabilities. However, we haven't thought about trying to unify with the SIP option-tag feature. Personally I think this is a very good idea and will lead to greater flexibility, but it may imply more expensive processing than the simple "dictionary" approach that was envisioned by 3GPP. > > > What if there's a new HTTP Auth > > > scheme that the SIP node doesn't know, but both > > > the client and the AAA server do know? What I'm > > > getting at is whether it makes sense to transport > > > the HTTP Auth headers as such, unchanged, or > > > whether you want or need to understand more of > > > what happens inside the auth headers. > > > > First of all, would you really update your client and AAA, and not your > > SIP node? > > > > Furthermore, so lets say that the AAA is handling the HTTP Auth scheme > > and we transport HTTP Auth headers as such, unchanged, I don't see that > > the SIP node really have to understand the scheme in it's full detail. > > The SIP node (SSP) only has to forward the HTTP Auth header created by > > the client and the AAA, and finally get a successful result code from > > the AAA, if successfully authenticated . > > > > On the other hand, if the SIP node is incharge of authenitication and > > the SIP node receives an unkown HTTP Auth header you would have do deal > > with this as in a SIP only case... > > > > Unless I have missed some thing, I don't really see that we should > > change the idea of forwarding the HTTP Auth headers as such. > > We seem to agree about the goal but perhaps I didn't understand > the document well enough to see that this was really the goal. > If you transport the HTTP Auth headers as such, where do you > need EAP-Payload? I think I see your point. The current text is designed to meet 3GPP's requirements for AKA, which have the SSP doing some of the work in checking RES=XRES and caching several authentication vectors in order to minimize round trips with AAA. However, this does seem to violate some of the goals of EAP (assuming we run AKA in EAP), which is to keep the NAS-like device unaware of most aspects of the authentication protocol, even if it does need to know ciphersuites and key them based on NAS-Keys. Perhaps the requirement is misguided and we should learn to live with only HTTP Auth headers in the Diameter application and require AAA involvement on every authentication. Another approach would be for the SSP to understand the details of AKA, its embedding in SIP (with or without EAP), and to encode specific AVPs for AKA inside Diameter. -Pete From owner-aaa-wg@merit.edu Tue Feb 5 16:03:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19253 for ; Tue, 5 Feb 2002 16:03:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4F8D89127D; Tue, 5 Feb 2002 16:03:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D6AB9127E; Tue, 5 Feb 2002 16:03:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1D6679127D for ; Tue, 5 Feb 2002 16:03:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF0BE5DDEE; Tue, 5 Feb 2002 16:03:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id AD4905DDAE for ; Tue, 5 Feb 2002 16:03:20 -0500 (EST) Received: (qmail 26947 invoked by uid 507); 5 Feb 2002 21:03:15 -0000 Date: Tue, 5 Feb 2002 15:03:13 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Very Minor nit Message-ID: <20020205210313.GM23135@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk An EXTREMELY minor nit . . . But . . . AAA should be defined in the terminology sections of all drafts. (The acronym is never broken down) -Dave From owner-aaa-wg@merit.edu Tue Feb 5 16:28:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20036 for ; Tue, 5 Feb 2002 16:28:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A97969127E; Tue, 5 Feb 2002 16:27:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D11E9127F; Tue, 5 Feb 2002 16:27:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E75C9127E for ; Tue, 5 Feb 2002 16:27:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 121C95DDEE; Tue, 5 Feb 2002 16:27:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id A2D995DDAE for ; Tue, 5 Feb 2002 16:27:50 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g15LRkh14344; Tue, 5 Feb 2002 15:27:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g15LRjU10653; Tue, 5 Feb 2002 15:27:45 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA22603; Tue, 5 Feb 2002 15:27:44 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA11197; Tue, 5 Feb 2002 15:27:43 -0600 (CST) Message-ID: <3C604DD1.F8E85B51@ericsson.com> Date: Tue, 05 Feb 2002 13:25:38 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu, Thomas Panagiotis-PTHOMAS1 , Mark Eklund Subject: Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob, By reading your comments below and thinking a little bit more. I agree with you I think we can discard the MIP-Encrypted-FA-to-HA-Key AVP and instead only use the CMS-Encrypted-Data AVP. So, what about change the text proposal for section 5.4 to the following: "5.4 Distributing the Foreign-Home Session Key If the home agent is in the home realm, then the AAAH has to generate the Foreign-Home session key. Otherwise, it is generated by AAAF. In the cases when the AAAH generates the Foreign-Home session key, the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and includes the AVP as part of the HAR message sent to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAH until the HAA is received. Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, allocates an SPI to be used with the key. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. In the cases when the AAAF generates the Foreign-Home session key (home agent in foreign domain), the AAAF will, upon receipt of the HAR message, generate the Foreign-Home session key and include the session key in the MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAF until the HAA is received. Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the Foreign-Home session key destined for the foreign agent needs to be encrypted. If the session key needs to be encrypted, the AAAF will check if a security association can be established using DSA messages defined in the CMS application [9] with the originating host found in the MIP-Originating-Foreign-AAA AVP. If the DSA establishment is successful, the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-Data AVP with the AAAF as originator and the recipient copied from the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is included by the AAAF in the HAA destined for the AAAH. Otherwise, if the DSA establishment fails, the AAAF MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If the session key does not need to be encrypted, the AAAF will add MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the HAA to the AAAH . Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA Key AVP if present or the CMS-Ecrypted-data AVP if present and not destined for the AAAH into the AMA. If a Foreign-Home session key was present in the AMA, the foreign agent MUST include the Mobile-Foreign authentication extension in the Registration Reply, using the newly distributed key. " I blieve this also covers your last bullet (4). However, we still need to change the CMS application to allow any to AAA servers to exchange DSA messages, regardless if they belong to the users home domain or not. Since the DSA message exchange in this case needs to be done between two AAAF servers where non of them belongs to the user home domain. /Tony Bob Kopacz wrote: > Hi Tony, > > A few more comments. Again bear in mind my CMS limitations. > > > " 6.3 MIP-Encrypted-FA-to-HA-Key AVP > > > > The MIP-Encrypted-FA-to-HA-Key AVP (AVP Code YYY) is of type Grouped, > > and contains the Foreign Agent's session key encrypted in a CMS- > > Encrypted-Data AVP [9]. Its Data field has the following ABNF > > grammar: > > > > MIP-Encrypted-FA-to-HA-Key ::= < AVP Header: YYY > > > { CMS-Encrypted-Data } > > * [ AVP ] " > > > > > > (1) I think the way that CMS works is that the CMS-Encrypted-Data AVP is a > standalone AVP (not a member of a grouped AVP). When the destination > decrypts the CMS-Encrypted-Data AVP, one or more AVPs are revealed. In > this case, when the originating AAAF decrypts the CMS-Encrypted-Data AVP, > he will find a MIP-FA-to-HA-Key AVP. So instead of returning a > MIP-Encrypted-FA-to-HA-Key AVP in the HAA, the destination AAAF would > return a CMS-Encrypted-Data AVP. > > (2) Therefore do we even need the new MIP-Encrypted-FA-to-HA-Key AVP? The > only reason I can think of why we might need it would be this: I have a > recollection (which may be wrong so I may be all wet here) that CMS > pre-defines which AVPs are to be encrypted and which are not. If so, then > we might need a MIP-Encrypted-FA-to-HA-Key AVP, but its member AVPs would > be the same as the MIP-FA-to-HA-Key AVP. The rule would be that the > MIP-FA-to-HA-Key AVP wouldn't be encrypted, and the > MIP-Encrypted-FA-to-HA-Key AVP would be encrypted. But I'd rather not > have to manufacture a AVP for this purpose, I'd rather have the > originating AAAF decrypt the CMS-Encrypted-Data AVP and say "Gosh, look, a > MIP-FA-to-HA-Key AVP, I know just what to do with this". > > (3) In the case where the originating AAAF and the destination AAAF are > the same server, and the AAAF wants to encrypt the FA-HA-key, then the > same mechanism would be used to return the encrypted key to himself, but > the setup of the security association with himself could be skipped. That > is, the destination AAAF would encrypt the FA-HA-key with his public key > in the HAA, and the originating (same) AAAF would decrypt the FA-HA-key > with his private key. True? > > (4) The node which sends the CMS-Encrypted-Data (destination AAAF) is not > the same as the node which originates the AMA (AAAH). Are there any > assumptions/requirements in CMS that the originator of a > message's CMS-Encrypted-Data AVP be the same as the originator of the > message? > > Bob K. From owner-aaa-wg@merit.edu Tue Feb 5 19:41:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26036 for ; Tue, 5 Feb 2002 19:41:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 00E0E91282; Tue, 5 Feb 2002 19:41:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0B4291283; Tue, 5 Feb 2002 19:41:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCF1D91282 for ; Tue, 5 Feb 2002 19:41:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id AD4245DDFD; Tue, 5 Feb 2002 19:41:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id E0F055DDAE for ; Tue, 5 Feb 2002 19:41:12 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA34784 for ; Tue, 5 Feb 2002 16:24:04 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 5 Feb 2002 16:24:04 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: IETF 53 draft cutoff deadlines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk NOTE: There are two (2) Internet-Draft Cutoff dates for IETF 53. February 22nd: Cutoff for Initial Submissions (new documents) March 1st: FINAL Internet-Draft cutoff. This is the deadline most relevant to AAA WG. All initial submissions(-00) must be submitted by Friday, February 22nd, 17:00 US-EST. Initial submissions received after this time will NOT be made available in the Internet-Drafts directory, and will have to be resubmitted. As before, all initial submissions (-00.txt) with a filename beginning with a draft-ietf MUST be approved by the appropriate WG Chair prior to processing and announcing. WG Chair approval must be received by Monday, February 25th. Please do NOT wait until the last minute to submit. Be advised: NO placeholders. Updates to initial submissions received the week of February 22nd will NOT be accepted. March 1st: FINAL Internet-Draft Cutoff All revised Internet-Draft submissions must be submitted by Friday, March 1st, 2002 at 17:00 US-EST. Internet-Drafts received after this time will NOT be announced NOR made available in the Internet-Drafts Directories. We will begin accepting Internet-Draft submissions the week of the meeting, though announcements will NOT be sent until the IETF meeting is over. Thank you for your understanding and cooperation. Please do not hesitate to contact us if you have any questions or concenrs. FYI: These and other significant dates can be found at http://www.ietf.org/meetings/cutoff_dates_53.html From owner-aaa-wg@merit.edu Tue Feb 5 19:57:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26463 for ; Tue, 5 Feb 2002 19:57:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6AA9191283; Tue, 5 Feb 2002 19:56:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C51091284; Tue, 5 Feb 2002 19:56:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07B7F91283 for ; Tue, 5 Feb 2002 19:56:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEAB65DDF7; Tue, 5 Feb 2002 19:56:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 2D0E35DDAE for ; Tue, 5 Feb 2002 19:56:37 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA34814 for ; Tue, 5 Feb 2002 16:39:24 -0800 (PST) (envelope-from aboba@internaut.com) Date: Tue, 5 Feb 2002 16:39:24 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: New Editorial Team Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Due to the demands of his new company, Pat Calhoun has had to transition editorship of the Diameter specifications. We would like to announce a new editorial team which will work on revising the specifications to make the March 1, 2002 IETF draft deadline. Here is the new editorial team: Base: John Loughney CMS-SEC: Stephen Farrell MIP: Tony Johansson Transport: Bernard Aboba/Jonathan Wood NASREQ: TBD (will announce soon) Please join us in welcoming the new editorial team, and give them your support in resolving the remaining issues so we can get the Diameter specs ready for IESG review. From owner-aaa-wg@merit.edu Wed Feb 6 09:12:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20403 for ; Wed, 6 Feb 2002 09:12:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F0939122A; Wed, 6 Feb 2002 09:12:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 42DB391285; Wed, 6 Feb 2002 09:12:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46B209122A for ; Wed, 6 Feb 2002 09:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C1F15DD95; Wed, 6 Feb 2002 09:12:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 8A3E65DD91 for ; Wed, 6 Feb 2002 09:12:23 -0500 (EST) Received: (qmail 3575 invoked by uid 507); 6 Feb 2002 14:12:23 -0000 Date: Wed, 6 Feb 2002 08:12:21 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Stupid CMS Questions/Comments Message-ID: <20020206141220.GA3469@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry, I've finally studied the CMS draft sufficently enough to be confused: First, in section 1.0: Why is it a MUST for Diameter clients to support PDS? Either I'm confused as to what a client is, or I think this is an error. If a NAS is a client, then forcing it to support CMS is asking too much. My vote is change MUST -> SHOULD. I think I understand the proxying . . . please correct me if I'm wrong: When a proxy issues DIAMETER_CAN_ACT_AS_CMS_PROXY, and the client accepts it, it really ends up making two end-to-end connections, right? The entire message is decrypted, and re-encrypted/signed for the destination (or next proxy), right? So, it's just like hop-by-hop security, except, instead of every diameter hop decrypting the messages, only the proxies you trust decrypt the messages. In section 4.2, shouldn't [CMS-Singed-Data] be 0*1[CMS-Signed-Data] like in the DSAR? In section 5.0, it mentions that when sending DSARs, you can provide a list of AVPs that you expect to be encrypted, but I can't seem to find the format of that AVP list. Also in that example, the home server did not return a certificate, indicating one way encryption. How can you request two way encryption in a DSAR? Is it possible? Or, do the holders of certificates mandate whether or not it can receive encrypted data? Sorry if any of these questions are ignorant . . . -Dave From owner-aaa-wg@merit.edu Wed Feb 6 10:23:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22932 for ; Wed, 6 Feb 2002 10:23:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 67CA291287; Wed, 6 Feb 2002 10:23:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B82391288; Wed, 6 Feb 2002 10:23:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 41C7891287 for ; Wed, 6 Feb 2002 10:23:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 216505DDBF; Wed, 6 Feb 2002 10:23:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D3FB05DD9C for ; Wed, 6 Feb 2002 10:23:22 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id ECAB76C for ; Wed, 6 Feb 2002 10:23:21 -0500 (EST) From: "Bob Kopacz" To: "aaa-wg" Subject: [AAA-WG]: [issue] Changes to state machine for ASR/ASA messages Date: Wed, 6 Feb 2002 10:22:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Changes to state machine for ASR/ASA messages Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-06-2002 Reference: Document: base-08 Comment type: Technical Priority: 1 Section: 8.1 Rationale/Explanation of issue: I believe there is an error in the "Authorization Session State Machine", in section 8.1 of the base draft, in the 1st state machine which represents the case where the server maintains session-state. If, for a session in OPEN state, the server wants the session to be be terminated, it sends an ASR and goes into DISCON state. When the ASA is received, the server goes into IDLE state. The state/events I am referring to are: | The following state machine is used when state is maintained on the | server: | | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Discon | terminate the service | | Discon ASA Received Cleanup Idle This seems not quite right for a few reasons. (1) When the server subsequently receives the follow-up STR from the access device, the session will be either non-existent or in IDLE state. (2) An ASR is only a request to terminate a session. It doesn't really go away until the session-timeout expires, the authorization-lifetime expires, or the access device sends an STR. So sending an ASR should not affect the server's state (OPEN), and receiving an ASA should in general not affect the server's state (OPEN). (3) The state machine doesn't take into account the Result-Code returned in the ASA. The draft indicates that an access device is not required to honor an ASR, i.e. the access device can just reply with "unable to comply" and not terminate the session. In this case the server would have incorrectly terminated an active session when receiving the negative ASA. When an ASR is sent, the Result-Code values likely to be returned in the ASA are: SUCCESS -- This means that the access device will be following the ASA with an STR, so the server can just wait for the STR. UNABLE_TO_COMPLY -- The access device has no intention of terminating the session. UNKNOWN_SESSION_ID -- The access device doesn't know about this session. Somehow the access device and server have gotten out of sync. The server can go ahead an clean up this phantom session. UNABLE_TO_DELIVER -- The ASR never made it to the access device, so the access device won't be terminating this session, if it even exists. Requested change: Replace the two entries: | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Discon | terminate the service | | Discon ASA Received Cleanup Idle With: | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Open | terminate the service | | Open ASA Received Cleanup Idle | with Result-Code | = UNKNOWN-SESSION-ID | | Open ASA Received None Open | with Result-Code (ignore) | not = UNKNOWN-SESSION-ID | | Not ASA Received None No Change. | Open Notes on the above four entries (this is FYI, not part of draft): Entry#1. The ASR doesn't do anything on its own, so just stay in OPEN state and wait for the ASA. Entry#2. This is the case where the server is out of sync with the access device. This is a phantom session that the server can remove. Entry#3. If SUCCESS, the access device will soon send an STR, which will terminate the session. If not SUCCESS, the access device won't be terminating the session, so it stays active. Entry#4. Here something happened to the session between the time the ASR was sent and the ASA was received. From owner-aaa-wg@merit.edu Wed Feb 6 15:49:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01558 for ; Wed, 6 Feb 2002 15:49:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 94F0E91229; Wed, 6 Feb 2002 15:49:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64EFC9122B; Wed, 6 Feb 2002 15:49:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60BD591229 for ; Wed, 6 Feb 2002 15:49:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 486675DDD9; Wed, 6 Feb 2002 15:49:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (unknown [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id 78A905DDE3 for ; Wed, 6 Feb 2002 15:49:27 -0500 (EST) Received: from ipunplugged.com ([213.100.60.208]) by fep04-svc.swip.net with ESMTP id <20020206204806.HAYV4425.fep04-svc.swip.net@ipunplugged.com> for ; Wed, 6 Feb 2002 21:48:06 +0100 Message-ID: <3C61A4AC.1030703@ipunplugged.com> Date: Wed, 06 Feb 2002 21:48:28 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: Re: [AAA-WG]: [issue] Changes to state machine for ASR/ASA messages References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree with essentially everything, but I am not so sure about this: Bob Kopacz wrote: >(3) The state machine doesn't take into account the Result-Code > returned in the ASA. The draft indicates that an access device is not > required to honor an ASR, i.e. the access device can just reply with > "unable to comply" and not terminate the session. In this case the > server would have incorrectly terminated an active session when > receiving the negative ASA. > I am not sure what would be gained by not terminating the session at the server and I think keeping it can be harmful. The server has already stated that the session must go, so any client not heeding the ASR would be on its own. How would you get rid of the session *ever* on the server if the client refuses to terminate it? In the mobile ip application you have at least two sessions for each user. If the HA session is terminated the session in the FA will receive an ASR. Whether the FA complies or not the session is for all practical purposes defunct once the HA terminates its end. Please, someone, explain to me why ASRs don't have termination cause codes when STRs do. j From owner-aaa-wg@merit.edu Thu Feb 7 00:26:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12092 for ; Thu, 7 Feb 2002 00:26:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A65E891290; Thu, 7 Feb 2002 00:25:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67DFF91291; Thu, 7 Feb 2002 00:25:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A07F91290 for ; Thu, 7 Feb 2002 00:25:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F7085DE16; Thu, 7 Feb 2002 00:25:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id B2F8B5DDD7 for ; Thu, 7 Feb 2002 00:25:11 -0500 (EST) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Feb 2002 14:26:17 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A69E2AC@cms3.etri.re.kr> From: anny5@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: CMS Question Date: Thu, 7 Feb 2002 14:26:14 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AF97.F5D1E2A0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AF97.F5D1E2A0 Content-Type: text/plain; charset="euc-kr" there is something strange in CMS document. in section 4.1 Diameter-Security-Association-Request, DSAR message can have zero or more AAA-Node-Cert AVP .( * [ AAA-Node-Cert ]) but, in section 8.0, AAA-Node-Cert | 0-1 | 0-1 | 0 | 0 |. it means that AAA-Node-Cert can be 0 or 1 in DSAR or DSAA. it is a contradiction. i wonder how many AAA-Node-Cert AVPs are in DSAR message . there is another question. if a host send DSAR message, does it include other host's certificates in same realm?(within many AAA-Node-Cert AVPs ) ------_=_NextPart_001_01C1AF97.F5D1E2A0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [AAA-WG]: CMS Question

there is something strange in CMS document.

in section 4.1  = Diameter-Security-Association-Request,   DSAR message can = have zero or more  AAA-Node-Cert AVP .(
   * [ AAA-Node-Cert ])

but, in section 8.0, = AAA-Node-Cert          = ;       | 0-1 | 0-1 | 0   | = 0   |.

it means  that AAA-Node-Cert can be 0 or 1 in = DSAR or DSAA.

it is a contradiction. i wonder how many = AAA-Node-Cert AVPs are in DSAR message .

there is another question. if a host send DSAR = message, does  it include other host's certificates in same = realm?(within many AAA-Node-Cert AVPs )

------_=_NextPart_001_01C1AF97.F5D1E2A0-- From owner-aaa-wg@merit.edu Thu Feb 7 11:46:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01795 for ; Thu, 7 Feb 2002 11:46:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F160C91285; Thu, 7 Feb 2002 11:29:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEF9D9128A; Thu, 7 Feb 2002 11:29:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8DCF91285 for ; Thu, 7 Feb 2002 11:29:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 876125DD9C; Thu, 7 Feb 2002 11:29:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 464515DD9A for ; Thu, 7 Feb 2002 11:29:57 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id DC7587E; Thu, 7 Feb 2002 11:29:56 -0500 (EST) From: "Bob Kopacz" To: "Johan Johansson" , "aaa-wg" Subject: RE: [AAA-WG]: [issue] Changes to state machine for ASR/ASA messages Date: Thu, 7 Feb 2002 11:29:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <3C61A4AC.1030703@ipunplugged.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, > From: Johan Johansson [johanj@ipunplugged.com] > Sent: Wednesday, February 06, 2002 4:46 PM > To: Bob Kopacz > Subject: Re: [AAA-WG]: [issue] Changes to state machine for ASR/ASA > messages > > I agree with essentially everything, but I am not so sure about this: > > Bob Kopacz wrote: > > >(3) The state machine doesn't take into account the Result-Code > > returned in the ASA. The draft indicates that an access device is not > > required to honor an ASR, i.e. the access device can just reply with > > "unable to comply" and not terminate the session. In this case the > > server would have incorrectly terminated an active session when > > receiving the negative ASA. > > > I am not sure what would be gained by not terminating the session at the > server and I think keeping it can be harmful. The server has already > stated that the session must go, so any client not heeding the ASR would > be on its own. My thinking, and I could be wrong, was that the server's session state should reflect the reality of the session, rather than what the server wishes. So in the case where the HA responds with "unable to comply", the session is still going on. Also, if the server terminates the session in this case, and then the session (still alive from the MN, FA, and HA's standpoint) undergoes a handoff, the server will incorrectly see this as a new session and issue a new Session-Id and Acct-Multi-Session-Id to the HA. I don't know if this would confuse things. > How would you get rid of the session *ever* on the server > if the client refuses to terminate it? My thinking is also that the server has some a tool where an administrator can force the server to clear a session if the ASR doesn't work, this being useful in the case where the server is hanging on to a phantom session because it got out of sync with the HA, or the server is unable to reach the HA. > In the mobile ip application you have at least two sessions for each > user. If the HA session is terminated the session in the FA will receive > an ASR. I'm not sure the FA would receive an ASR. My understanding is that the AAAH issues his ASR to the HA, and it is up to the AAAF to issue any ASRs to the FA. So I think what would happen here is that: 1. The AAAH issues an ASR to the HA. 2. The HA clears the session, sending an ASA and STR to the AAAH, and a issues a session-clearing Mobile-IP message to the FA. The FA then clears his session and issues an STR. > Whether the FA complies or not the session is for all practical > purposes defunct once the HA terminates its end. True. But I was thinking about the case where the HA didn't terminate its end. > Please, someone, explain to me why ASRs don't have termination cause > codes when STRs do. I think a terminate cause for an ASR would be useful, though not quite as useful as the STR's termination cause. For many circumstances where the AAAH clears a session, e.g. session-timeout or authorization lifetime expiration, an ASR isn't sent. So I'm guessing that many ASRs would just carry a termination-cause of "Administrative action" or something like that. Would probably have to submit an issue for this to be considered rather than ignored. > j > Bob K. From owner-aaa-wg@merit.edu Thu Feb 7 12:38:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03412 for ; Thu, 7 Feb 2002 12:38:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9E71E91292; Thu, 7 Feb 2002 12:37:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63E8591293; Thu, 7 Feb 2002 12:37:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A3AB91292 for ; Thu, 7 Feb 2002 12:37:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A3905DDFA; Thu, 7 Feb 2002 12:37:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id B9A945DDDC for ; Thu, 7 Feb 2002 12:37:56 -0500 (EST) Received: (qmail 14009 invoked by uid 507); 7 Feb 2002 17:37:56 -0000 Date: Thu, 7 Feb 2002 11:37:54 -0600 From: David Frascone To: aaa-wg@merit.edu, diameter@frascone.com Subject: [AAA-WG]: Implementations Query Message-ID: <20020207173753.GP1423@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu, diameter@frascone.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk Ok, now that the Connectathon test plan has been out for a few days: Has *anyone* implemented CMS? Is anyone planning on testing it? Has *anyone* implemented TLS? Is anyone planning on testing it? And finally, has *anyone* implemented NASREQ, and is anyone planning on testing it? I'm going to try and have both NASREQ and CMS working before Cthon, but, if I can't get both done, I'd like to know which one is more likely to be tested. I'm leaning towards NASREQ at the moment. -Dave From owner-aaa-wg@merit.edu Thu Feb 7 15:42:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09278 for ; Thu, 7 Feb 2002 15:42:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F7B191235; Thu, 7 Feb 2002 15:42:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B71691295; Thu, 7 Feb 2002 15:42:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D6C6691235 for ; Thu, 7 Feb 2002 15:42:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id B622E5DDFF; Thu, 7 Feb 2002 15:42:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 208DE5DDE4 for ; Thu, 7 Feb 2002 15:42:09 -0500 (EST) Received: from ipunplugged.com ([213.100.60.208]) by fep03-svc.swip.net with ESMTP id <20020207204208.MGKV16307.fep03-svc.swip.net@ipunplugged.com>; Thu, 7 Feb 2002 21:42:08 +0100 Message-ID: <3C62F4C8.6030703@ipunplugged.com> Date: Thu, 07 Feb 2002 21:42:32 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: [issue] Changes to state machine for ASR/ASA messages References: 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 Bob Kopacz wrote: >>I am not sure what would be gained by not terminating the session at the >>server and I think keeping it can be harmful. The server has already >>stated that the session must go, so any client not heeding the ASR would >>be on its own. >> >My thinking, and I could be wrong, was that the server's session state >should reflect the reality of the session, rather than what the server >wishes. So in the case where the HA responds with "unable to comply", >the session is still going on. > >Also, if the server terminates the session in this case, and then the >session (still alive from the MN, FA, and HA's standpoint) undergoes a >handoff, the server will incorrectly see this as a new session and >issue a new Session-Id and Acct-Multi-Session-Id to the HA. I don't >know if this would confuse things. > This depends. If both the HA and FA agree that the session is still going on and the AAAH attempts to start a new "multi session" the HA will inform it of its mistake as specified in the mip draft. If only the FA thinks that the session is still going on it is mistaken - it is not. If only the HA thinks the session is still up it will connect the old and the new sessions by returning what it considers to be the valid multi session id. >>How would you get rid of the session *ever* on the server >>if the client refuses to terminate it? >> >My thinking is also that the server has some a tool where an >administrator can force the server to clear a session if the ASR >doesn't work, this being useful in the case where the server is >hanging on to a phantom session because it got out of sync with the >HA, or the server is unable to reach the HA. > Of course. The question is how often you want the adminstrator to weed the sessions. How would he even know which ones to kill in the first place? >>In the mobile ip application you have at least two sessions for each >>user. If the HA session is terminated the session in the FA will receive >>an ASR. >> >I'm not sure the FA would receive an ASR. My understanding is that >the AAAH issues his ASR to the HA, and it is up to the AAAF to issue >any ASRs to the FA. > This is incompatible with my understanding. This *may* be the case if the HA is in the foreign net. I have not examined that scenario. The AAAF doesn't seem to be even needed if the HA is in the home network. > So I think what would happen here is that: >1. The AAAH issues an ASR to the HA. >2. The HA clears the session, sending an ASA and STR to the AAAH, and >a issues a session-clearing Mobile-IP message to the FA. The FA then >clears his session and issues an STR. > Sure, this would work. There is no specification of the interaction between mobile ip and diameter in this respect - feel free to correct me of course - but terminating the diameter session through diameter would probably rely on other network paths, and possibly even communicate an explanation. >>Please, someone, explain to me why ASRs don't have termination cause >>codes when STRs do. >> > >I think a terminate cause for an ASR would be useful, though not quite >as useful as the STR's termination cause. For many circumstances >where the AAAH clears a session, e.g. session-timeout or authorization >lifetime expiration, an ASR isn't sent. So I'm guessing that many >ASRs would just carry a termination-cause of "Administrative action" >or something like that. > >Would probably have to submit an issue for this to be considered >rather than ignored. > If I could be sure that it is a mistake and not something done on purpose I would post an issue. I wish it was possible to discuss things before you have to claim that something is wrong. This doesn't seem to be the case though. j From owner-aaa-wg@merit.edu Thu Feb 7 19:22:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13856 for ; Thu, 7 Feb 2002 19:22:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 61DB591237; Thu, 7 Feb 2002 19:22:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F3939123B; Thu, 7 Feb 2002 19:22:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99CC791237 for ; Thu, 7 Feb 2002 19:22:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7DAAA5DDE4; Thu, 7 Feb 2002 19:22:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 49C655DDD5 for ; Thu, 7 Feb 2002 19:22:22 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g180MLh14129 for ; Thu, 7 Feb 2002 18:22:21 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g180MLa01782 for ; Thu, 7 Feb 2002 18:22:21 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA26109 for ; Thu, 7 Feb 2002 18:22:20 -0600 (CST) Received: from ericsson.com ([138.85.159.104]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA04041 for ; Thu, 7 Feb 2002 18:22:19 -0600 (CST) Message-ID: <3C6319B9.40A36B48@ericsson.com> Date: Thu, 07 Feb 2002 16:20:09 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue : Remove section 1.6 from the CMS appl Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Issue : Remove section 1.6 from the CMS appl Submitter name: Tony Submitter email address: tony.Johansson@ericsson.com Date first submitted: 02-07-2002 Reference: Document: cms-03 Comment type: Technical/Editorial Priority: 1 Section: 1.6 Rationale/Explanation of issue: In the discussion and proposed solution to issue #266 - Returning AAAF-Generated FA-HA Key to FA (please find detailed background info in http://www.merit.edu/mail.archives/aaa-wg/msg02986.html message thread) we have identified the need to be able to issue DSA messages between two AAA(F) servers, where none of the nodes belong to the same realm as the user being authorized. This seems to be okay and straight forward according to the CMS application except for what is stated in section 1.6. “However, it is important to note that one of participants of a DSA (specifically the one in the home network) MUST belong to the same realm as the user being authorized (the realm portion of the Network Access Identifier found in the User-Name AVP), otherwise an answer is returned with the Result-Code AVP set to DIAMETER_AUTHORIZATION_REJECTED.” The CMS application describes how a security association is established by two peers through agents, and how authentication, integrity, confidentiality and non-repudiation (with proof of origin) are achieved using a mixture of symmetric and asymmetric transforms, by encapsulating CMS data within AVPs. Thus, the nature of this application deals with servers and not users. Do really have to bring in user authorization as described in section 1.6? Requested change: Remove section 1.6, so that the CMS application only talks about security association establishment between peers, encryption of AVPs between peers, etc. From owner-aaa-wg@merit.edu Fri Feb 8 06:22:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03490 for ; Fri, 8 Feb 2002 06:22:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B36E19123C; Fri, 8 Feb 2002 06:22:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8783E9123E; Fri, 8 Feb 2002 06:22:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 508469123C for ; Fri, 8 Feb 2002 06:22:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D01F5DE07; Fri, 8 Feb 2002 06:22:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E02775DDAA for ; Fri, 8 Feb 2002 06:22:05 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g18BMAZ20560 for ; Fri, 8 Feb 2002 13:22:10 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Feb 2002 13:22:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Feb 2002 13:21:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Note from the Base editor Date: Fri, 8 Feb 2002 13:21:46 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCA6@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: New Editorial Team Thread-Index: AcGuqTvzxWWPPsXyTguoPtoGj+cO0AB50Mlw From: To: , X-OriginalArrivalTime: 08 Feb 2002 11:21:46.0983 (UTC) FILETIME=[CB8D3F70:01C1B092] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA03490 Hi all, First off, I want to thank Pat for all of the work he has done on Diameter. Hopefully, I will be able to fill his shoes in editing the document. I'm currently starting to review the open issues. As I make progress on the open issues, I will ask the list for consensus, especially on the more controversial topics. Currently, I am starting to edit the Introduction (see http://www.drizzle.com/~aboba/AAA/issues.html#Issue #269). Also, I am working on seperating the Normative and Non-Normative References (http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20#250). John From owner-aaa-wg@merit.edu Fri Feb 8 09:09:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07172 for ; Fri, 8 Feb 2002 09:09:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E0E5491240; Fri, 8 Feb 2002 09:08:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA81A91241; Fri, 8 Feb 2002 09:08:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E31691240 for ; Fri, 8 Feb 2002 09:08:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A5F15DDAE; Fri, 8 Feb 2002 09:08:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailhub.fokus.gmd.de (unknown [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id AE62C5DD98 for ; Fri, 8 Feb 2002 09:08:51 -0500 (EST) Received: from fokus.fhg.de (dhcp252 [195.37.78.252]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g18E8oE23301 for ; Fri, 8 Feb 2002 15:08:50 +0100 (MET) Message-ID: <3C63DB16.BEEC8CC2@fokus.fhg.de> Date: Fri, 08 Feb 2002 15:05:10 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: IETF AAA List Subject: [AAA-WG]: User-Name AVP must be present in all accounting records? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present." I don't understand why there is a must for the User-Name since the Diameter node sending the accounting request may not know it. Still the target can use the various session-ID AVPs to correlate the records. There also seems to be some inconsistency in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2 (ACR, ACA definition) User-Name AVP is marked as optional while in section 10.2 it is again specified as MUST. nasreq-08 reads: "Unless the access device interprets the EAP-Response/Identity packet returned by the authenticating peer, it will not have access to the user's identity. Therefore, the Diameter Server SHOULD return the user's identity by inserting it in the User-Name attribute of subsequent Diameter-EAP-Answer packets. Without the user's identity, the Session-Id AVP MAY be used for accounting and billing, however operationally this MAY be very difficult to manage." This make sense to me but my interpretation of this is that the User-Name AVP SHOULD be present in accounting messages which contradicts to the MUST in the base draft. Could someone please clarify on this issue? -- Sebastian From owner-aaa-wg@merit.edu Fri Feb 8 10:08:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09985 for ; Fri, 8 Feb 2002 10:08:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D20CE91242; Fri, 8 Feb 2002 10:08:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91D5191241; Fri, 8 Feb 2002 10:08:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 269A891205 for ; Fri, 8 Feb 2002 10:08:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 017D25DDAE; Fri, 8 Feb 2002 10:08:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id A92395DD98 for ; Fri, 8 Feb 2002 10:08:15 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RWV1>; Fri, 8 Feb 2002 07:08:13 -0800 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com'" , aboba@internaut.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Note from the Base editor Date: Fri, 8 Feb 2002 07:08:12 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B0B2.6CF77AF0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B0B2.6CF77AF0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > First off, I want to thank Pat for all of the work he has done on > Diameter. Hopefully, I > will be able to fill his shoes in editing > the document. I wear size 10.5(US) :) I'd like to personally thank John for taking over. My responsibilities at Black Storm are such that I could not provide the timeliness that is required for Diameter to get through the standards track in short order. PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGPp3DN1fXKoxmisEQI9+QCaA01vRib9xADhssJatu7qH4FHP0kAoMsp yavYg50WpdMk4/MevVtJvMc2 =5OJl -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B0B2.6CF77AF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Note from the Base editor

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> First off, I want to thank Pat for all of the = work he has done on
> Diameter. Hopefully, I > will be able to = fill his shoes in editing
> the document. 

I wear size 10.5(US) :)

I'd like to personally thank John for taking over. = My
responsibilities at Black Storm are such that I = could not provide the
timeliness that is required for Diameter to get = through the standards
track in short order.

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGPp3DN1fXKoxmisEQI9+QCaA01vRib9xADhssJatu7qH4FHP0kAoMs= p
yavYg50WpdMk4/MevVtJvMc2
=3D5OJl
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B0B2.6CF77AF0-- From owner-aaa-wg@merit.edu Fri Feb 8 14:06:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19775 for ; Fri, 8 Feb 2002 14:06:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C0A891223; Fri, 8 Feb 2002 14:05:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 121839122E; Fri, 8 Feb 2002 14:05:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9BF691223 for ; Fri, 8 Feb 2002 14:05:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id BCC6A5DD8E; Fri, 8 Feb 2002 14:05:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id DE7D25DD8D for ; Fri, 8 Feb 2002 14:05:30 -0500 (EST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020208190510.JRKI24910.fep01-app.kolumbus.fi@jariws1>; Fri, 8 Feb 2002 21:05:10 +0200 Message-ID: <018c01c1b0d3$906041e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <8470181DABD5D511B3E700D0B7A8AC4A69E2AC@cms3.etri.re.kr> Subject: Re: [AAA-WG]: CMS Question Date: Fri, 8 Feb 2002 21:05:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit [AAA-WG]: CMS Question>in section 4.1 Diameter-Security-Association-Request, >DSAR message can have zero or more AAA-Node-Cert AVP >but, in section 8.0, AAA-Node-Cert 0-1. >it is a contradiction. i wonder how many AAA-Node-Cert AVPs are in DSAR message . This seems to be an error in 8.0. Should be 0+ for both DSAR and DSAA. Also, I have the concern that section 3.1 lists only a subset of all AVPs that are allowed in 4.1 for DSAR and DSAA. This list should be completed. Preferably, the list items should also point to the AVP names for easier reference. There are many cert AVPs, for instance, it is not very easy to distinguish them from each other. >there is another question. if a host send DSAR message, does it >include other host's certificates in same realm?(within many AAA-Node-Cert AVPs ) I suppose so. Needs clarification in the I-D. Jari From owner-aaa-wg@merit.edu Fri Feb 8 14:26:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21121 for ; Fri, 8 Feb 2002 14:26:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16C9591246; Fri, 8 Feb 2002 14:26:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8D2591247; Fri, 8 Feb 2002 14:26:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA85891246 for ; Fri, 8 Feb 2002 14:26:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id B41385DDAE; Fri, 8 Feb 2002 14:26:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (unknown [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 117BB5DD8E for ; Fri, 8 Feb 2002 14:26:36 -0500 (EST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020208192635.JSUN24910.fep01-app.kolumbus.fi@jariws1>; Fri, 8 Feb 2002 21:26:35 +0200 Message-ID: <01b401c1b0d6$8e610f20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Sebastian Zander" , "IETF AAA List" References: <3C63DB16.BEEC8CC2@fokus.fhg.de> Subject: Re: [AAA-WG]: User-Name AVP must be present in all accounting records? Date: Fri, 8 Feb 2002 21:26:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Section 9.5 of base-08 reads: > "In all accounting records the Session-Id and User-Name AVPs MUST be present." > > I don't understand why there is a must for the User-Name since the Diameter node > sending the accounting request may not know it. Still the target can use the various > session-ID AVPs to correlate the records. There also seems to be some inconsistency > in the draft and between base-08 and nasreq-08: > > In section 9.7.1 & 9.7.2 (ACR, ACA definition) User-Name AVP is marked as optional > while in section 10.2 it is again specified as MUST. You are correct. This is not right. I suggest chaning 9.5 so that it reads. "User-Name AVP MUST be present if it is available to the Diameter client." Then change the tables accordingly. Can you file an issue? > nasreq-08 reads: > "Unless the access device interprets the EAP-Response/Identity packet > returned by the authenticating peer, it will not have access to the > user's identity. Therefore, the Diameter Server SHOULD return the > user's identity by inserting it in the User-Name attribute of > subsequent Diameter-EAP-Answer packets. Without the user's identity, > the Session-Id AVP MAY be used for accounting and billing, however > operationally this MAY be very difficult to manage." > > This make sense to me but my interpretation of this is that the User-Name AVP SHOULD > be present in accounting messages which contradicts to the MUST in the base draft. I would suggest that the nasreq-08 be kept as is -- using the server to dig out the User-Name so that it eventually becomes available to the client, and be inserted in the (at the very least) the Stop record for the session. Jari From owner-aaa-wg@merit.edu Fri Feb 8 15:24:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23682 for ; Fri, 8 Feb 2002 15:24:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19B769124B; Fri, 8 Feb 2002 15:24:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBAA19124C; Fri, 8 Feb 2002 15:24:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB74A9124B for ; Fri, 8 Feb 2002 15:24:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A426A5DD8D; Fri, 8 Feb 2002 15:24:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (unknown [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id F13D05DD98 for ; Fri, 8 Feb 2002 15:24:14 -0500 (EST) Received: from jariws1 ([62.248.145.160]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020208202414.JWMT24910.fep01-app.kolumbus.fi@jariws1>; Fri, 8 Feb 2002 22:24:14 +0200 Message-ID: <020b01c1b0de$9c43c580$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Frascone" , References: <20020206141220.GA3469@newman.frascone.com> Subject: Re: [AAA-WG]: Stupid CMS Questions/Comments Date: Fri, 8 Feb 2002 22:24:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Why is it a MUST for Diameter clients to support PDS? Either I'm > confused as to what a client is, or I think this is an error. > If a NAS is a client, then forcing it to support CMS is asking too > much. My vote is change MUST -> SHOULD. No, the idea of the PDS[RA] is to have the NAS *not* need to support CMS, and allow the local ISP proxy to handle it on its behalf. (But a question to you: do a find some part of the text misleading in this respect? If so, we should fix it.) > When a proxy issues DIAMETER_CAN_ACT_AS_CMS_PROXY, and the client > accepts it, it really ends up making two end-to-end connections, > right? The entire message is decrypted, and re-encrypted/signed > for the destination (or next proxy), right? No, just hbh protection to the proxy, then real CMS protection to the end of the path. > In section 4.2, shouldn't [CMS-Singed-Data] be 0*1[CMS-Signed-Data] like > in the DSAR? I quote section 3.1: "The DSAR message MAY include the CMS-Signed-Data AVP. If the originating node has a private key, and it includes AVPs whose 'P' bit set, the CMS-Signed-Data AVP MUST be present. The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent or server within the user's realm, to prevent an intermediate node from modifying the protection expectations for AVPs." > In section 5.0, it mentions that when sending DSARs, you can provide a list > of AVPs that you expect to be encrypted, but I can't seem to find the format > of that AVP list. You know, I can't find it either. I'm not sure if this is because it's late friday evening or because it isn't described anywhere... someone? > Also in that example, the home server did not return a certificate, indicating > one way encryption. How can you request two way encryption in a DSAR? Is > it possible? Or, do the holders of certificates mandate whether or not it > can receive encrypted data? If you are talking about draft-ietf-aaa-diameter-cms-sec-03.txt and the example in section 5 *does* return a cert. On the other hand, it states CMS-Cert, which isn't defined anywhere. It is also referenced from base, and not defined... looks like an issue needs to be filed, or at least the issue data base needs to be checked if this has already been fixed. Jari From owner-aaa-wg@merit.edu Fri Feb 8 15:50:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24293 for ; Fri, 8 Feb 2002 15:50:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1226A9124E; Fri, 8 Feb 2002 15:50:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE07C9124F; Fri, 8 Feb 2002 15:50:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DE369124E for ; Fri, 8 Feb 2002 15:50:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 162F15DD98; Fri, 8 Feb 2002 15:50:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 8A6015DD8D for ; Fri, 8 Feb 2002 15:50:20 -0500 (EST) Received: (qmail 29625 invoked by uid 507); 8 Feb 2002 20:50:16 -0000 Date: Fri, 8 Feb 2002 14:50:13 -0600 From: David Frascone To: Jari Arkko Cc: David Frascone , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Stupid CMS Questions/Comments Message-ID: <20020208205013.GA29189@newman.frascone.com> Mail-Followup-To: Jari Arkko , David Frascone , aaa-wg@merit.edu References: <20020206141220.GA3469@newman.frascone.com> <020b01c1b0de$9c43c580$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020b01c1b0de$9c43c580$8a1b6e0a@arenanet.fi> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk Ok, I think I've got a handle on it now. (comments inline) On Friday, 08 Feb 2002, Jari Arkko wrote: > > Why is it a MUST for Diameter clients to support PDS? Either I'm > > confused as to what a client is, or I think this is an error. > > If a NAS is a client, then forcing it to support CMS is asking too > > much. My vote is change MUST -> SHOULD. > > No, the idea of the PDS[RA] is to have the NAS *not* need > to support CMS, and allow the local ISP proxy to handle it > on its behalf. > > (But a question to you: do a find some part of the text > misleading in this respect? If so, we should fix it.) I was mistakenly assuming that PDS[RA]'s were setting up hops of encryption. See below. > > > When a proxy issues DIAMETER_CAN_ACT_AS_CMS_PROXY, and the client > > accepts it, it really ends up making two end-to-end connections, > > right? The entire message is decrypted, and re-encrypted/signed > > for the destination (or next proxy), right? > > No, just hbh protection to the proxy, then real CMS protection to the > end of the path. > Ok, so when the PDS[RA] is issued, the proxy and the other side form the Security Association. Data is "in the clear" from the originating side to the proxy, then the proxy uses CMS to protect it to the far side. I get it. What happens if the proxy receives the DIAMETER_CAN_ACT_AS_CMS_PROXY from another hop? It seems that the originator of the message should be the only entity that can decide if a message should be sent in the clear, right? > > Also in that example, the home server did not return a certificate, indicating > > one way encryption. How can you request two way encryption in a DSAR? Is > > it possible? Or, do the holders of certificates mandate whether or not it > > can receive encrypted data? > > If you are talking about draft-ietf-aaa-diameter-cms-sec-03.txt and the > example in section 5 *does* return a cert. On the other hand, it states > CMS-Cert, which isn't defined anywhere. It is also referenced from base, > and not defined... looks like an issue needs to be filed, or at least the > issue data base needs to be checked if this has already been fixed. Ok, then, how is it decided what should or should not be encrypted. The draft seems to have two mechanisms, the may-encrypt flag in the dictionary, and the mystical list of avps. We need to better define that list. -Dave From owner-aaa-wg@merit.edu Sat Feb 9 09:35:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15717 for ; Sat, 9 Feb 2002 09:35:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 873979121A; Sat, 9 Feb 2002 09:35:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5938291245; Sat, 9 Feb 2002 09:35:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AE239121A for ; Sat, 9 Feb 2002 09:35:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 197855DDB9; Sat, 9 Feb 2002 09:35:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 29ED85DD9E for ; Sat, 9 Feb 2002 09:35:29 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA42856; Sat, 9 Feb 2002 06:16:51 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sat, 9 Feb 2002 06:16:51 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: Jari Arkko , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Stupid CMS Questions/Comments In-Reply-To: <20020208205013.GA29189@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Can someone file an issue on this, suggesting new text that could make this more clear? On Fri, 8 Feb 2002, David Frascone wrote: > > Ok, I think I've got a handle on it now. (comments inline) > > On Friday, 08 Feb 2002, Jari Arkko wrote: > > > Why is it a MUST for Diameter clients to support PDS? Either I'm > > > confused as to what a client is, or I think this is an error. > > > If a NAS is a client, then forcing it to support CMS is asking too > > > much. My vote is change MUST -> SHOULD. > > > > No, the idea of the PDS[RA] is to have the NAS *not* need > > to support CMS, and allow the local ISP proxy to handle it > > on its behalf. > > > > (But a question to you: do a find some part of the text > > misleading in this respect? If so, we should fix it.) > > I was mistakenly assuming that PDS[RA]'s were setting up hops of > encryption. See below. > > > > > > When a proxy issues DIAMETER_CAN_ACT_AS_CMS_PROXY, and the client > > > accepts it, it really ends up making two end-to-end connections, > > > right? The entire message is decrypted, and re-encrypted/signed > > > for the destination (or next proxy), right? > > > > No, just hbh protection to the proxy, then real CMS protection to the > > end of the path. > > > > Ok, so when the PDS[RA] is issued, the proxy and the other side form the > Security Association. Data is "in the clear" from the originating side to > the proxy, then the proxy uses CMS to protect it to the far side. I get > it. > > What happens if the proxy receives the DIAMETER_CAN_ACT_AS_CMS_PROXY from > another hop? It seems that the originator of the message should be the only > entity that can decide if a message should be sent in the clear, right? > > > > Also in that example, the home server did not return a certificate, indicating > > > one way encryption. How can you request two way encryption in a DSAR? Is > > > it possible? Or, do the holders of certificates mandate whether or not it > > > can receive encrypted data? > > > > If you are talking about draft-ietf-aaa-diameter-cms-sec-03.txt and the > > example in section 5 *does* return a cert. On the other hand, it states > > CMS-Cert, which isn't defined anywhere. It is also referenced from base, > > and not defined... looks like an issue needs to be filed, or at least the > > issue data base needs to be checked if this has already been fixed. > > Ok, then, how is it decided what should or should not be encrypted. The > draft seems to have two mechanisms, the may-encrypt flag in the dictionary, > and the mystical list of avps. > > We need to better define that list. > > > -Dave > From owner-aaa-wg@merit.edu Sat Feb 9 09:37:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15760 for ; Sat, 9 Feb 2002 09:37:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 706FC91245; Sat, 9 Feb 2002 09:37:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 444CF91255; Sat, 9 Feb 2002 09:37:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5350C91245 for ; Sat, 9 Feb 2002 09:37:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B4B125DDB9; Sat, 9 Feb 2002 09:37:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 07C2D5DD9E for ; Sat, 9 Feb 2002 09:37:02 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA42864 for ; Sat, 9 Feb 2002 06:19:36 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sat, 9 Feb 2002 06:19:36 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: NASREQ Editors In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk David Spence and David Mitton have graciously volunteered to edit the NASREQ draft. This fills out the editorial team: Base: John Loughney CMS-SEC: Stephen Farrell MIP: Tony Johansson Transport: Bernard Aboba and Jonathan Wood NASREQ: David Spence and David Mitton From owner-aaa-wg@merit.edu Sun Feb 10 11:02:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07461 for ; Sun, 10 Feb 2002 11:02:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AF58F9121C; Sun, 10 Feb 2002 11:01:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3184B9121F; Sun, 10 Feb 2002 11:01:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E9D9B9121C for ; Sun, 10 Feb 2002 11:01:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id C362A5DDC5; Sun, 10 Feb 2002 11:01:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (unknown [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id 8EADF5DDBC for ; Sun, 10 Feb 2002 11:01:53 -0500 (EST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id B33186A907 for ; Sun, 10 Feb 2002 18:01:52 +0200 (EET) Message-ID: <3C6699AE.3020300@kolumbus.fi> Date: Sun, 10 Feb 2002 18:02:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue about User-Name AVP and accounting 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 Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: base, nasreq Comment type: E Priority: 2 Section: 9.5, 9.7.1, 9.7.2, nasreq 10.2 Rationale/Explanation of issue: Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present.". However, the Diameter node sending the accounting request may not know it. Still the target can use the various session-ID AVPs to correlate the records. There also seems to be some inconsistency in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2 (ACR, ACA definition) User-Name AVP is marked as optional while in section 10.2 it is again specified as MUST. Proposed change: I suggest modifying 9.5 so that it reads. "User-Name AVP MUST be present if it is available to the Diameter client." Then change the tables in 10.2 as follows: User-Name | 0+ | 0+ | From owner-aaa-wg@merit.edu Sun Feb 10 11:25:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07667 for ; Sun, 10 Feb 2002 11:25:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 05AF291211; Sun, 10 Feb 2002 11:25:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C7BB19121F; Sun, 10 Feb 2002 11:25:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BB72C91211 for ; Sun, 10 Feb 2002 11:25:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id A12C55DDCB; Sun, 10 Feb 2002 11:25:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (unknown [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id 66AA55DDC6 for ; Sun, 10 Feb 2002 11:25:31 -0500 (EST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 551396A907 for ; Sun, 10 Feb 2002 18:25:30 +0200 (EET) Message-ID: <3C669F38.5070802@kolumbus.fi> Date: Sun, 10 Feb 2002 18:26:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue about clarifying PDS/DSA roles in CMS 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 Submitter name: Jari Arkko Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03003.html Document: cms Comment type: E/T Priority: 2 Section: 1, 1.3, 7.1 Rationale/Explanation of issue: People who have read the CMS document do not clearly understand that PDS mechanisms are not intended to create actual security associations, but just to offload the computations to someone else. Secondly, the document does not explain what to do in case NO_CMS_THROUGH_PROXY is maliciously returned from somewhere else than in our own domain. Thirdly, there's some spelling problems. Requested change: Change > This specification contains two different set of messages. The DSA > messages are used to establish a security assocation, while the PDS > messages are used to request that a security association be > established by a third party. to This specification contains two different set of messages. The DSA messages are used to establish a security assocation, while the PDS messages are used to request that a security association be established by a third party. The security association established using DSA is used end-to-end for Diameter signaling, even through proxies that may exist in between. In constrast, where PDS messages are used, Diameter signaling is protected as usual only hop-by-hop between the client and the proxy handling CMS security on its behalf. From there onwards to the Diameter server, end-to-end protection is then used. Also in 1.3, "recelived" => "received". And just before the end of 1.3, the last "MAY" => "might". In 1.3, just before "If a DSA for a given realm cannot be established...", add a new paragraph: A proxy MAY both allow CMS security through itself and it can offer CMS services to the clients connecting to it. This would be useful in networks where some clients wish to use CMS security themselves, and some others need the proxy to assist them. However, it is necessary to prevent misconfigured clients from inappropriately sending PDS messages to nodes further onwards in the network, as this would leaeve the Diameter messaging without CMS protection when it leaves the proxy. For this reason, the DIAMETER_NO_CLEARTEXT_THROUGH_PROXY MUST be returned for PDS messages where Destination-Realm is not the proxy itself. This also ensures that rogue nodes further onwards in the network can not return DIAMETER_NO_CMS_THROUGH_PROXY in an attempt to bypass security mechanisms. And then add to section 7.1: DIAMETER_NO_CMS_THROUGH_PROXY 4014 This error code is returned when a non-transparent proxy receives an PDSR message to Destination-Realm that is not the proxy itself, and the proxy requires CMS security to be applied for all traffic leaving it. From owner-aaa-wg@merit.edu Sun Feb 10 11:44:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07898 for ; Sun, 10 Feb 2002 11:44:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5CBAD9121F; Sun, 10 Feb 2002 11:44:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EB1D91220; Sun, 10 Feb 2002 11:44:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42E8A9121F for ; Sun, 10 Feb 2002 11:44:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 201535DDC6; Sun, 10 Feb 2002 11:44:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 990005DDBC for ; Sun, 10 Feb 2002 11:44:03 -0500 (EST) Received: from localhost (httpd@localhost) by internaut.com (8.10.2/8.10.2) with SMTP id g1AG5df08334; Sun, 10 Feb 2002 08:05:39 -0800 Message-Id: <200202101605.g1AG5df08334@internaut.com> X-Authentication-Warning: internaut.com: httpd owned process doing -bs To: aaa-wg@merit.edu, Jari Arkko Subject: Re: [AAA-WG]: Issue about User-Name AVP and accounting Content-Type: text/plain; charset=iso-8859-1 X-Mailer: Cobalt Webmail Date: Sun, 10 Feb 2002 08:05:39 -0800 From: Bernard Aboba Sender: owner-aaa-wg@merit.edu Precedence: bulk Question: Why would the NAS not know the User-Name? Are we talking about call-check functionality, or is there another reason? ---------- Original message ---------- Date: Sun, 10 Feb 2002 18:02:54 +0200 From: Jari Arkko Reply-To: Jari Arkko To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue about User-Name AVP and accounting Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: base, nasreq Comment type: E Priority: 2 Section: 9.5, 9.7.1, 9.7.2, nasreq 10.2 Rationale/Explanation of issue: Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present.". However, the Diameter node sending the accounting request may not know it. Still the target can use the various session-ID AVPs to correlate the records. There also seems to be some inconsistency in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2 (ACR, ACA definition) User-Name AVP is marked as optional while in section 10.2 it is again specified as MUST. Proposed change: I suggest modifying 9.5 so that it reads. "User-Name AVP MUST be present if it is available to the Diameter client." Then change the tables in 10.2 as follows: User-Name | 0+ | 0+ | From owner-aaa-wg@merit.edu Sun Feb 10 11:50:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07959 for ; Sun, 10 Feb 2002 11:49:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5202791220; Sun, 10 Feb 2002 11:49:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2412291221; Sun, 10 Feb 2002 11:49:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19BAC91220 for ; Sun, 10 Feb 2002 11:49:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id ED0075DDCC; Sun, 10 Feb 2002 11:49:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (unknown [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id BB3EE5DDBC for ; Sun, 10 Feb 2002 11:49:47 -0500 (EST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id ADEC86A907; Sun, 10 Feb 2002 18:49:46 +0200 (EET) Message-ID: <3C66A4E8.8070408@kolumbus.fi> Date: Sun, 10 Feb 2002 18:50:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue about User-Name AVP and accounting References: <200202101605.g1AG5df08334@internaut.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 Bernard Aboba wrote: > Question: Why would the NAS not know the User-Name? Are we talking about call-check functionality, or is there another reason? This could be a NAS call which isn't authenticated at all by the NAS and L2TP tunneled to another device, and only have a phone number. Or this could be a Diameter node that is acting only for accounting purposes. Possibly, User-Name might not be available at an early stage of EAP authentication (since the server is to return the User-Name) -- but I'm not sure we are sending any accounting messages at that stage yet. Jari From owner-aaa-wg@merit.edu Sun Feb 10 11:55:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07996 for ; Sun, 10 Feb 2002 11:55:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8398F91221; Sun, 10 Feb 2002 11:55:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5BB6C91222; Sun, 10 Feb 2002 11:55:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5B9B391221 for ; Sun, 10 Feb 2002 11:55:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3340D5DDCC; Sun, 10 Feb 2002 11:55:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ws2.piuha.net (unknown [195.165.196.2]) by segue.merit.edu (Postfix) with ESMTP id F20E35DDBC for ; Sun, 10 Feb 2002 11:55:25 -0500 (EST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 11FE56A907 for ; Sun, 10 Feb 2002 18:55:25 +0200 (EET) Message-ID: <3C66A63B.20007@kolumbus.fi> Date: Sun, 10 Feb 2002 18:56:27 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue about which AVPs to encrypt and which not References: <3C6699AE.3020300@kolumbus.fi> 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 Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: cms, base Comment type: E Priority: 2 Section: base 4.6, cms 2.0, 3.1, 5.0 Rationale/Explanation of issue: 1) Base does not sufficiently explain what 'MAY encrypt' means in the AVP tables. Does it mean that it where CMS is used for the particular message, the AVPs MAY be encrypted, or does it mean that if CMS is used, they MUST be encrypted? 2) CMS flow example in 5.0 is misleading as to how the set of protected AVPs is decided. 3) There are several references to somehow negotiating the AVPs to be signed/encrypted. We have removed such functionality since this is really static information. Proposed change: 1) Add to the end of the first paragraph in base 4.6: "If an AVP MAY be encrypted, section 2.0 of the Diameter CMS security extension [11] defines in which situations the encryption is actually employed." Move the last paragraph of 3.1 to the end of 2.0, where I think it would be easier to find. In cms 3.1, change the text ", which specifies which AVPs should be encrypted, signed or both, as well as which public key(s) to use." to ", which specifies which public key(s) to use for signing and encryption of AVPs." Also, in cms 5.0, remove the last sentence of step (f). And the last sentence of (g). In step (h) change "which authenticates the AVPs that were requested by the Home Server in the DSAA." to "which authenticates the AVPs that MUST be authenticated as defined in section 2.0." In step (i) change "whose contents include the AVPs that were specified by the NAS in the DSAR." to "whose contents include the AVPs that MUST be encrypted as defined in section 2.0." From owner-aaa-wg@merit.edu Sun Feb 10 13:22:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08886 for ; Sun, 10 Feb 2002 13:22:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7963791222; Sun, 10 Feb 2002 13:21:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4353391224; Sun, 10 Feb 2002 13:21:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1060591222 for ; Sun, 10 Feb 2002 13:21:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB9D95DDCC; Sun, 10 Feb 2002 13:21:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 8E3425DDB5 for ; Sun, 10 Feb 2002 13:21:42 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RXPF>; Sun, 10 Feb 2002 10:21:40 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Jari Arkko'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue about which AVPs to encrypt and which not Date: Sun, 10 Feb 2002 10:21:36 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B25F.C6B87860" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B25F.C6B87860 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The WG decided to eliminate the Expected AVPs because of the possibility for conflicting information between the tables in the specifications, and what one sends in its Expected list of secured AVPs. I see no reason to go back to the more complex scheme. PatC - -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: Sunday, February 10, 2002 8:56 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue about which AVPs to encrypt and which not Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: cms, base Comment type: E Priority: 2 Section: base 4.6, cms 2.0, 3.1, 5.0 Rationale/Explanation of issue: 1) Base does not sufficiently explain what 'MAY encrypt' means in the AVP tables. Does it mean that it where CMS is used for the particular message, the AVPs MAY be encrypted, or does it mean that if CMS is used, they MUST be encrypted? 2) CMS flow example in 5.0 is misleading as to how the set of protected AVPs is decided. 3) There are several references to somehow negotiating the AVPs to be signed/encrypted. We have removed such functionality since this is really static information. Proposed change: 1) Add to the end of the first paragraph in base 4.6: "If an AVP MAY be encrypted, section 2.0 of the Diameter CMS security extension [11] defines in which situations the encryption is actually employed." Move the last paragraph of 3.1 to the end of 2.0, where I think it would be easier to find. In cms 3.1, change the text ", which specifies which AVPs should be encrypted, signed or both, as well as which public key(s) to use." to ", which specifies which public key(s) to use for signing and encryption of AVPs." Also, in cms 5.0, remove the last sentence of step (f). And the last sentence of (g). In step (h) change "which authenticates the AVPs that were requested by the Home Server in the DSAA." to "which authenticates the AVPs that MUST be authenticated as defined in section 2.0." In step (i) change "whose contents include the AVPs that were specified by the NAS in the DSAR." to "whose contents include the AVPs that MUST be encrypted as defined in section 2.0." -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGa6MDN1fXKoxmisEQKMFQCgjDcdh8r1GN8YjinjpkvM2JreEwYAoMl1 c1U1ScK97hAv7iKsn6nt2RBb =Q9eX -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B25F.C6B87860 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Issue about which AVPs to encrypt and which = not

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The WG decided to eliminate the Expected AVPs because = of the
possibility for conflicting information between the = tables in the
specifications, and what one sends in its Expected = list of secured
AVPs.

I see no reason to go back to the more complex = scheme.

PatC

- -----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi= ]
Sent: Sunday, February 10, 2002 8:56 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Issue about which AVPs to encrypt = and which not



Submitter name: Jari Arkko (Sebastian Zander)
Submitter email address: jari@arkko.com
Date first submitted: Feb 10, 2002
Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.htm= l
Document: cms, base
Comment type: E
Priority: 2
Section: base 4.6, cms 2.0, 3.1, 5.0
Rationale/Explanation of issue:


1) Base does not sufficiently explain what 'MAY = encrypt' means in the
AVP tables. Does it mean that it where CMS is used = for the particular
message, the AVPs MAY be encrypted, or does it mean = that if CMS is
used, they MUST be encrypted?

2) CMS flow example in 5.0 is misleading as to how = the
set of protected AVPs is decided.

3) There are several references to somehow = negotiating
the AVPs to be signed/encrypted. We have removed = such functionality
since this is really static information.


Proposed change:


1) Add to the end of the first paragraph in base 4.6: = "If an AVP MAY
be encrypted, section 2.0 of the Diameter CMS = security extension [11]
defines in which situations the encryption is = actually employed."

Move the last paragraph of 3.1 to the end of 2.0, = where I
think it would be easier to find.

In cms 3.1, change the text ", which specifies = which AVPs should be
encrypted, signed or both, as well as which = public
key(s) to use." to ", which specifies = which public key(s)
to use for signing and encryption of = AVPs."

Also, in cms 5.0, remove the last sentence of step = (f). And
the last sentence of (g).

In step (h) change "which authenticates the AVPs = that were requested
by the Home Server in the DSAA." to "which = authenticates the AVPs
that MUST be authenticated as defined in section = 2.0."

In step (i) change "whose contents include the = AVPs that were
specified by the NAS in the DSAR." to = "whose contents include the
AVPs that MUST be encrypted as defined in section = 2.0."

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGa6MDN1fXKoxmisEQKMFQCgjDcdh8r1GN8YjinjpkvM2JreEwYAoMl= 1
c1U1ScK97hAv7iKsn6nt2RBb
=3DQ9eX
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B25F.C6B87860-- From owner-aaa-wg@merit.edu Sun Feb 10 14:31:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09726 for ; Sun, 10 Feb 2002 14:31:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E50FF91258; Sun, 10 Feb 2002 14:30:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4CDD91259; Sun, 10 Feb 2002 14:30:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6B0991258 for ; Sun, 10 Feb 2002 14:30:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC06C5DDBB; Sun, 10 Feb 2002 14:30:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id E03875DDB5 for ; Sun, 10 Feb 2002 14:30:40 -0500 (EST) Received: from jariws1 ([62.248.145.2]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020210193034.VWIZ1076.fep06-app.kolumbus.fi@jariws1>; Sun, 10 Feb 2002 21:30:34 +0200 Message-ID: <002a01c1b269$6abf0ba0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat R. Calhoun" , References: Subject: Re: [AAA-WG]: Issue about which AVPs to encrypt and which not Date: Sun, 10 Feb 2002 21:30:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RE: [AAA-WG]: Issue about which AVPs to encrypt and which not>The WG decided to eliminate the Expected AVPs because of the >possibility for conflicting information between the tables in the >specifications, and what one sends in its Expected list of secured >AVPs. >I see no reason to go back to the more complex scheme. Agreed. I think the confusion arises from some parts of the old scheme still being visible in the text. My proposed fix tries to write everything in a manner where the data is fixed and not sent in the Expected lists. Jari From owner-aaa-wg@merit.edu Mon Feb 11 02:34:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26086 for ; Mon, 11 Feb 2002 02:34:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8AD2491216; Mon, 11 Feb 2002 02:33:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CD0F9125A; Mon, 11 Feb 2002 02:33:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3E36591216 for ; Mon, 11 Feb 2002 02:33:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 177375DDB2; Mon, 11 Feb 2002 02:33:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by segue.merit.edu (Postfix) with ESMTP id 5A6E35DD99 for ; Mon, 11 Feb 2002 02:33:55 -0500 (EST) Received: from fokus.fhg.de (dhcp187 [195.37.78.187]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g1B7XsE27743 for ; Mon, 11 Feb 2002 08:33:54 +0100 (MET) Message-ID: <3C6772E1.10FB9D0B@fokus.fhg.de> Date: Mon, 11 Feb 2002 08:29:37 +0100 From: Sebastian Zander Organization: FhI FOKUS X-Mailer: Mozilla 4.75 [de] (Windows NT 5.0; U) X-Accept-Language: de MIME-Version: 1.0 To: IETF AAA List Subject: [AAA-WG]: ISSUE: User-Name AVP should not be a MUST in accounting records Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Sebastian Zander Submitter email address: zander@fokus.fhg.de Date first submitted: February 11th, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02998.html Document: base-08 Comment type: T Priority: 1 Section: 9.5, 10.2 Rationale/Explanation of issue: Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present." The Diameter client may not know the user's identity. Therefore there can not be a MUST for including it. Furthermore there is some inconsistency in the draft since the User-Name AVP is already marked optional in section 9.7.1 and 9.7.2 but mandatory in section 10.2. Requested change: Section 9.5 should be changed to: "In all accounting records the Session-Id AVP MUST be present. The User-Name AVP MUST be present if it is available to the Diameter client." The table in section 10.2 should be changed so that User-Name is optional. -- Sebastian From owner-aaa-wg@merit.edu Mon Feb 11 07:22:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29123 for ; Mon, 11 Feb 2002 07:22:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F41E49121D; Mon, 11 Feb 2002 07:22:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7EFD91225; Mon, 11 Feb 2002 07:22:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 934639121D for ; Mon, 11 Feb 2002 07:22:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7370C5DDB9; Mon, 11 Feb 2002 07:22:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B16F15DD99 for ; Mon, 11 Feb 2002 07:22:07 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BCMDZ11026 for ; Mon, 11 Feb 2002 14:22:13 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 11 Feb 2002 14:22:06 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Feb 2002 14:22:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Diameter Port Reservation? Date: Mon, 11 Feb 2002 14:22:06 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCAA@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE: User-Name AVP should not be a MUST in accounting records Thread-Index: AcGyzoMbynSgTQtJTVeRVNhwtcADBQAJ1shQ From: To: X-OriginalArrivalTime: 11 Feb 2002 12:22:06.0851 (UTC) FILETIME=[B8668530:01C1B2F6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA29123 Hi all, In section 2.1 Transport: The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until IANA assigns a port to the protocol). When used with TLS [38], the Diameter protocol is run on port TBD of both TCP and SCTP. Has anyone yet reserved the ports for TCP & SCTP for Diameter? Or shall I, the trusty editior do this? Additionally, it would be worthwhile to reserve an SCTP Protocol Payload ID as well for Diameter. John From owner-aaa-wg@merit.edu Mon Feb 11 08:41:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01510 for ; Mon, 11 Feb 2002 08:41:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3619291225; Mon, 11 Feb 2002 08:41:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A2F191226; Mon, 11 Feb 2002 08:41:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1834691225 for ; Mon, 11 Feb 2002 08:41:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id E074C5DDBD; Mon, 11 Feb 2002 08:41:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by segue.merit.edu (Postfix) with ESMTP id 401A45DD99 for ; Mon, 11 Feb 2002 08:41:16 -0500 (EST) Received: from blues.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.227]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA08069; Mon, 11 Feb 2002 14:40:54 +0100 (MET) Received: from mchh273e.demchh201e.icn.siemens.de ([139.21.200.83]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA11876; Mon, 11 Feb 2002 14:40:50 +0100 (MET) Received: by MCHH273E with Internet Mail Service (5.5.2653.19) id <1JWX68DC>; Mon, 11 Feb 2002 14:40:54 +0100 Message-ID: From: Tuexen Michael To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Port Reservation? Date: Mon, 11 Feb 2002 14:40:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, it would be good to have a payload protocol identifier for Dianmeter/TLS as well. Best regards Michael Michael Tuexen Tel.: +49 89 722 47210 Siemens AG Fax: +49 89 722 48212 ICN WN CS SE 5 E-mail: Michael.Tuexen@icn.siemens.de > -----Original Message----- > From: john.loughney@nokia.com [SMTP:john.loughney@nokia.com] > Sent: Monday, February 11, 2002 1:22 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter Port Reservation? > > Hi all, > > In section 2.1 Transport: > > The base Diameter protocol is run on port TBD of both TCP [27] and > SCTP [26] transport protocols (for interoperability test purposes > port 1812 will be used until IANA assigns a port to the protocol). > When used with TLS [38], the Diameter protocol is run on port TBD of > both TCP and SCTP. > > Has anyone yet reserved the ports for TCP & SCTP for Diameter? Or > shall I, the trusty editior do this? > > Additionally, it would be worthwhile to reserve an SCTP > Protocol Payload ID as well for Diameter. > > John From owner-aaa-wg@merit.edu Mon Feb 11 09:22:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03262 for ; Mon, 11 Feb 2002 09:22:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2AE2891227; Mon, 11 Feb 2002 09:22:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0FDD9122A; Mon, 11 Feb 2002 09:22:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C436191227 for ; Mon, 11 Feb 2002 09:22:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id A674D5DDC0; Mon, 11 Feb 2002 09:22:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B879C5DD92 for ; Mon, 11 Feb 2002 09:22:05 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1BELUZ29097 for ; Mon, 11 Feb 2002 16:21:30 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 11 Feb 2002 16:21:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 11 Feb 2002 16:21:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter Port Reservation? Date: Mon, 11 Feb 2002 16:21:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64849@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Port Reservation? Thread-Index: AcGzAci5jRoOE9nuRRyMpxKMZ4/p6gABZE5A From: To: , X-OriginalArrivalTime: 11 Feb 2002 14:21:23.0638 (UTC) FILETIME=[622D8D60:01C1B307] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA03262 HI Michael, > it would be good to have a payload protocol > identifier for Dianmeter/TLS as well. Good point. John From owner-aaa-wg@merit.edu Mon Feb 11 10:18:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05168 for ; Mon, 11 Feb 2002 10:18:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4985B9125A; Mon, 11 Feb 2002 10:18:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 154409125B; Mon, 11 Feb 2002 10:18:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6E649125A for ; Mon, 11 Feb 2002 10:18:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id C867A5DD95; Mon, 11 Feb 2002 10:18:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 695215DD91 for ; Mon, 11 Feb 2002 10:18:17 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7RXV0>; Mon, 11 Feb 2002 07:17:37 -0800 Message-ID: From: "Pat R. Calhoun" To: "'john.loughney@nokia.com'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Diameter Port Reservation? Date: Mon, 11 Feb 2002 07:17:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B30F.3A5F25C0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1B30F.3A5F25C0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 IANA considerations section informs IANA to update TBD with the port assigned. A request was sent to IANA at least a year ago, and they stated that they would assign the port when the protocol was on the RFC editor's desk. PatC - -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Monday, February 11, 2002 4:22 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter Port Reservation? Hi all, In section 2.1 Transport: The base Diameter protocol is run on port TBD of both TCP [27] and SCTP [26] transport protocols (for interoperability test purposes port 1812 will be used until IANA assigns a port to the protocol). When used with TLS [38], the Diameter protocol is run on port TBD of both TCP and SCTP. Has anyone yet reserved the ports for TCP & SCTP for Diameter? Or shall I, the trusty editior do this? Additionally, it would be worthwhile to reserve an SCTP Protocol Payload ID as well for Diameter. John -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPGfgjDN1fXKoxmisEQL1JQCgiMJ4tBAIx/H9OmnuniOc2uBoQXYAnR7n FDY5lrXkqvxjOaCQBai7YPBk =LhAC -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1B30F.3A5F25C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Diameter Port Reservation?

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

IANA considerations section informs IANA to update = TBD with the port
assigned. A request was sent to IANA at least a year = ago, and they
stated that they would assign the port when the = protocol was on the
RFC editor's desk.

PatC

- -----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Monday, February 11, 2002 4:22 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter Port Reservation?


Hi all,

In section 2.1 Transport:

  The base Diameter protocol is run on port TBD = of both TCP [27] and
  SCTP [26] transport protocols (for = interoperability test purposes
  port 1812 will be used until IANA assigns a = port to the protocol).
  When used with TLS [38], the Diameter = protocol is run on port TBD
of
  both TCP and SCTP.

Has anyone yet reserved the ports for TCP & SCTP = for Diameter? Or
shall I, the trusty editior do this?

Additionally, it would be worthwhile to reserve an = SCTP Protocol
Payload ID as well for Diameter.

John

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPGfgjDN1fXKoxmisEQL1JQCgiMJ4tBAIx/H9OmnuniOc2uBoQXYAnR7= n
FDY5lrXkqvxjOaCQBai7YPBk
=3DLhAC
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1B30F.3A5F25C0-- From owner-aaa-wg@merit.edu Mon Feb 11 17:07:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19142 for ; Mon, 11 Feb 2002 17:07:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC57291229; Mon, 11 Feb 2002 17:06:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 963609122B; Mon, 11 Feb 2002 17:06:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F7FF91229 for ; Mon, 11 Feb 2002 17:06:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F0325DDB8; Mon, 11 Feb 2002 17:06:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 1B2D55DD92 for ; Mon, 11 Feb 2002 17:06:51 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1BM6oh13587 for ; Mon, 11 Feb 2002 16:06:50 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1BM6nx20744 for ; Mon, 11 Feb 2002 16:06:50 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA24807 for ; Mon, 11 Feb 2002 16:06:49 -0600 (CST) Received: from ericberk107 ([138.85.159.127]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id QAA24706 for ; Mon, 11 Feb 2002 16:06:48 -0600 (CST) From: "Kevin Purser" To: "IETF AAA List" Subject: [AAA-WG]: ISSUE: invalid reference Date: Mon, 11 Feb 2002 14:06:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-reply-to: <3C6772E1.10FB9D0B@fokus.fhg.de> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: February 11th, 2002 Reference: none Document: base-08alpha02 Comment type: Editorial Priority: 1 Section: 5.6 "Peer State Machine" Rationale/Explanation of issue: There are a couple of references in this section to "the state machine described in [52]". However, in the latest version of the transport draft, such a state machine is not present. Requested change: Remove these references in the text. From owner-aaa-wg@merit.edu Tue Feb 12 02:37:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05507 for ; Tue, 12 Feb 2002 02:37:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CEF449122C; Tue, 12 Feb 2002 02:37:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F11F91230; Tue, 12 Feb 2002 02:37:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 826179122C for ; Tue, 12 Feb 2002 02:37:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E0655DDCD; Tue, 12 Feb 2002 02:37:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A66EC5DDB7 for ; Tue, 12 Feb 2002 02:37:31 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1C7bbZ15731 for ; Tue, 12 Feb 2002 09:37:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 12 Feb 2002 09:37:30 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 12 Feb 2002 09:37:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter Port Reservation? Date: Tue, 12 Feb 2002 09:37:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6484D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter Port Reservation? Thread-Index: AcGzDz5y+9AMKhw7S4amUR408tlzlgAiNMmg From: To: , X-OriginalArrivalTime: 12 Feb 2002 07:37:30.0608 (UTC) FILETIME=[20945F00:01C1B398] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA05507 Hi Pat, > IANA considerations section informs IANA to update TBD with the port > assigned. A request was sent to IANA at least a year ago, and they > stated that they would assign the port when the protocol was on the > RFC editor's desk. That sounds like a plan to me. Thanks, John From owner-aaa-wg@merit.edu Wed Feb 13 11:48:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11224 for ; Wed, 13 Feb 2002 11:48:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B6669912B1; Wed, 13 Feb 2002 11:47:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 882BA912B3; Wed, 13 Feb 2002 11:47:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F2DB912B1 for ; Wed, 13 Feb 2002 11:47:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C25A5DDD9; Wed, 13 Feb 2002 11:47:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 723175DDAA for ; Wed, 13 Feb 2002 11:47:11 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1DG8Na20997 for ; Wed, 13 Feb 2002 08:08:23 -0800 Date: Wed, 13 Feb 2002 08:08:22 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Information on document preparation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Please Consult . "Considerations for Internet Drafts" - covers information on process, including nits that will insure that the IESG will return the draft. (http://www.ietf.org/ID-nits.html ) . "Recent and Proposed RFC Editorial Policy Changes" -- . http://www.rfc-editor.org/policy.html) *** Note: The latter is now policy. The remainder of the presentation was taken from 'A Year in the Life of an Internet Draft' by Ned Freed, Allison Mankin & Thomas Narten, with minor changes. Becoming an RFC - The Process . AD review (3 business days ;-) - Is document ready? . Is document full of nits? - Is IETF last call needed? . Required for BCP, Standards track . Sometimes used with Info or Experimental RFCs . 2 weeks for WG documents . During IETF Last call - Community has chance to comment - IANA review (IANA considerations) *** Note: IANA ONLY looks at the IANA consideration section. Make sure this section is clear and self contained. - RFC Editor check (formatting, normative refs, etc.) IESG Review . AD verifies that outstanding issues resolved, then sends to IESG for full review - Technical quality? - Interoperability? - Completeness? - Adequate security? - ID nits (MUST/MAY/SHOULD defined?...) - Readability? - Usefulness?... Returned Documents . IESG comments are returned to author(s)/WG chair/WG . Iteration sometimes necessary... . Revised ID may be needed . Revised drafts may go directly to IESG, may need WG last call, or even another IETF last call (extreme cases) Are We Done Yet? . IESG concerns satisfactorily addressed? . IANA concerns satisfactorily addressed? . No normative references to Internet Drafts? . Is final ID in ID directory? . Finally!!! - IESG Secretary sends approval announcement The RFC Editor's Turn . ID enters RFC editor's queue . Some IDs are more equal than others - Standards track, WG documents have priority - IESG sometimes requests high priority (e.g., for RFC needed by another standards body) . Editing process begins - Check with IANA - fill in IANA assigned values (Oops -- IANA has more questions...) - 48 hour author review . Author must OK final version (Hello... where are the authors???) . Editorial changes only (Oops - these changes seem substantive...) . An RFC is born!!! . Total Elapsed time: 2.7 weeks - 13.4 years :-) Something to Think About . Internet Draft Statistics (Dec. 12, 2001): - Overall: . 2972 total . 2313 (excluding expired -- < 4kB in size) - Working Group Ids (excluding expired) . 975 Ids . 197 -00 submissions - Individual Submissions (excluding expired) . 1338 IDs . 681 -00 submissions Useful URLs . http://www.ietf.org/ietf/1id-guidelines.txt . http://www.ietf.org/ID-nits.html . http://www.ietf.org/IESG/request.html . http://www.rfc-editor.org/queue.html . http://www.rfc-editor.org/howtopub.html From owner-aaa-wg@merit.edu Wed Feb 13 12:43:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15102 for ; Wed, 13 Feb 2002 12:43:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F323F912B6; Wed, 13 Feb 2002 12:42:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEBB8912B7; Wed, 13 Feb 2002 12:42:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B4C92912B6 for ; Wed, 13 Feb 2002 12:42:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9561D5DDD9; Wed, 13 Feb 2002 12:42:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id C32AA5DDAA for ; Wed, 13 Feb 2002 12:42:56 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1DHgsB08851 for ; Wed, 13 Feb 2002 18:42:54 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Feb 13 18:42:54 2002 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Feb 2002 18:42:52 +0100 Message-ID: <577066326047D41180AC00508B955DDA06C450B4@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Carolina Canales Valenzuela (ECE)" , "'mccap@lucent.com'" , "'jaakko.rajaniemi@nokia.com'" , "'Johanna.Wild@motorola.com'" , "'nhberry@lucent.com'" , "'dlwarren@nortelnetworks.com'" , "'peter.schmitt@icn.siemens.de'" , "'mikko.aittola@nokia.com'" , "Miguel-Angel Pallares-Lopez (ECE)" Subject: [AAA-WG]: RE:draft-johansson-aaa-diameter-mm-app-01.txt Date: Wed, 13 Feb 2002 18:42:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, taking in account the requirements draft "draft-calhoun-sip-aaa-reqs-03" (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-03.txt), in section 3.0, bullet 4, I can see there's a requirement for the AAA infrastructure to distribute (*push or pull*)subscriber/service/security profiles to the relevant SIP servers. In "draft-johansson-aaa-diameter-mm-app-01" this has been implemented as an only, bi-directional command, PUR (section 3.5). This command might be issued either by the AAA or by the SIP server, in order to update the user profile in the corresponding node. However, I think it could be useful to split this command in 2 uni-directional commands, one issued from the AAA and another one issued by the SIP server. The fact that such a command can be issued from the same node as a request and as a reply, adds a lot of complexity in the implementation part. Why not using two different commands? I think there is no shortage of command codes, right? ;-). BR, Carolina >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, February 12, 2002 1:02 PM >Cc: aaa-wg@merit.edu >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Diameter Multimedia Application > Author(s) : T. Johansson et al. > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > Pages : 31 > Date : 11-Feb-02 > >This document specifies a Diameter application that allows a Diameter >server to authenticate, authorize, and collect accounting information >for Session Initiation Protocol (SIP) services rendered to a client >node. This application, combined with the base Diameter protocol and >appropriate SIP extensions, allows SIP User Agents (UAs) to obtain >services from SIP servers that are connected to a Diameter >infrastructure. When combined with the Inter-Domain capability of >the base protocol, service may even be obtained from SIP servers that >belong to foreign domains, as would be encountered by roaming mobile >nodes. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete r-mm-app-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johansson-aaa-diameter-mm-app-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-aaa-wg@merit.edu Thu Feb 14 16:01:30 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09584 for ; Thu, 14 Feb 2002 16:01:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A8CAC912D7; Thu, 14 Feb 2002 15:58:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67D40912D6; Thu, 14 Feb 2002 15:58:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2B04B912D4 for ; Thu, 14 Feb 2002 15:58:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 10CFC5DDAD; Thu, 14 Feb 2002 15:58:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 9163A5DD98 for ; Thu, 14 Feb 2002 15:58:34 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1EKwUh29515 for ; Thu, 14 Feb 2002 14:58:30 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1EKwUt27105 for ; Thu, 14 Feb 2002 14:58:30 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA04146 for ; Thu, 14 Feb 2002 14:58:29 -0600 (CST) Received: from ericberk107 (letmein2-040.exu.ericsson.se [138.85.130.40]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id OAA04050 for ; Thu, 14 Feb 2002 14:58:28 -0600 (CST) Message-ID: <003f01c1b59a$5a6cdf00$6401a8c0@ew.us.am.ericsson.se> From: "Kevin Purser" To: "IETF AAA List" References: Subject: [AAA-WG]: ISSUE: redirect based on user names Date: Thu, 14 Feb 2002 12:58:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: February 14th, 2002 Reference: none Document: base-08alpha02 Comment type: Technical Priority: 1 Sections: 2.9.3, 6.12 Rationale/Explanation of issue: Diameter redirect agents currently provide realm to server address resolution. Within a single administrative domain, it could be useful to allow redirect agents to have the option of providing user to server address resolution. Requested change: * change the first paragraph of section 2.9.3 to read: Redirect agents provide Realm to Server address resolution and MAY also provide User to Server address resolution. These redirect agents would make use of the Diameter routing table or optionally, a user table to determine where a given request should be forwarded. When a request is received by a redirect agent, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact directly. * add the following enumerated value in section 6.12: ALL_USER 6 All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP. From owner-aaa-wg@merit.edu Fri Feb 15 04:34:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00953 for ; Fri, 15 Feb 2002 04:34:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0DD5A912C6; Fri, 15 Feb 2002 04:34:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD84C912D1; Fri, 15 Feb 2002 04:34:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B074912C6 for ; Fri, 15 Feb 2002 04:34:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7808D5DDB4; Fri, 15 Feb 2002 04:34:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by segue.merit.edu (Postfix) with ESMTP id F14655DDAC for ; Fri, 15 Feb 2002 04:34:05 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1F9XehM024101 for ; Fri, 15 Feb 2002 10:33:40 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Feb 15 10:33:40 2002 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 10:33:22 +0100 Message-ID: <577066326047D41180AC00508B955DDA06C450C3@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE-SENT:draft-johansson-aaa-diameter-mm-app-01.txt Date: Fri, 15 Feb 2002 10:33:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, There was a problem with my e-mail system and I received an strange error message after sending this e-mail. I'm re-sending it, in case it was not received. Sorry if you receive it twice. Hello, taking in account the requirements draft "draft-calhoun-sip-aaa-reqs-03" (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa-reqs-03.txt), in section 3.0, bullet 4, I can see there's a requirement for the AAA infrastructure to distribute (*push or pull*)subscriber/service/security profiles to the relevant SIP servers. In "draft-johansson-aaa-diameter-mm-app-01" this has been implemented as an only, bi-directional command, PUR (section 3.5). This command might be issued either by the AAA or by the SIP server, in order to update the user profile in the corresponding node. However, I think it could be useful to split this command in 2 uni-directional commands, one issued from the AAA and another one issued by the SIP server. The fact that such a command can be issued from the same node as a request and as a reply, adds a lot of complexity in the implementation part. Why not using two different commands? I think there is no shortage of command codes, right? ;-). BR, Carolina >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, February 12, 2002 1:02 PM >Cc: aaa-wg@merit.edu >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > >A New Internet-Draft is available from the on-line >Internet-Drafts directories. > > > Title : Diameter Multimedia Application > Author(s) : T. Johansson et al. > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > Pages : 31 > Date : 11-Feb-02 > >This document specifies a Diameter application that allows a Diameter >server to authenticate, authorize, and collect accounting information >for Session Initiation Protocol (SIP) services rendered to a client >node. This application, combined with the base Diameter protocol and >appropriate SIP extensions, allows SIP User Agents (UAs) to obtain >services from SIP servers that are connected to a Diameter >infrastructure. When combined with the Inter-Domain capability of >the base protocol, service may even be obtained from SIP servers that >belong to foreign domains, as would be encountered by roaming mobile >nodes. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete r-mm-app-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-johansson-aaa-diameter-mm-app-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-aaa-wg@merit.edu Fri Feb 15 04:57:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01214 for ; Fri, 15 Feb 2002 04:57:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72F9C912D1; Fri, 15 Feb 2002 04:57:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4276A912D2; Fri, 15 Feb 2002 04:57:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFE44912D1 for ; Fri, 15 Feb 2002 04:56:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id C17395DDB4; Fri, 15 Feb 2002 04:56:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 467685DD9E for ; Fri, 15 Feb 2002 04:56:32 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1F9udi26565 for ; Fri, 15 Feb 2002 11:56:39 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Feb 2002 11:56:14 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Feb 2002 11:56:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Fri, 15 Feb 2002 11:56:13 +0200 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB43@esebe013.NOE.Nokia.com> Thread-Topic: draft-johansson-aaa-diameter-mm-app-01.txt Thread-Index: AcG0td6g82xMcEZgQbCyDoNxLYUF9ABTg++w From: To: , Cc: , , , , , , X-OriginalArrivalTime: 15 Feb 2002 09:56:14.0456 (UTC) FILETIME=[01380780:01C1B607] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA01214 Hi, In addition, PUR/PUA command is also used in the draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) registering the user, either from the AAAH or the client. From the logical point of view the profile updating and (-/re/de-) registration are different operations and therefore it would be quite natural to separate the profile updating from the registration. This could be done by specifying different command codes for the profile and the registration related operations. Best Regards, Jaakko > -----Original Message----- > From: ext carolina.canales-valenzuela@ece.ericsson.se > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > Sent: 13 February, 2002 19:42 > To: 'aaa-wg@merit.edu' > Cc: Carolina Canales Valenzuela (ECE); 'mccap@lucent.com'; Rajaniemi > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; 'nhberry@lucent.com'; > 'dlwarren@nortelnetworks.com'; 'peter.schmitt@icn.siemens.de'; Aittola > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > Hello, > taking in account the requirements draft > "draft-calhoun-sip-aaa-reqs-03" > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > requirement for the AAA infrastructure to distribute (*push > or pull*)subscriber/service/security profiles to the relevant > SIP servers. > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > implemented as an only, bi-directional command, PUR (section > 3.5). This command might be issued either by the AAA or by > the SIP server, in order to update the user profile in the > corresponding node. > > However, I think it could be useful to split this command in > 2 uni-directional commands, one issued from the AAA and > another one issued by the SIP server. > > The fact that such a command can be issued from the same node > as a request and as a reply, adds a lot of complexity in the > implementation part. Why not using two different commands? I > think there is no shortage of command codes, right? ;-). > > BR, > Carolina > > > >-----Original Message----- > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > >Sent: Tuesday, February 12, 2002 1:02 PM > >Cc: aaa-wg@merit.edu > >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > >A New Internet-Draft is available from the on-line > >Internet-Drafts directories. > > > > > > Title : Diameter Multimedia Application > > Author(s) : T. Johansson et al. > > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > > Pages : 31 > > Date : 11-Feb-02 > > > >This document specifies a Diameter application that allows a Diameter > >server to authenticate, authorize, and collect accounting information > >for Session Initiation Protocol (SIP) services rendered to a client > >node. This application, combined with the base Diameter protocol and > >appropriate SIP extensions, allows SIP User Agents (UAs) to obtain > >services from SIP servers that are connected to a Diameter > >infrastructure. When combined with the Inter-Domain capability of > >the base protocol, service may even be obtained from SIP servers that > >belong to foreign domains, as would be encountered by roaming mobile > >nodes. > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > r-mm-app-01.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body > of the message. > > Internet-Drafts are also available by anonymous FTP. Login > with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant > mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From owner-aaa-wg@merit.edu Fri Feb 15 05:38:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01655 for ; Fri, 15 Feb 2002 05:38:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F501912D2; Fri, 15 Feb 2002 05:37:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0F85912D3; Fri, 15 Feb 2002 05:37:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1429912D2 for ; Fri, 15 Feb 2002 05:37:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC2B35DDE9; Fri, 15 Feb 2002 05:37:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by segue.merit.edu (Postfix) with ESMTP id 296FF5DDE5 for ; Fri, 15 Feb 2002 05:37:50 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1FAbjhM008741 for ; Fri, 15 Feb 2002 11:37:45 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Feb 15 11:37:45 2002 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Feb 2002 11:37:26 +0100 Message-ID: <577066326047D41180AC00508B955DDA05ED1EA4@eestqnt104.es.eu.ericsson.se> From: "Miguel-Angel Pallares-Lopez (ECE)" To: aaa-wg@merit.edu Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Fri, 15 Feb 2002 11:37:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, So we would have three commands: - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). - One (AAA->SSP) to de-register the user from AAA to SSP (Registration-Termination-Request, RTR?). - One (SSP->AAA) to update registration information and to pull user data. It seems sensible to me. I agree that their semantic is different and we are not going to run out of commands codes. Best regards, Miguel > -----Original Message----- > From: jaakko.rajaniemi@nokia.com [mailto:jaakko.rajaniemi@nokia.com] > Sent: Friday, February 15, 2002 10:56 AM > To: carolina.canales-valenzuela@ece.ericsson.se; aaa-wg@merit.edu > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; nhberry@lucent.com; > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > mikko.aittola@nokia.com; Miguel-Angel.Pallares-Lopez@ece.ericsson.se > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > Hi, > > In addition, PUR/PUA command is also used in the > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > registering the user, either from the AAAH or the client. > From the logical point of view the profile updating and > (-/re/de-) registration are different operations and > therefore it would be quite natural to separate the profile > updating from the registration. > > This could be done by specifying different command codes for > the profile and the registration related operations. > > Best Regards, Jaakko > > > -----Original Message----- > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > Sent: 13 February, 2002 19:42 > > To: 'aaa-wg@merit.edu' > > Cc: Carolina Canales Valenzuela (ECE); 'mccap@lucent.com'; Rajaniemi > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > 'nhberry@lucent.com'; > > 'dlwarren@nortelnetworks.com'; > 'peter.schmitt@icn.siemens.de'; Aittola > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > Hello, > > taking in account the requirements draft > > "draft-calhoun-sip-aaa-reqs-03" > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > requirement for the AAA infrastructure to distribute (*push > > or pull*)subscriber/service/security profiles to the relevant > > SIP servers. > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > implemented as an only, bi-directional command, PUR (section > > 3.5). This command might be issued either by the AAA or by > > the SIP server, in order to update the user profile in the > > corresponding node. > > > > However, I think it could be useful to split this command in > > 2 uni-directional commands, one issued from the AAA and > > another one issued by the SIP server. > > > > The fact that such a command can be issued from the same node > > as a request and as a reply, adds a lot of complexity in the > > implementation part. Why not using two different commands? I > > think there is no shortage of command codes, right? ;-). > > > > BR, > > Carolina > > > > > > >-----Original Message----- > > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > >Sent: Tuesday, February 12, 2002 1:02 PM > > >Cc: aaa-wg@merit.edu > > >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > >A New Internet-Draft is available from the on-line > > >Internet-Drafts directories. > > > > > > > > > Title : Diameter Multimedia Application > > > Author(s) : T. Johansson et al. > > > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > > > Pages : 31 > > > Date : 11-Feb-02 > > > > > >This document specifies a Diameter application that allows > a Diameter > > >server to authenticate, authorize, and collect accounting > information > > >for Session Initiation Protocol (SIP) services rendered to a client > > >node. This application, combined with the base Diameter > protocol and > > >appropriate SIP extensions, allows SIP User Agents (UAs) to obtain > > >services from SIP servers that are connected to a Diameter > > >infrastructure. When combined with the Inter-Domain capability of > > >the base protocol, service may even be obtained from SIP > servers that > > >belong to foreign domains, as would be encountered by > roaming mobile > > >nodes. > > > > > >A URL for this Internet-Draft is: > > >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > r-mm-app-01.txt > > > > To remove yourself from the IETF Announcement list, send a > message to > > ietf-announce-request with the word unsubscribe in the body > > of the message. > > > > Internet-Drafts are also available by anonymous FTP. Login > > with the username > > "anonymous" and a password of your e-mail address. After logging in, > > type "cd internet-drafts" and then > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > > mailserv@ietf.org. > > In the body type: > > "FILE > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant > > mail readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > From owner-aaa-wg@merit.edu Fri Feb 15 07:34:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03386 for ; Fri, 15 Feb 2002 07:34:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83E49912D6; Fri, 15 Feb 2002 07:33:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F8C9912DC; Fri, 15 Feb 2002 07:33:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A97FD912D6 for ; Fri, 15 Feb 2002 07:33:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D4445DDB7; Fri, 15 Feb 2002 07:33:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 093E55DDB6 for ; Fri, 15 Feb 2002 07:33:19 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FCXbi05999 for ; Fri, 15 Feb 2002 14:33:37 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Feb 2002 14:33:10 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Feb 2002 14:33:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Fri, 15 Feb 2002 14:33:10 +0200 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB47@esebe013.NOE.Nokia.com> Thread-Topic: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Thread-Index: AcG2DQX44Pq6NRjKSBKLTcEAEm4TnwADqZ8Q From: To: , X-OriginalArrivalTime: 15 Feb 2002 12:33:10.0779 (UTC) FILETIME=[EDC8E4B0:01C1B61C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA03386 Hi, > So we would have three commands: > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > - One (AAA->SSP) to de-register the user from AAA to SSP > (Registration-Termination-Request, RTR?). > - One (SSP->AAA) to update registration information and to > pull user data. Right, this was what I had in mind. The SIP-Profile-Update-Type AVP could be changed in such a way that at least the UPDATE_PROFILE value is removed and the name of the AVP could be something else e.g. SIP-Server-Assignment-Type. What about the RETRIEVE_PROFILE value of the SIP-Profile-Update-Type AVP? Should we keep it or remove it? The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT value is not clear. Best Regards, Jaakko > -----Original Message----- > From: ext Miguel-Angel Pallares-Lopez (ECE) > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > Sent: 15 February, 2002 12:37 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > Hi, > > So we would have three commands: > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > - One (AAA->SSP) to de-register the user from AAA to SSP > (Registration-Termination-Request, RTR?). > - One (SSP->AAA) to update registration information and to > pull user data. > > It seems sensible to me. I agree that their semantic is > different and we are not going to run out of commands codes. > > Best regards, > Miguel > > > -----Original Message----- > > From: jaakko.rajaniemi@nokia.com [mailto:jaakko.rajaniemi@nokia.com] > > Sent: Friday, February 15, 2002 10:56 AM > > To: carolina.canales-valenzuela@ece.ericsson.se; aaa-wg@merit.edu > > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; nhberry@lucent.com; > > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > > mikko.aittola@nokia.com; Miguel-Angel.Pallares-Lopez@ece.ericsson.se > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > Hi, > > > > In addition, PUR/PUA command is also used in the > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > > registering the user, either from the AAAH or the client. > > From the logical point of view the profile updating and > > (-/re/de-) registration are different operations and > > therefore it would be quite natural to separate the profile > > updating from the registration. > > > > This could be done by specifying different command codes for > > the profile and the registration related operations. > > > > Best Regards, Jaakko > > > > > -----Original Message----- > > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > > Sent: 13 February, 2002 19:42 > > > To: 'aaa-wg@merit.edu' > > > Cc: Carolina Canales Valenzuela (ECE); > 'mccap@lucent.com'; Rajaniemi > > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > > 'nhberry@lucent.com'; > > > 'dlwarren@nortelnetworks.com'; > > 'peter.schmitt@icn.siemens.de'; Aittola > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > Hello, > > > taking in account the requirements draft > > > "draft-calhoun-sip-aaa-reqs-03" > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > > requirement for the AAA infrastructure to distribute (*push > > > or pull*)subscriber/service/security profiles to the relevant > > > SIP servers. > > > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > > implemented as an only, bi-directional command, PUR (section > > > 3.5). This command might be issued either by the AAA or by > > > the SIP server, in order to update the user profile in the > > > corresponding node. > > > > > > However, I think it could be useful to split this command in > > > 2 uni-directional commands, one issued from the AAA and > > > another one issued by the SIP server. > > > > > > The fact that such a command can be issued from the same node > > > as a request and as a reply, adds a lot of complexity in the > > > implementation part. Why not using two different commands? I > > > think there is no shortage of command codes, right? ;-). > > > > > > BR, > > > Carolina > > > > > > > > > >-----Original Message----- > > > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > >Sent: Tuesday, February 12, 2002 1:02 PM > > > >Cc: aaa-wg@merit.edu > > > >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > >Internet-Drafts directories. > > > > > > > > > > > > Title : Diameter Multimedia Application > > > > Author(s) : T. Johansson et al. > > > > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > > > > Pages : 31 > > > > Date : 11-Feb-02 > > > > > > > >This document specifies a Diameter application that allows > > a Diameter > > > >server to authenticate, authorize, and collect accounting > > information > > > >for Session Initiation Protocol (SIP) services rendered > to a client > > > >node. This application, combined with the base Diameter > > protocol and > > > >appropriate SIP extensions, allows SIP User Agents (UAs) > to obtain > > > >services from SIP servers that are connected to a Diameter > > > >infrastructure. When combined with the Inter-Domain > capability of > > > >the base protocol, service may even be obtained from SIP > > servers that > > > >belong to foreign domains, as would be encountered by > > roaming mobile > > > >nodes. > > > > > > > >A URL for this Internet-Draft is: > > > >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > > r-mm-app-01.txt > > > > > > To remove yourself from the IETF Announcement list, send a > > message to > > > ietf-announce-request with the word unsubscribe in the body > > > of the message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > with the username > > > "anonymous" and a password of your e-mail address. After > logging in, > > > type "cd internet-drafts" and then > > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > A list of Internet-Drafts directories can be found in > > > http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > Send a message to: > > > mailserv@ietf.org. > > > In the body type: > > > "FILE > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > NOTE: The mail server at ietf.org can return the document in > > > MIME-encoded form by using the "mpack" utility. To use this > > > feature, insert the command "ENCODING mime" before the "FILE" > > > command. To decode the response(s), you will need "munpack" or > > > a MIME-compliant mail reader. Different MIME-compliant > > > mail readers > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > From owner-aaa-wg@merit.edu Fri Feb 15 07:59:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03980 for ; Fri, 15 Feb 2002 07:59:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43B90912D8; Fri, 15 Feb 2002 07:58:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 152E9912DC; Fri, 15 Feb 2002 07:58:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 034DD912D8 for ; Fri, 15 Feb 2002 07:58:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id D98685DDB7; Fri, 15 Feb 2002 07:58:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 78D855DDB6 for ; Fri, 15 Feb 2002 07:58:55 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1FCwvZ25473 for ; Fri, 15 Feb 2002 14:58:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Feb 2002 14:58:49 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Feb 2002 14:58:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE: redirect based on user names Date: Fri, 15 Feb 2002 14:58:49 +0200 Message-ID: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB48@esebe013.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE: redirect based on user names Thread-Index: AcG1mtkzskTqDkjPTgKD1wnfKdaHGAAghkCw From: To: , X-OriginalArrivalTime: 15 Feb 2002 12:58:49.0696 (UTC) FILETIME=[830CFE00:01C1B620] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA03980 I think that this change is useful. Best Regards, Jaakko > -----Original Message----- > From: ext Kevin Purser [mailto:kevin.purser@ericsson.com] > Sent: 14 February, 2002 22:58 > To: IETF AAA List > Subject: [AAA-WG]: ISSUE: redirect based on user names > > > Submitter name: Kevin Purser > Submitter email address: kevin.purser@ericsson.com > Date first submitted: February 14th, 2002 > Reference: none > Document: base-08alpha02 > Comment type: Technical > Priority: 1 > Sections: 2.9.3, 6.12 > Rationale/Explanation of issue: > > Diameter redirect agents currently provide realm to server address > resolution. Within a single administrative domain, it could > be useful to > allow redirect agents to have the option of providing user to > server address > resolution. > > Requested change: > > * change the first paragraph of section 2.9.3 to read: > > Redirect agents provide Realm to Server address resolution > and MAY also > provide User to Server address resolution. These redirect > agents would make > use of the Diameter routing table or optionally, a user table > to determine > where a given request should be forwarded. When a request is > received by a > redirect agent, a special answer is created, which includes > the identity of > the Diameter server(s) the originator of the request should contact > directly. > > * add the following enumerated value in section 6.12: > > ALL_USER 6 > All messages for the user requested MAY be sent to the > host specified in the Redirect-Host AVP. > > > From owner-aaa-wg@merit.edu Fri Feb 15 11:48:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10953 for ; Fri, 15 Feb 2002 11:48:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68FE491211; Fri, 15 Feb 2002 11:47:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 81A72912DC; Fri, 15 Feb 2002 11:47:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7075B91211 for ; Fri, 15 Feb 2002 11:47:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 542445DDBE; Fri, 15 Feb 2002 11:47:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id DB0885DD9E for ; Fri, 15 Feb 2002 11:47:44 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1FGlcP14844; Fri, 15 Feb 2002 11:47:39 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA08578; Fri, 15 Feb 2002 10:47:38 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id KAA23212; Fri, 15 Feb 2002 10:47:38 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15469.15273.890301.860002@nwsgpb.ih.lucent.com> Date: Fri, 15 Feb 2002 10:47:37 -0600 (CST) From: Pete McCann To: Cc: , Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt In-Reply-To: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB47@esebe013.NOE.Nokia.com> References: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB47@esebe013.NOE.Nokia.com> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A couple of questions for the working group: * Is it technically OK to use a message in both directions (client->server and server->client)? I think the answer is yes, although most existing Diameter applications don't do this. Are there any other considerations of which we should be aware? * Couldn't we use ASR for terminating registration sessions? -Pete jaakko.rajaniemi@nokia.com writes: > Hi, > > > So we would have three commands: > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > - One (AAA->SSP) to de-register the user from AAA to SSP > > (Registration-Termination-Request, RTR?). > > - One (SSP->AAA) to update registration information and to > > pull user data. > > Right, this was what I had in mind. The SIP-Profile-Update-Type AVP could be changed in such a way that at least the UPDATE_PROFILE value is removed and the name of the AVP could be something else e.g. SIP-Server-Assignment-Type. > > What about the RETRIEVE_PROFILE value of the SIP-Profile-Update-Type AVP? Should we keep it or remove it? The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT value is not clear. > > Best Regards, Jaakko > > > -----Original Message----- > > From: ext Miguel-Angel Pallares-Lopez (ECE) > > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > > Sent: 15 February, 2002 12:37 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > Hi, > > > > So we would have three commands: > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > - One (AAA->SSP) to de-register the user from AAA to SSP > > (Registration-Termination-Request, RTR?). > > - One (SSP->AAA) to update registration information and to > > pull user data. > > > > It seems sensible to me. I agree that their semantic is > > different and we are not going to run out of commands codes. > > > > Best regards, > > Miguel > > > > > -----Original Message----- > > > From: jaakko.rajaniemi@nokia.com [mailto:jaakko.rajaniemi@nokia.com] > > > Sent: Friday, February 15, 2002 10:56 AM > > > To: carolina.canales-valenzuela@ece.ericsson.se; aaa-wg@merit.edu > > > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; nhberry@lucent.com; > > > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > > > mikko.aittola@nokia.com; Miguel-Angel.Pallares-Lopez@ece.ericsson.se > > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > Hi, > > > > > > In addition, PUR/PUA command is also used in the > > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > > > registering the user, either from the AAAH or the client. > > > From the logical point of view the profile updating and > > > (-/re/de-) registration are different operations and > > > therefore it would be quite natural to separate the profile > > > updating from the registration. > > > > > > This could be done by specifying different command codes for > > > the profile and the registration related operations. > > > > > > Best Regards, Jaakko > > > > > > > -----Original Message----- > > > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > > > Sent: 13 February, 2002 19:42 > > > > To: 'aaa-wg@merit.edu' > > > > Cc: Carolina Canales Valenzuela (ECE); > > 'mccap@lucent.com'; Rajaniemi > > > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > > > 'nhberry@lucent.com'; > > > > 'dlwarren@nortelnetworks.com'; > > > 'peter.schmitt@icn.siemens.de'; Aittola > > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > Hello, > > > > taking in account the requirements draft > > > > "draft-calhoun-sip-aaa-reqs-03" > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > > > requirement for the AAA infrastructure to distribute (*push > > > > or pull*)subscriber/service/security profiles to the relevant > > > > SIP servers. > > > > > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > > > implemented as an only, bi-directional command, PUR (section > > > > 3.5). This command might be issued either by the AAA or by > > > > the SIP server, in order to update the user profile in the > > > > corresponding node. > > > > > > > > However, I think it could be useful to split this command in > > > > 2 uni-directional commands, one issued from the AAA and > > > > another one issued by the SIP server. > > > > > > > > The fact that such a command can be issued from the same node > > > > as a request and as a reply, adds a lot of complexity in the > > > > implementation part. Why not using two different commands? I > > > > think there is no shortage of command codes, right? ;-). > > > > > > > > BR, > > > > Carolina > > > > > > > > > > > > >-----Original Message----- > > > > >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > > > >Sent: Tuesday, February 12, 2002 1:02 PM > > > > >Cc: aaa-wg@merit.edu > > > > >Subject: I-D ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > >Internet-Drafts directories. > > > > > > > > > > > > > > > Title : Diameter Multimedia Application > > > > > Author(s) : T. Johansson et al. > > > > > Filename : draft-johansson-aaa-diameter-mm-app-01.txt > > > > > Pages : 31 > > > > > Date : 11-Feb-02 > > > > > > > > > >This document specifies a Diameter application that allows > > > a Diameter > > > > >server to authenticate, authorize, and collect accounting > > > information > > > > >for Session Initiation Protocol (SIP) services rendered > > to a client > > > > >node. This application, combined with the base Diameter > > > protocol and > > > > >appropriate SIP extensions, allows SIP User Agents (UAs) > > to obtain > > > > >services from SIP servers that are connected to a Diameter > > > > >infrastructure. When combined with the Inter-Domain > > capability of > > > > >the base protocol, service may even be obtained from SIP > > > servers that > > > > >belong to foreign domains, as would be encountered by > > > roaming mobile > > > > >nodes. > > > > > > > > > >A URL for this Internet-Draft is: > > > > >http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > > > r-mm-app-01.txt > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > message to > > > > ietf-announce-request with the word unsubscribe in the body > > > > of the message. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > with the username > > > > "anonymous" and a password of your e-mail address. After > > logging in, > > > > type "cd internet-drafts" and then > > > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > A list of Internet-Drafts directories can be found in > > > > http://www.ietf.org/shadow.html > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > Send a message to: > > > > mailserv@ietf.org. > > > > In the body type: > > > > "FILE > > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > MIME-encoded form by using the "mpack" utility. To use this > > > > feature, insert the command "ENCODING mime" before the "FILE" > > > > command. To decode the response(s), you will need "munpack" or > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > mail readers > > > > exhibit different behavior, especially when dealing with > > > > "multipart" MIME messages (i.e. documents which have been split > > > > up into multiple messages), so check your local documentation on > > > > how to manipulate these messages. > > > > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > > implementation to automatically retrieve the ASCII version of the > > > > Internet-Draft. > > > > > > > > > > From owner-aaa-wg@merit.edu Fri Feb 15 13:04:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14268 for ; Fri, 15 Feb 2002 13:04:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C8204912DC; Fri, 15 Feb 2002 13:04:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95B36912DD; Fri, 15 Feb 2002 13:04:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87BED912DC for ; Fri, 15 Feb 2002 13:04:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 646DB5DDC6; Fri, 15 Feb 2002 13:04:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (unknown [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 838EE5DD9A for ; Fri, 15 Feb 2002 13:04:31 -0500 (EST) Received: from jariws1 ([62.248.149.81]) by fep02-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020215180423.DPYJ21965.fep02-app.kolumbus.fi@jariws1>; Fri, 15 Feb 2002 20:04:23 +0200 Message-ID: <001901c1b64b$36160620$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pete McCann" , Cc: , References: <84230E60BFCF6B4FB0360BAE4C9B3EB562AB47@esebe013.NOE.Nokia.com> <15469.15273.890301.860002@nwsgpb.ih.lucent.com> Subject: Re: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Fri, 15 Feb 2002 20:04:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > A couple of questions for the working group: > > * Is it technically OK to use a message in both directions > (client->server and server->client)? I think the answer is yes, > although most existing Diameter applications don't do this. > Are there any other considerations of which we should be aware? Do you mean the *same* message in two directions? Hmm... might be better to have two different ones just for clarity. > * Couldn't we use ASR for terminating registration sessions? Yes, why not. Jari From owner-aaa-wg@merit.edu Mon Feb 18 04:21:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29035 for ; Mon, 18 Feb 2002 04:21:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2DE489123A; Mon, 18 Feb 2002 04:21:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E7D8A9125E; Mon, 18 Feb 2002 04:21:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B2E709123A for ; Mon, 18 Feb 2002 04:21:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 92B225DE26; Mon, 18 Feb 2002 04:21:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 9D33A5DE23 for ; Mon, 18 Feb 2002 04:21:28 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1I9LWZ05096 for ; Mon, 18 Feb 2002 11:21:32 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 18 Feb 2002 11:21:18 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 18 Feb 2002 11:21:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references Date: Mon, 18 Feb 2002 11:21:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC648EB@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references Thread-Index: AcGpA41wLFg6gCD2RzepMXHAf66huQPWZ/Dg From: To: , X-OriginalArrivalTime: 18 Feb 2002 09:21:18.0380 (UTC) FILETIME=[9F1976C0:01C1B85D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29035 Hi Mark, Going through this exercise myself, I think that all of the references you mentioned (4,5,6,14,19,39 & 48) should be dropped. John > -----Original Message----- > From: ext Mark Eklund [mailto:meklund@cisco.com] > Sent: 29 January, 2002 21:43 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references > > > When Jari did the work of determining Normative vs Informative, he > couldn't find the following references referenced in the body of the > base draft. Do we leave them in, or drop them from the base? > > My vote, drop 4, 5, 6, 14, and 19 from the base (keep in CMS if it > makes sense). I have no opinion on 39, and 48. > > No mention of MD5 in this draft: > [4] Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. > > No mention in this draft: > [5] Kaufman, Perlman, Speciner, "Network Security: Private Communica- > tions in a Public World", Prentice Hall, March 1995, ISBN > 0-13-061466-1. > > A part of the obsolete Integrity-Check-Value AVP > [6] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message > Authentication", RFC 2104, January 1997. > > Older drafts mentioned DIAMETER Message Security requiring a > Public Key > Infrastructure. > [14] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet > Public Key > Infrastructure Online Certificate Status Protocol (OCSP)", RFC > 2560, June 1999. > > No mention in this draft. > [19] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- > ture Certificate and CRL Profile", RFC 2459, January 1999. > > No mention in the draft. > [39] "The Communications of the ACM" Vol.33, No.6 (June 1990), pp. > 677-680. > > No mention in the draft. > [48] P. V. Mockapetris, "Domain names - implementation and specifica- > tion," RFC 1035, November 1987. > > -mark > From owner-aaa-wg@merit.edu Mon Feb 18 23:12:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00602 for ; Mon, 18 Feb 2002 23:12:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7905291247; Mon, 18 Feb 2002 23:12:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CAFB91246; Mon, 18 Feb 2002 23:12:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E02AA91247 for ; Mon, 18 Feb 2002 23:12:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id B57F35DDD3; Mon, 18 Feb 2002 23:12:13 -0500 (EST) 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 0A3AA5DDA6 for ; Mon, 18 Feb 2002 23:12:13 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1J4Bi302602 for ; Tue, 19 Feb 2002 06:11:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Feb 2002 06:12:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 06:12:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: [issue] DNS SRV text needs to be updated. Date: Tue, 19 Feb 2002 06:12:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22899@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references Thread-Index: AcGpA41wLFg6gCD2RzepMXHAf66huQPWZ/DgABUwN9AAADtFIA== From: To: X-OriginalArrivalTime: 19 Feb 2002 04:12:11.0842 (UTC) FILETIME=[9AEA1A20:01C1B8FB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00602 Hi all, We've recieved some comments from the IESG, so I am filling the comments as issues. Description of issue: DNS SRV text needs to be updated Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: 18 Feb 2002 Reference: Document: Base Comment type: T Priority: 1 Section: 3 Rationale/Explanation of issue: DNS SRV-related text in Base needs to be updated to reflect latest SIP discovery draft. Requested change: Proposal Review the current draft, draft-ietf-sip-srv-04.txt and summarize the text. Proposed text forthcoming. John From owner-aaa-wg@merit.edu Mon Feb 18 23:12:51 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00614 for ; Mon, 18 Feb 2002 23:12:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2CF6891244; Mon, 18 Feb 2002 23:12:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE6E891246; Mon, 18 Feb 2002 23:12:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B60A591244 for ; Mon, 18 Feb 2002 23:12:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 965F85DDD3; Mon, 18 Feb 2002 23:12:12 -0500 (EST) 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 ADC2D5DDA6 for ; Mon, 18 Feb 2002 23:12:11 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1J4Bg302596 for ; Tue, 19 Feb 2002 06:11:42 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 19 Feb 2002 06:12:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 06:12:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 06:12:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22898@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue #250, Sub Issue, Unreferenced references Thread-Index: AcGpA41wLFg6gCD2RzepMXHAf66huQPWZ/DgABUwN9A= From: To: X-OriginalArrivalTime: 19 Feb 2002 04:12:10.0623 (UTC) FILETIME=[9A3018F0:01C1B8FB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA00614 Hi all, We've recieved some comments from the IESG, so I am filling the comments as issues. Description of issue: Usage of TLS and IPsec needs more detail Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: 18 Feb 2002 Reference: Document: Base Comment type: T Priority: 1 Section: 2.2 Rationale/Explanation of issue: Usage of TLS and IPsec. Aside from more detail on how to use TLS and IPsec, it was noted that the drafts do not say that IPsec is for Intra-domain use and TLS for inter-domain. In practice, IKE isn't very interoperable when used with certs, and can't support the required cert policies very well. TLS has this nailed. Should we say that IPsec is primarily for use with pre-shared keys and only intra-domain, and TLS is for cert usage and inter-domain? Should we adjust the language (TLS as MUST on client, too?) Issue to be filed and raised on the mailing list. Requested change: Proposal Add the following text: Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. Diameter servers MUST support TLS and IPSec. Operating the Diameter protocol without any security mechanism is not recommended. It is suggested that IPsec is primarily for use with pre-shared keys and to protect intra-domain traffic. TLS is for certificate usage and to project inter-domain traffic. John From owner-aaa-wg@merit.edu Tue Feb 19 01:06:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02777 for ; Tue, 19 Feb 2002 01:06:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4EB5991248; Tue, 19 Feb 2002 01:06:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C7B29124A; Tue, 19 Feb 2002 01:06:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AB4C91248 for ; Tue, 19 Feb 2002 01:06:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 066FC5DDD6; Tue, 19 Feb 2002 01:06:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 4B1145DD92 for ; Tue, 19 Feb 2002 01:06:28 -0500 (EST) Received: (qmail 13075 invoked by uid 507); 19 Feb 2002 06:06:27 -0000 Date: Tue, 19 Feb 2002 00:06:25 -0600 From: David Frascone To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Message-ID: <20020219060625.GO5545@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22898@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFA22898@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk I know that this is obviously what the IESG wants, but I don't think it's a very good idea. The beauty of RADIUS was that it was light weight. Forcing all Diameter clients to support IPSEC just isn't going to happen. Low end devices probably won't even have the CPU to implement it. I think adding this paragraph is going to keep all embedded systems from implementing Diameter. They'll just stick with RADIUS, and force all Diameter servers to implement the RADIUS gateways. IMHO, this is a VERY VERY bad "recommendation" -Dave On Tuesday, 19 Feb 2002, john.loughney@nokia.com wrote: > Hi all, > > We've recieved some comments from the IESG, so I am filling the comments > as issues. > > Description of issue: Usage of TLS and IPsec needs more detail > Submitter name: John Loughney > Submitter email address: john.loughney@nokia.com > Date first submitted: 18 Feb 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: 2.2 > Rationale/Explanation of issue: > > Usage of TLS and IPsec. Aside from more detail on how to use TLS and > IPsec, it was noted that the drafts do not say that IPsec is for > Intra-domain use and TLS for inter-domain. In practice, IKE isn't very > interoperable when used with certs, and can't support the required cert > policies very well. TLS has this nailed. Should we say > that IPsec is primarily for use with pre-shared keys and only > intra-domain, and TLS is for cert usage and inter-domain? Should we > adjust the language (TLS as MUST on client, too?) Issue to be filed and > raised on the mailing list. > > Requested change: > Proposal > > Add the following text: > > Diameter clients, such as Network Access Servers (NASes) and Mobility > Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. > Diameter servers MUST support TLS and IPSec. Operating the Diameter > protocol without any security mechanism is not recommended. > It is suggested that IPsec is primarily for use with pre-shared keys > and to protect intra-domain traffic. TLS is for certificate usage and > to project inter-domain traffic. > > John > From owner-aaa-wg@merit.edu Tue Feb 19 01:44:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03222 for ; Tue, 19 Feb 2002 01:44:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6D00191217; Tue, 19 Feb 2002 01:44:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EF7C9124A; Tue, 19 Feb 2002 01:44:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46F9791217 for ; Tue, 19 Feb 2002 01:44:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1FF285DDD7; Tue, 19 Feb 2002 01:44:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A8A205DDD6 for ; Tue, 19 Feb 2002 01:44:33 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1J65KL14947; Mon, 18 Feb 2002 22:05:20 -0800 Date: Mon, 18 Feb 2002 22:05:20 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: <20020219060625.GO5545@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The beauty of RADIUS was that it was light weight. Forcing all Diameter > clients to support IPSEC just isn't going to happen. Low end devices > probably won't even have the CPU to implement it. What is your proposal for Diameter security, then? TLS? CMS-Sec? Nothing? From owner-aaa-wg@merit.edu Tue Feb 19 01:45:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03239 for ; Tue, 19 Feb 2002 01:45:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0AEE79124A; Tue, 19 Feb 2002 01:44:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4C459124D; Tue, 19 Feb 2002 01:44:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D07279124A for ; Tue, 19 Feb 2002 01:44:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id B22375DDD6; Tue, 19 Feb 2002 01:44:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CB3B85DD92 for ; Tue, 19 Feb 2002 01:44:38 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1J6ikZ13680 for ; Tue, 19 Feb 2002 08:44:46 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 08:44:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 08:44:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 08:43:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Usage of TLS and IPsec Thread-Index: AcG5C5OHsfvKXGhqSb6h9Kar+HDvwwABNpfg From: To: Cc: X-OriginalArrivalTime: 19 Feb 2002 06:44:37.0522 (UTC) FILETIME=[E62A1F20:01C1B910] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA03239 Hi David, > I know that this is obviously what the IESG wants, but I don't think > it's a very good idea. > > The beauty of RADIUS was that it was light weight. Forcing > all Diameter clients to support IPSEC just isn't going to happen. Low > end devices probably won't even have the CPU to implement it. > > I think adding this paragraph is going to keep all embedded > systems from implementing Diameter. They'll just stick with RADIUS, > and force all Diameter servers to implement the RADIUS gateways. > > IMHO, this is a VERY VERY bad "recommendation" In version 8 of the base spec, the Section 2.2 reads: Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter servers MUST support TLS and IPSec. Operating the Diameter protocol without any security mechanism is not recommended. My text is adding nothing to this. My text has increased the usage of TLS from a MAY to a SHOULD. Are you suggesting that it could be the otherway around? Such as IPsec is a SHOULD and TLS is a MUST? thanks, John From owner-aaa-wg@merit.edu Tue Feb 19 01:54:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03368 for ; Tue, 19 Feb 2002 01:54:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06ED49124B; Tue, 19 Feb 2002 01:54:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C4C709124C; Tue, 19 Feb 2002 01:54:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B697B9124B for ; Tue, 19 Feb 2002 01:54:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 961A45DDD6; Tue, 19 Feb 2002 01:54:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id B6B645DD92 for ; Tue, 19 Feb 2002 01:54:20 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219065419.RLZE24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 08:54:19 +0200 Message-ID: <01ca01c1b912$4620f740$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22898@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 08:54:27 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 1) I'm not sure I agree with IESG on their understanding of cert policies etc. I know products that implement the cert processing of IKE and TLS using same code, for instance. Also, are they sure they have not confused the ease of server-side cert usage in TLS with the ease of certs in TLS in general? I've heard the same IESG story elsewhere on inter and intra but I find it hard to see why I can't install Verisign as my IPsec root, or Ericsson CA as my web TLS root. 2) Regardless of the above... what John is proposing not not unreasonable. The two things that do worry me are the only-recommendation on no security, and the MAY upgrade to SHOULD... but on the other hand it still isn't a MUST so the implementors still have a way out. Let me propose alternative text: Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. Diameter servers MUST support TLS and IPSec. The Diameter protocol MUST NOT be operated without any security mechanism. Jari From owner-aaa-wg@merit.edu Tue Feb 19 02:28:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11574 for ; Tue, 19 Feb 2002 02:28:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A2AE9124C; Tue, 19 Feb 2002 02:27:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E1729124D; Tue, 19 Feb 2002 02:27:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 51E2A9124C for ; Tue, 19 Feb 2002 02:27:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DAC65DDC8; Tue, 19 Feb 2002 02:27:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 7F53C5DD8E for ; Tue, 19 Feb 2002 02:27:53 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219072752.RTYI24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 09:27:52 +0200 Message-ID: <022e01c1b916$f62dcba0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22898@esebe004.NOE.Nokia.com> <01ca01c1b912$4620f740$8a1b6e0a@arenanet.fi> Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 09:28:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit One more thing. Thinking about this some more, while I do not necessarily agree with the IESG suggestion on intra and inter, this happens to coincide with what I think has been the intent (if not the letter) of the current spec. That is, you run IPsec, perhaps shared-secret keyed (if not even manually but here I think Bernard and I had a disagreement) on the edges, and then servers mainly communicate with each other using TLS. So could state something like this at the end of my suggested note below: It is suggested that IPsec can be used primarily at the edges and in intra-domain traffic, such as using pre-shared keys between a NAS a local AAA proxy. This also eases the requirements on the NAS to support certificates. It is also suggested that inter-domain traffic would primarily use TLS. Jari ----- Original Message ----- From: "Jari Arkko" To: ; Sent: 19. helmikuuta 2002 8:54 Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec > > 1) I'm not sure I agree with IESG on their understanding of cert > policies etc. I know products that implement the cert processing > of IKE and TLS using same code, for instance. Also, are they > sure they have not confused the ease of server-side cert usage > in TLS with the ease of certs in TLS in general? I've heard the > same IESG story elsewhere on inter and intra but I find it hard > to see why I can't install Verisign as my IPsec root, or Ericsson CA > as my web TLS root. > > 2) Regardless of the above... what John is proposing not not > unreasonable. The two things that do worry me are the > only-recommendation on no security, and the MAY upgrade > to SHOULD... but on the other hand it still isn't a MUST so > the implementors still have a way out. Let me propose > alternative text: > > Diameter clients, such as Network Access Servers (NASes) and Mobility > Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. > Diameter servers MUST support TLS and IPSec. The Diameter > protocol MUST NOT be operated without any security mechanism. > > Jari > > > From owner-aaa-wg@merit.edu Tue Feb 19 02:29:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11601 for ; Tue, 19 Feb 2002 02:29:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 569309124D; Tue, 19 Feb 2002 02:29:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 245899124E; Tue, 19 Feb 2002 02:29:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 182E89124D for ; Tue, 19 Feb 2002 02:29:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id E89175DDC8; Tue, 19 Feb 2002 02:29:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 38B3E5DD8E for ; Tue, 19 Feb 2002 02:29:21 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1J7TPZ08516 for ; Tue, 19 Feb 2002 09:29:25 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 09:29:16 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 09:29:16 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 09:29:16 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64906@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Usage of TLS and IPsec Thread-Index: AcG5FvHNxWLg12CRSxGDdl4uPY2EgAAABNvg From: To: , X-OriginalArrivalTime: 19 Feb 2002 07:29:16.0320 (UTC) FILETIME=[22DA4200:01C1B917] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA11601 Hi Jari, > One more thing. Thinking about this some more, while I > do not necessarily agree with the IESG suggestion on > intra and inter, this happens to coincide with what I think > has been the intent (if not the letter) of the current spec. > That is, you run IPsec, perhaps shared-secret keyed > (if not even manually but here I think Bernard and I had > a disagreement) on the edges, and then servers mainly > communicate with each other using TLS. So could > state something like this at the end of my suggested > note below: > > It is suggested that IPsec can be used primarily at the > edges and in intra-domain traffic, such as using pre-shared > keys between a NAS a local AAA proxy. This also eases > the requirements on the NAS to support certificates. It is > also suggested that inter-domain traffic would primarily use > TLS. This is what I was intending to suggest as text - but you put it much more elequently than I. I agree with your text. John From owner-aaa-wg@merit.edu Tue Feb 19 02:36:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11789 for ; Tue, 19 Feb 2002 02:36:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5BF229124E; Tue, 19 Feb 2002 02:36:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 27AED9124F; Tue, 19 Feb 2002 02:36:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4013A9124E for ; Tue, 19 Feb 2002 02:36:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2058E5DD90; Tue, 19 Feb 2002 02:36:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9EE2F5DD8E for ; Tue, 19 Feb 2002 02:36:16 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1J6v4g17729; Mon, 18 Feb 2002 22:57:04 -0800 Date: Mon, 18 Feb 2002 22:57:04 -0800 (PST) From: Bernard Aboba To: Jari Arkko Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: <01ca01c1b912$4620f740$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > to see why I can't install Verisign as my IPsec root, or Ericsson CA > as my web TLS root. Since TLS runs over TCP, cert chains (or even long certs) are not an issue. With IPsec, the result is IKE fragmentation, and since NATs/filtering routers typically drop fragments, connectivity can often not be established. We are seeing this problem arise more and more in real situations. That's the main "inter-domain" issue that I see with IPsec. "Diameter Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. Diameter servers MUST support TLS and IPSec. The Diameter protocol MUST NOT be operated without any security mechanism." This seems fine to me -- but out of curiousity, what are implementations actually using? From owner-aaa-wg@merit.edu Tue Feb 19 02:40:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11860 for ; Tue, 19 Feb 2002 02:40:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 265059124F; Tue, 19 Feb 2002 02:40:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E01B791250; Tue, 19 Feb 2002 02:40:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0257A9124F for ; Tue, 19 Feb 2002 02:40:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2B185DD90; Tue, 19 Feb 2002 02:40:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 60D585DD8E for ; Tue, 19 Feb 2002 02:40:22 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1J71AG18086; Mon, 18 Feb 2002 23:01:10 -0800 Date: Mon, 18 Feb 2002 23:01:09 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64906@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > It is suggested that IPsec can be used primarily at the > edges and in intra-domain traffic, such as using pre-shared > keys between a NAS a local AAA proxy. This also eases > the requirements on the NAS to support certificates. It is > also suggested that inter-domain traffic would primarily use > TLS. Out of curiosity - it is AAA servers that will be involved in inter-domain traffic not NASes, correct? So is there anything wrong with the original text (requiring IPsec on NASes)? From owner-aaa-wg@merit.edu Tue Feb 19 03:04:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12208 for ; Tue, 19 Feb 2002 03:04:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5112191251; Tue, 19 Feb 2002 03:04:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A296A91250; Tue, 19 Feb 2002 03:04:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 165FD91250 for ; Tue, 19 Feb 2002 03:03:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFCEC5DD8E; Tue, 19 Feb 2002 03:03:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id A55205DD8D for ; Tue, 19 Feb 2002 03:03:55 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219080354.SDCX24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 10:03:54 +0200 Message-ID: <029d01c1b91b$fea89080$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Bernard Aboba" , Cc: References: Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 10:04:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Out of curiosity - it is AAA servers that will be involved in inter-domain > traffic not NASes, correct? So is there anything wrong with the original > text (requiring IPsec on NASes)? Right. In fact, to follow the IESG inter-intra recommendation, the original NAS MAY was quite OK, wasn't it? Perhaps we should just have clarified the where these things are being used network wise. Jari From owner-aaa-wg@merit.edu Tue Feb 19 06:33:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14368 for ; Tue, 19 Feb 2002 06:33:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EB7F291250; Tue, 19 Feb 2002 06:32:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AF2C791252; Tue, 19 Feb 2002 06:32:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88C9191250 for ; Tue, 19 Feb 2002 06:32:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5685C5DDA2; Tue, 19 Feb 2002 06:32:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from minotaur.nge.isi.edu (minotaur.nge.isi.edu [65.114.169.202]) by segue.merit.edu (Postfix) with ESMTP id E7A4A5DD8D for ; Tue, 19 Feb 2002 06:32:33 -0500 (EST) Received: from minotaur (mankin@localhost) by minotaur.nge.isi.edu (8.11.6/8.11.6) with ESMTP id g1JBWVC25825; Tue, 19 Feb 2002 06:32:31 -0500 Message-Id: <200202191132.g1JBWVC25825@minotaur.nge.isi.edu> To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Reply-To: mankin@isi.edu Subject: Re: [AAA-WG]: [issue] DNS SRV text needs to be updated. In-reply-to: Your message of Tue, 19 Feb 2002 06:12:11 +0200. <0C1353ABB1DEB74DB067ADFF749C4EEFA22899@esebe004.NOE.Nokia.com> Mime-Version: 1.0 (generated by tm-edit 1.7) Content-Type: text/plain; charset=US-ASCII Date: Tue, 19 Feb 2002 06:32:31 -0500 From: Allison Mankin Sender: owner-aaa-wg@merit.edu Precedence: bulk John, The final draft before of sip-srv will be 05 and it has major changes from 04. It will appear today. From owner-aaa-wg@merit.edu Tue Feb 19 06:39:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14490 for ; Tue, 19 Feb 2002 06:39:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 30D2191252; Tue, 19 Feb 2002 06:39:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECA5191253; Tue, 19 Feb 2002 06:39:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D23E591252 for ; Tue, 19 Feb 2002 06:39:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADB895DDB0; Tue, 19 Feb 2002 06:39:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 72F075DD8D for ; Tue, 19 Feb 2002 06:39:24 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1JBdVZ20548 for ; Tue, 19 Feb 2002 13:39:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 13:39:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 13:39:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] DNS SRV text needs to be updated. Date: Tue, 19 Feb 2002 13:39:03 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6492D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] DNS SRV text needs to be updated. Thread-Index: AcG5OR+2EcBkY2aHT0GVRYC8/tynOgAANcIA From: To: Cc: X-OriginalArrivalTime: 19 Feb 2002 11:39:23.0379 (UTC) FILETIME=[13C1BC30:01C1B93A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA14490 Hi Allison, > The final draft before of sip-srv will be 05 and it > has major changes from 04. It will appear today. OK, thanks for the information. I guess I will have some more reading to do! John From owner-aaa-wg@merit.edu Tue Feb 19 07:18:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15764 for ; Tue, 19 Feb 2002 07:18:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B57B891253; Tue, 19 Feb 2002 07:18:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8B6F191254; Tue, 19 Feb 2002 07:18:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B65291253 for ; Tue, 19 Feb 2002 07:18:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A6CF5DDAA; Tue, 19 Feb 2002 07:18:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id F23BF5DD8D for ; Tue, 19 Feb 2002 07:18:39 -0500 (EST) Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios To: aaa-wg@merit.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Tue, 19 Feb 2002 07:41:07 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/19/2002 01:18:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue : Possible modification to the Diameter Cost Control Application protocol Submitter name: Paco Marin Submitter email address: fmaring@airtel.es Date first submitted: 02-18-2002 Reference: Document: draft-hakala-diameter-credit-control-01.txt Comment type: Technical Hi all, I've been taking look to the last version of the draft 'Diameter Credit Control Application' (draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part. Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios being covered with the described protocol, however I did'nt find the way to use this protocol to cover two possible scenarios. The referred scenarios are the following: 1.- Check of balance. Sometimes is necessary to check if there is enough balance to grant a service to a subscriber. Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there are three parts: the subscriber, the network operator and a third party which is the service provider. The third party will charge the sent melody (or logo) to the network operator just when the network operator receives it, so it could be interesting to acknowledge the Short Message delivery from the third party only when the subscriber has enough credit. This way the operator avoids to pay for a message that will never be delivered because the final user (the subscriber) has no credit enough. I've been thinking about the possibility of using 'session based credit control'. However is hardly ineficient, the SM must be acknowledged immediately and the short message could wait several days to be delivered to the final user (the user could be out of coverage), it implies to keep the session opened until the SM is finally delivered. 2.- Increment of Credit In some scenarios could be useful to add to the protocol the posibility to increase the balance instead of decrementing it. As an example, could be a way to motivate the user access to advertisement information in the internet or to receive adversiting Short Messages from a third party. In these scenarios could be interesting to be able to increment the credit directly from the client, as an example increase money on the user account or allow 1 free short message every 5 advertisement Short Message received. I think there is no way to make it with the current version of the draft (please, please, please correct me if I am wrong or confused). The solution to these two scenarios should not be fundamental for the overall working of the Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the legacy architectures of the current network operators. In my humble opinion a possible solution for both scenarios should be to include a new AVP. PROPOSAL OF SOLUTION A new AVP to indicate an operation on the balance is going to be accomplished could be added to the proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out is a decrement, check of balance or an increment. If this new AVP is not included in the request, the server should consider that the value of this one is '0', it will mean the behaviour of the protocol will be the one described up to now. The new AVP could be: 'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be: '0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted. This units will be decremented in that moment from the user account. '1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units allowed to be carried out. This units will NOT be decremented from the user account. '2': Increment, the request and answer work in a similar way as described for the value '0'. The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP contains the service units incremented. This units will be incremented in that moment in the user account. The accounted AVP table should be modified as follows: +----------+ | Command | | code | +----+-----+ Attribute Name |ACR | ACA | ------------------------------+----+-----+ Balance-Management-Indicator |0-1 | 0 | ------------------------------+----+-----+ Maybe I'm confused..... correct me in that case. Thanks a lot. Paco. From owner-aaa-wg@merit.edu Tue Feb 19 08:14:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17164 for ; Tue, 19 Feb 2002 08:14:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D2D2791256; Tue, 19 Feb 2002 08:14:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A4A7891265; Tue, 19 Feb 2002 08:14:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9266D91256 for ; Tue, 19 Feb 2002 08:13:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 788885DDB0; Tue, 19 Feb 2002 08:13:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B5E685DD8D for ; Tue, 19 Feb 2002 08:13:58 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1JDE5Z26720 for ; Tue, 19 Feb 2002 15:14:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 15:13:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 15:13:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: ISSUE 250: ready for closure? Date: Tue, 19 Feb 2002 15:13:57 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCD3@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios Thread-Index: AcG5QyL/n039HHBKRnWmXff+i/Jo7gAASoQA From: To: , X-OriginalArrivalTime: 19 Feb 2002 13:13:58.0000 (UTC) FILETIME=[4A182F00:01C1B947] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17164 Hi all, I've reviewed the previous threads on this & I feel we are ready to close on this. Below is what I have. Note I have moved to text reference tags - it makes things somewhat easier. Oddly enough, there were no direct references for UDP. In section 4.4 Derived AVP Data Formats, udp is listed under transport-protocol, for the URI for aaa. How should we handle the UDP reference? John 14.1 Normative [AAATRANS] B. Aboba, J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", draft-ietf-aaa- transport-04.txt, IETF Work in Progress, June 2001. [ASSIGNNO] Reynolds, Postel, "Assigned Numbers", RFC 1700, October 1994. [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Secu- rity application", draft-ietf-aaa-diameter-cms-sec- 03.txt, IETF work in progress, November 2001. [DIFFSERV] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," RFC 2474, December 1998. [DIFFSERVAF] J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, "Assured Forwarding PHB Group," RFC 2597, June 1999. [DIFFSERVEF] V. Jacobson, K. Nichols, K. Poduri, "An Expedited For- warding PHB", RFC 2598, June 1999. [DNSSRV] A. Gulbrandsen, P. Vixie, L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [EAP] L. J. Blunk, J. R. Vollbrecht, "PPP Extensible Authen- tication Protocol (EAP)." RFC 2284, March 1998. [FLOATPOINT] Institute of Electrical and Electronics Engineers, "IEEE Standard for Binary Floating-Point Arithmetic", ANSI/IEEE Standard 754-1985, August 1985. [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998 [IANAWEB] IANA, "Number assignment", http://www.iana.org [IKE] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [IPComp] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP Pay- load Compression Protocol (IPComp)", RFC 2393, December 1998. [IPV4] ISI, "Internet Protocol", RFC 791, September 1981. [IPV6] Hinden, Deering, "IP Version 6 Addressing Architec- ture", RFC 2373, July 1998. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [NAI] Aboba, Beadles "The Network Access Identifier." RFC 2486. January 1999. [RADTYPE] IANA, "RADIUS Types", http://www.isi.edu/in- notes/iana/assignments/radius-types [SCTP] R. Stewart et al., "Stream Control Transmission Proto- col". RFC 2960. October 2000. [SLP] E. Guttman, C. Perkins, J. Veizades, M. Day. "Service Location Protocol, Version 2", RFC 2165, June 1999. [SECARCH] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [SNTP] Mills, "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI, RFC 2030, October 1996. [TCP] Postel, J. "Transmission Control Protocol", RFC 793, January 1981. [TEMPLATE] E. Guttman, C. Perkins, J. Kempf, "Service Templates and Service: Schemes", RFC 2609, June 1999. [TLS] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [URI] T. Berners-Lee, R. Fielding, U.C. Irvine, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax". RFC 2396, August 1998. [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 14.2 Non-Normative [ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specif- ications: ABNF", RFC 2234, November 1997. [ACCMGMT] B. Aboba, J. Arkko, D. Harrington. "Introduction to Accounting Management", RFC 2975, October 2000. [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [DIAMMIP] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft-ietf-aaa-diameter-mobileip-08.txt, IETF work in progress, November 2001. [DNSSEC] D. Eastlake, "Domain Name System Security Extensions", RFC 2535, March 1999. [DNSSECOP] D. Eastlake, "DNS Security Operational Considerations", RFC 2541, March 1999. [DNSSIG] D. Eastlake, "DNS Request and Transaction Signatures ( SIG(0)s )", RFC 2931, September 2000. [MIPV4] C. Perkins, Editor. IP Mobility Support. RFC 2002, October 1996. [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica- tion, Authorization, and Accounting Requirements". RFC 2977. October 2000. [NASREQ] P. Calhoun, W. Bulley, A. Rubens, J. Haag, "Diameter NASREQ Application", draft-ietf-aaa-diameter-nasreq- 08.txt, IETF work in progress, November 2001. [NASCRIT] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", RFC 3169, September 2001. [PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, STD 51, July 1994. [PROXYCHAIN] B. Aboba, J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. [RADIUS] C. Rigney, A. Rubens, W. Simpson, S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [ROAMCRIT] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro- tocols", RFC 2477, January 1999. From owner-aaa-wg@merit.edu Tue Feb 19 08:28:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17621 for ; Tue, 19 Feb 2002 08:28:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD1129121B; Tue, 19 Feb 2002 08:28:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B33D491228; Tue, 19 Feb 2002 08:28:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CA419121B for ; Tue, 19 Feb 2002 08:28:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C8FD5DDB0; Tue, 19 Feb 2002 08:28:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 898CA5DDA2 for ; Tue, 19 Feb 2002 08:28:13 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1JDSKZ07602 for ; Tue, 19 Feb 2002 15:28:20 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Feb 2002 15:28:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Feb 2002 15:28:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 15:28:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6493C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Usage of TLS and IPsec Thread-Index: AcG5IOXM4MPyLOiKThGKwm+iZk/lxwAKB8iA From: To: , X-OriginalArrivalTime: 19 Feb 2002 13:28:12.0266 (UTC) FILETIME=[4746D4A0:01C1B949] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA17621 Jari, Then, if the text for 2.2 is the following: 2.2 Securing Diameter Messages Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and SHOULD support TLS [TLS]. Diameter servers MUST support TLS and IPSec. Operating the Diameter protocol without any security mechanism is not recommended. It is suggested that IPsec can be used primarily at the edges and in intra-domain traffic, such as using pre-shared keys between a NAS a local AAA proxy. This also eases the requirements on the NAS to support certificates. It is also suggested that inter-domain traffic would primarily use TLS. Is it OK with everyone? John From owner-aaa-wg@merit.edu Tue Feb 19 08:52:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18284 for ; Tue, 19 Feb 2002 08:52:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C999791265; Tue, 19 Feb 2002 08:52:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F85C91266; Tue, 19 Feb 2002 08:52:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9763D91265 for ; Tue, 19 Feb 2002 08:52:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 761845DDD5; Tue, 19 Feb 2002 08:52:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id D1BB25DDA2 for ; Tue, 19 Feb 2002 08:52:26 -0500 (EST) Received: (qmail 16628 invoked by uid 507); 19 Feb 2002 13:52:26 -0000 Date: Tue, 19 Feb 2002 07:52:24 -0600 From: David Frascone To: Bernard Aboba Cc: David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Message-ID: <20020219135224.GP5545@newman.frascone.com> Mail-Followup-To: Bernard Aboba , David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu References: <20020219060625.GO5545@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk SHOULDS, across the board. Security is something that's great to have, but I think having MUSTs will kill the protocol for small devices. On Monday, 18 Feb 2002, Bernard Aboba wrote: > > The beauty of RADIUS was that it was light weight. Forcing all Diameter > > clients to support IPSEC just isn't going to happen. Low end devices > > probably won't even have the CPU to implement it. > > What is your proposal for Diameter security, > then? TLS? CMS-Sec? Nothing? > > From owner-aaa-wg@merit.edu Tue Feb 19 09:17:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19790 for ; Tue, 19 Feb 2002 09:17:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B3EA91228; Tue, 19 Feb 2002 09:16:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 334B491212; Tue, 19 Feb 2002 09:16:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BCA891238 for ; Tue, 19 Feb 2002 09:16:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E5FE5DDD6; Tue, 19 Feb 2002 09:16:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id 3904C5DDD5 for ; Tue, 19 Feb 2002 09:16:51 -0500 (EST) Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios To: aaa-wg@merit.edu X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Tue, 19 Feb 2002 12:44:48 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/19/2002 03:16:51 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry, I think that was a problem with the delivery of my previous mail. Issue : Possible modification to the Diameter Cost Control Application protocol Submitter name: Paco Marin Submitter email address: fmaring@airtel.es Date first submitted: 02-18-2002 Reference: Document: draft-hakala-diameter-credit-control-01.txt Comment type: Technical Hi all, I've been taking look to the last version of the draft 'Diameter Credit Control Application' (draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part. Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios being covered with the described protocol, however I did'nt find the way to use this protocol to cover two possible scenarios. The referred scenarios are the following: 1.- Check of balance. Sometimes is necessary to check if there is enough balance to grant a service to a subscriber. Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there are three parts: the subscriber, the network operator and a third party which is the service provider. The third party will charge the sent melody (or logo) to the network operator just when the network operator receives it, so it could be interesting to acknowledge the Short Message delivery from the third party only when the subscriber has enough credit. This way the operator avoids to pay for a message that will never be delivered because the final user (the subscriber) has no credit enough. I've been thinking about the possibility of using 'session based credit control'. However is hardly ineficient, the SM must be acknowledged immediately and the short message could wait several days to be delivered to the final user (the user could be out of coverage), it implies to keep the session opened until the SM is finally delivered. 2.- Increment of Credit In some scenarios could be useful to add to the protocol the posibility to increase the balance instead of decrementing it. As an example, could be a way to motivate the user access to advertisement information in the internet or to receive adversiting Short Messages from a third party. In these scenarios could be interesting to be able to increment the credit directly from the client, as an example increase money on the user account or allow 1 free short message every 5 advertisement Short Message received. I think there is no way to make it with the current version of the draft (please, please, please correct me if I am wrong or confused). The solution to these two scenarios should not be fundamental for the overall working of the Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the legacy architectures of the current network operators. In my humble opinion a possible solution for both scenarios should be to include a new AVP. PROPOSAL OF SOLUTION A new AVP to indicate an operation on the balance is going to be accomplished could be added to the proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out is a decrement, check of balance or an increment. If this new AVP is not included in the request, the server should consider that the value of this one is '0', it will mean the behaviour of the protocol will be the one described up to now. The new AVP could be: 'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be: '0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted. This units will be decremented in that moment from the user account. '1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units allowed to be carried out. This units will NOT be decremented from the user account. '2': Increment, the request and answer work in a similar way as described for the value '0'. The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP contains the service units incremented. This units will be incremented in that moment in the user account. The accounted AVP table should be modified as follows: +----------+ | Command | | code | +----+-----+ Attribute Name |ACR | ACA | ------------------------------+----+-----+ Balance-Management-Indicator |0-1 | 0 | ------------------------------+----+-----+ Maybe I'm confused..... correct me in that case. Thanks a lot. Paco. From owner-aaa-wg@merit.edu Tue Feb 19 09:20:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20185 for ; Tue, 19 Feb 2002 09:20:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3EA4B91212; Tue, 19 Feb 2002 09:20:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10A2D91238; Tue, 19 Feb 2002 09:20:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1486091212 for ; Tue, 19 Feb 2002 09:20:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id E5B0F5DDD6; Tue, 19 Feb 2002 09:20:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 7103C5DDD5 for ; Tue, 19 Feb 2002 09:20:31 -0500 (EST) Received: (qmail 16996 invoked by uid 507); 19 Feb 2002 14:20:31 -0000 Date: Tue, 19 Feb 2002 08:20:29 -0600 From: David Frascone To: john.loughney@nokia.com Cc: dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Message-ID: <20020219142029.GQ5545@newman.frascone.com> Mail-Followup-To: john.loughney@nokia.com, dave@frascone.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk Well, I've spent this morning searching the archive for my previous post on this paragraph, but I guess I never made it. I do have a problem with the MUST in version 8 of the draft too. I think it is too much to ask embedded systems to implement IPSEC or TLS. For some reason, I even remember a response to my complaint, where someone said that small boxes would just use RADIUS. . . . guess I need more sleep :) I prefer a SHOULD instead of the MUSTS for NAS's and Mobility Agents. -Dave On Tuesday, 19 Feb 2002, john.loughney@nokia.com wrote: > Hi David, > > > I know that this is obviously what the IESG wants, but I don't think > > it's a very good idea. > > > > The beauty of RADIUS was that it was light weight. Forcing > > all Diameter clients to support IPSEC just isn't going to happen. Low > > end devices probably won't even have the CPU to implement it. > > > > I think adding this paragraph is going to keep all embedded > > systems from implementing Diameter. They'll just stick with RADIUS, > > and force all Diameter servers to implement the RADIUS gateways. > > > > IMHO, this is a VERY VERY bad "recommendation" > > In version 8 of the base spec, the Section 2.2 reads: > > Diameter clients, such as Network Access Servers (NASes) and Mobility > Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter > servers MUST support TLS and IPSec. Operating the Diameter protocol without > any security mechanism is not recommended. > > My text is adding nothing to this. My text has increased the usage of TLS > from a MAY to a SHOULD. Are you suggesting that it could be the otherway > around? Such as IPsec is a SHOULD and TLS is a MUST? > > thanks, > John > From owner-aaa-wg@merit.edu Tue Feb 19 09:37:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20988 for ; Tue, 19 Feb 2002 09:37:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3FCD091238; Tue, 19 Feb 2002 09:37:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 11E929123D; Tue, 19 Feb 2002 09:37:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CCF2891238 for ; Tue, 19 Feb 2002 09:37:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id A8DDE5DDD5; Tue, 19 Feb 2002 09:37:03 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 60BC05DDA2 for ; Tue, 19 Feb 2002 09:37:03 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1JEYZb01314; Tue, 19 Feb 2002 09:34:39 -0500 Message-ID: <3C72627B.14D26D27@interlinknetworks.com> Date: Tue, 19 Feb 2002 09:34:35 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec References: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> <20020219142029.GQ5545@newman.frascone.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA20988 Hi Dave, I'm concerned that allowing NASs and Mobility Agents to connect to Diameter servers without requiring any security makes the Diameter server very vulnerable to attack. A Diameter server without security is easier to attack than a RADIUS server that is at least protected by a shared secret. I think the NASs and Mobility Agents must provide at least some credentials before connecting to the Diameter server. Don David Frascone wrote: > Well, I've spent this morning searching the archive for my previous post > on this paragraph, but I guess I never made it. > > I do have a problem with the MUST in version 8 of the draft too. I think it > is too much to ask embedded systems to implement IPSEC or TLS. > > For some reason, I even remember a response to my complaint, where someone > said that small boxes would just use RADIUS. . . . guess I need more sleep :) > > I prefer a SHOULD instead of the MUSTS for NAS's and Mobility Agents. > > -Dave > > On Tuesday, 19 Feb 2002, john.loughney@nokia.com wrote: > > Hi David, > > > > > I know that this is obviously what the IESG wants, but I don't think > > > it's a very good idea. > > > > > > The beauty of RADIUS was that it was light weight. Forcing > > > all Diameter clients to support IPSEC just isn't going to happen. Low > > > end devices probably won't even have the CPU to implement it. > > > > > > I think adding this paragraph is going to keep all embedded > > > systems from implementing Diameter. They'll just stick with RADIUS, > > > and force all Diameter servers to implement the RADIUS gateways. > > > > > > IMHO, this is a VERY VERY bad "recommendation" > > > > In version 8 of the base spec, the Section 2.2 reads: > > > > Diameter clients, such as Network Access Servers (NASes) and Mobility > > Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter > > servers MUST support TLS and IPSec. Operating the Diameter protocol without > > any security mechanism is not recommended. > > > > My text is adding nothing to this. My text has increased the usage of TLS > > from a MAY to a SHOULD. Are you suggesting that it could be the otherway > > around? Such as IPsec is a SHOULD and TLS is a MUST? > > > > thanks, > > John > > From owner-aaa-wg@merit.edu Tue Feb 19 09:46:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21357 for ; Tue, 19 Feb 2002 09:46:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60EB89123D; Tue, 19 Feb 2002 09:45:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BCD59123F; Tue, 19 Feb 2002 09:45:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C98D89123D for ; Tue, 19 Feb 2002 09:45:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC41B5DDD9; Tue, 19 Feb 2002 09:45:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 11DFA5DDA2 for ; Tue, 19 Feb 2002 09:45:11 -0500 (EST) Received: (qmail 17405 invoked by uid 507); 19 Feb 2002 14:45:10 -0000 Date: Tue, 19 Feb 2002 08:45:08 -0600 From: David Frascone To: Don Zick Cc: David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Message-ID: <20020219144508.GR5545@newman.frascone.com> Mail-Followup-To: Don Zick , David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu References: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> <20020219142029.GQ5545@newman.frascone.com> <3C72627B.14D26D27@interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C72627B.14D26D27@interlinknetworks.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no X-Virus-Scanned: by AMaViS perl-11 Sender: owner-aaa-wg@merit.edu Precedence: bulk For the most part, I agree with you. In large setups, I agree 100%. But, what about the NAS that's directly connected to a Diameter server running NASREQ. In a small singal POP ISP, that's what you have. One server, one NAS. And, for most small ISPs, the NAS will be the cheapest one they can find. I just have a hard time believing that this econo-NAS will have the resources to implement IPSEC. I know we removed the CMS requirement from NAS's for this same reason. How much more lightweight is IPSEC than CMS? Why have a MUST for IPSEC, and a SHOULD for CMS (or is it a MAY? I'm too lazy to look)? If a NAS has the ability to do IPSEC, I'll bet it could do CMS too. But, I'm not really concerned with the NAS's that *can* do IPSEC. I'm worried about the ones that *can't*. And, with a MUST there, I'm concerned that small NAS vendors will just ignore Diameter completely (since they can't support IPSEC), and stick with RADIUS. Later, -Dave On Tuesday, 19 Feb 2002, Don Zick wrote: > Hi Dave, > I'm concerned that allowing NASs and Mobility Agents to connect to Diameter > servers without requiring any security makes the Diameter server very vulnerable > to attack. A Diameter server without security is easier to attack than a RADIUS > server that is at least protected by a shared secret. I think the NASs and > Mobility Agents must provide at least some credentials before connecting to the > Diameter server. > Don > > David Frascone wrote: > > > Well, I've spent this morning searching the archive for my previous post > > on this paragraph, but I guess I never made it. > > > > I do have a problem with the MUST in version 8 of the draft too. I think it > > is too much to ask embedded systems to implement IPSEC or TLS. > > > > For some reason, I even remember a response to my complaint, where someone > > said that small boxes would just use RADIUS. . . . guess I need more sleep :) > > > > I prefer a SHOULD instead of the MUSTS for NAS's and Mobility Agents. > > > > -Dave > > > > On Tuesday, 19 Feb 2002, john.loughney@nokia.com wrote: > > > Hi David, > > > > > > > I know that this is obviously what the IESG wants, but I don't think > > > > it's a very good idea. > > > > > > > > The beauty of RADIUS was that it was light weight. Forcing > > > > all Diameter clients to support IPSEC just isn't going to happen. Low > > > > end devices probably won't even have the CPU to implement it. > > > > > > > > I think adding this paragraph is going to keep all embedded > > > > systems from implementing Diameter. They'll just stick with RADIUS, > > > > and force all Diameter servers to implement the RADIUS gateways. > > > > > > > > IMHO, this is a VERY VERY bad "recommendation" > > > > > > In version 8 of the base spec, the Section 2.2 reads: > > > > > > Diameter clients, such as Network Access Servers (NASes) and Mobility > > > Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter > > > servers MUST support TLS and IPSec. Operating the Diameter protocol without > > > any security mechanism is not recommended. > > > > > > My text is adding nothing to this. My text has increased the usage of TLS > > > from a MAY to a SHOULD. Are you suggesting that it could be the otherway > > > around? Such as IPsec is a SHOULD and TLS is a MUST? > > > > > > thanks, > > > John > > > From owner-aaa-wg@merit.edu Tue Feb 19 09:47:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21436 for ; Tue, 19 Feb 2002 09:47:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 88DC29123F; Tue, 19 Feb 2002 09:47:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50CBE91264; Tue, 19 Feb 2002 09:47:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 25E639123F for ; Tue, 19 Feb 2002 09:47:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A6A95DDD9; Tue, 19 Feb 2002 09:47:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id CF5125DDA2 for ; Tue, 19 Feb 2002 09:47:08 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id PAA26559; Tue, 19 Feb 2002 15:44:25 +0100 Message-ID: <3C72733A.1070601@ipunplugged.com> Date: Tue, 19 Feb 2002 16:46:02 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Don Zick Cc: David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec References: <0C1353ABB1DEB74DB067ADFF749C4EEFC648FD@esebe004.NOE.Nokia.com> <20020219142029.GQ5545@newman.frascone.com> <3C72627B.14D26D27@interlinknetworks.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 Wouldn't that, assuming that insecure connections were allowed, be a policy decision that the contacted server would need to take whether to allow insecure connections or not based on the network topology? A mobility agent is a rather complicated beast and if you can put one of those together I think it's a reasonable assumption that it can be made to support TLS and/or IPsec. I don't know enough about NASes to have an informed opinion, but surely it is not entirely unreasonable to have a number of NASes talking to a local diameter server/proxy over dedicated lines? Of course more security gives more room for flexibility when building the networks, but then again we are not talking about banning the use of security but whether it is feasible to mandate it for every single device. j Don Zick wrote: >Hi Dave, >I'm concerned that allowing NASs and Mobility Agents to connect to Diameter >servers without requiring any security makes the Diameter server very vulnerable >to attack. A Diameter server without security is easier to attack than a RADIUS >server that is at least protected by a shared secret. I think the NASs and >Mobility Agents must provide at least some credentials before connecting to the >Diameter server. >Don > >David Frascone wrote: > >>Well, I've spent this morning searching the archive for my previous post >>on this paragraph, but I guess I never made it. >> >>I do have a problem with the MUST in version 8 of the draft too. I think it >>is too much to ask embedded systems to implement IPSEC or TLS. >> >>For some reason, I even remember a response to my complaint, where someone >>said that small boxes would just use RADIUS. . . . guess I need more sleep :) >> >>I prefer a SHOULD instead of the MUSTS for NAS's and Mobility Agents. >> >>-Dave >> >>On Tuesday, 19 Feb 2002, john.loughney@nokia.com wrote: >> >>>Hi David, >>> >>>>I know that this is obviously what the IESG wants, but I don't think >>>>it's a very good idea. >>>> >>>>The beauty of RADIUS was that it was light weight. Forcing >>>>all Diameter clients to support IPSEC just isn't going to happen. Low >>>>end devices probably won't even have the CPU to implement it. >>>> >>>>I think adding this paragraph is going to keep all embedded >>>>systems from implementing Diameter. They'll just stick with RADIUS, >>>>and force all Diameter servers to implement the RADIUS gateways. >>>> >>>>IMHO, this is a VERY VERY bad "recommendation" >>>> >>>In version 8 of the base spec, the Section 2.2 reads: >>> >>> Diameter clients, such as Network Access Servers (NASes) and Mobility >>> Agents MUST support IP Security [37], and MAY support TLS [38]. Diameter >>> servers MUST support TLS and IPSec. Operating the Diameter protocol without >>> any security mechanism is not recommended. >>> >>>My text is adding nothing to this. My text has increased the usage of TLS >>>from a MAY to a SHOULD. Are you suggesting that it could be the otherway >>>around? Such as IPsec is a SHOULD and TLS is a MUST? >>> >>>thanks, >>>John >>> > From owner-aaa-wg@merit.edu Tue Feb 19 10:02:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22360 for ; Tue, 19 Feb 2002 10:02:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C652091245; Tue, 19 Feb 2002 10:02:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 761A791266; Tue, 19 Feb 2002 10:02:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1A51F91245 for ; Tue, 19 Feb 2002 10:02:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id EF4F95DDAA; Tue, 19 Feb 2002 10:02:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 1CAC05DDA2 for ; Tue, 19 Feb 2002 10:02:46 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219150235.WDNS24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 17:02:35 +0200 Message-ID: <03d801c1b956$7df7c380$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , , References: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCD3@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: ISSUE 250: ready for closure? Date: Tue, 19 Feb 2002 17:02:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Oddly enough, there were no direct references for UDP. In section 4.4 Derived AVP > Data Formats, udp is listed under transport-protocol, for the URI for aaa. How should > we handle the UDP reference? We refer to SCTP and TCP in section 2.1 because they are Diameter transport protocols. I believe UDP is only talked about in 4.4 because it can appear in URIs due to Radius backwards compatibility, and because UDP/TCP/SCTP are relevant for filters. Just to be on the very safe side, why don't you put the correct references to UDP/TCP/SCTP in section 4.4 as well. UDP is RFC 768. This would be a .... normative reference I think because you have to be able to understand what the URIs mean. Or? Jari From owner-aaa-wg@merit.edu Tue Feb 19 10:05:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22538 for ; Tue, 19 Feb 2002 10:05:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B1B891266; Tue, 19 Feb 2002 10:05:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D91C391267; Tue, 19 Feb 2002 10:05:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2EBB91266 for ; Tue, 19 Feb 2002 10:05:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id B7DDA5DDAA; Tue, 19 Feb 2002 10:05:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.36]) by segue.merit.edu (Postfix) with ESMTP id 399F15DDA2 for ; Tue, 19 Feb 2002 10:05:33 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1JF5LhM017723 for ; Tue, 19 Feb 2002 16:05:21 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Feb 19 16:05:19 2002 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Feb 2002 16:05:19 +0100 Message-ID: <577066326047D41180AC00508B955DDA06C450E3@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: aaa-wg@merit.edu Cc: "'Pete McCann'" Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Tue, 19 Feb 2002 16:05:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk >* Is it technically OK to use a message in both directions > (client->server and server->client)? I think the answer is yes, > although most existing Diameter applications don't do this. > Are there any other considerations of which we should be aware? My main concern regarding this is : why do we need to do such thing? Why not implementing two different commands for each direction, as it has been always done so far? I think it more useful having more simple commands for each specific functionality, rather than merging every functionality in the same command, and, apart from that, making that command bi-directional.....I don't really see a reason for having bi-directional commands....(there is no shortage of command-codes). Could you please explain? BR, Carolina >jaakko.rajaniemi@nokia.com writes: > > Hi, > > > > > So we would have three commands: > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > (Registration-Termination-Request, RTR?). > > > - One (SSP->AAA) to update registration information and to > > > pull user data. > > > > Right, this was what I had in mind. The >SIP-Profile-Update-Type AVP could be changed in such a way >that at least the UPDATE_PROFILE value is removed and the name >of the AVP could be something else e.g. SIP-Server-Assignment-Type. > > > > What about the RETRIEVE_PROFILE value of the >SIP-Profile-Update-Type AVP? Should we keep it or remove it? >The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT >value is not clear. > > > > Best Regards, Jaakko > > > > > -----Original Message----- > > > From: ext Miguel-Angel Pallares-Lopez (ECE) > > > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > > > Sent: 15 February, 2002 12:37 > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > Hi, > > > > > > So we would have three commands: > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > (Registration-Termination-Request, RTR?). > > > - One (SSP->AAA) to update registration information and to > > > pull user data. > > > > > > It seems sensible to me. I agree that their semantic is > > > different and we are not going to run out of commands codes. > > > > > > Best regards, > > > Miguel > > > > > > > -----Original Message----- > > > > From: jaakko.rajaniemi@nokia.com >[mailto:jaakko.rajaniemi@nokia.com] > > > > Sent: Friday, February 15, 2002 10:56 AM > > > > To: carolina.canales-valenzuela@ece.ericsson.se; >aaa-wg@merit.edu > > > > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; >nhberry@lucent.com; > > > > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > > > > mikko.aittola@nokia.com; >Miguel-Angel.Pallares-Lopez@ece.ericsson.se > > > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > Hi, > > > > > > > > In addition, PUR/PUA command is also used in the > > > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > > > > registering the user, either from the AAAH or the client. > > > > From the logical point of view the profile updating and > > > > (-/re/de-) registration are different operations and > > > > therefore it would be quite natural to separate the profile > > > > updating from the registration. > > > > > > > > This could be done by specifying different command codes for > > > > the profile and the registration related operations. > > > > > > > > Best Regards, Jaakko > > > > > > > > > -----Original Message----- > > > > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > > > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > > > > Sent: 13 February, 2002 19:42 > > > > > To: 'aaa-wg@merit.edu' > > > > > Cc: Carolina Canales Valenzuela (ECE); > > > 'mccap@lucent.com'; Rajaniemi > > > > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > > > > 'nhberry@lucent.com'; > > > > > 'dlwarren@nortelnetworks.com'; > > > > 'peter.schmitt@icn.siemens.de'; Aittola > > > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > Hello, > > > > > taking in account the requirements draft > > > > > "draft-calhoun-sip-aaa-reqs-03" > > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > > > > requirement for the AAA infrastructure to distribute (*push > > > > > or pull*)subscriber/service/security profiles to the relevant > > > > > SIP servers. > > > > > > > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > > > > implemented as an only, bi-directional command, PUR (section > > > > > 3.5). This command might be issued either by the AAA or by > > > > > the SIP server, in order to update the user profile in the > > > > > corresponding node. > > > > > > > > > > However, I think it could be useful to split this command in > > > > > 2 uni-directional commands, one issued from the AAA and > > > > > another one issued by the SIP server. > > > > > > > > > > The fact that such a command can be issued from the same node > > > > > as a request and as a reply, adds a lot of complexity in the > > > > > implementation part. Why not using two different commands? I > > > > > think there is no shortage of command codes, right? ;-). > > > > > > > > > > BR, > > > > > Carolina > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] > > > > > >Sent: Tuesday, February 12, 2002 1:02 PM > > > > > >Cc: aaa-wg@merit.edu > > > > > >Subject: I-D >ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > > >Internet-Drafts directories. > > > > > > > > > > > > > > > > > > Title : Diameter Multimedia Application > > > > > > Author(s) : T. Johansson et al. > > > > > > Filename : >draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > Pages : 31 > > > > > > Date : 11-Feb-02 > > > > > > > > > > > >This document specifies a Diameter application that allows > > > > a Diameter > > > > > >server to authenticate, authorize, and collect accounting > > > > information > > > > > >for Session Initiation Protocol (SIP) services rendered > > > to a client > > > > > >node. This application, combined with the base Diameter > > > > protocol and > > > > > >appropriate SIP extensions, allows SIP User Agents (UAs) > > > to obtain > > > > > >services from SIP servers that are connected to a Diameter > > > > > >infrastructure. When combined with the Inter-Domain > > > capability of > > > > > >the base protocol, service may even be obtained from SIP > > > > servers that > > > > > >belong to foreign domains, as would be encountered by > > > > roaming mobile > > > > > >nodes. > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > >>http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > > > > r-mm-app-01.txt > > > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > > message to > > > > > ietf-announce-request with the word unsubscribe in the body > > > > > of the message. > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > > with the username > > > > > "anonymous" and a password of your e-mail address. After > > > logging in, > > > > > type "cd internet-drafts" and then > > > > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > http://www.ietf.org/shadow.html > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > Send a message to: > > > > > mailserv@ietf.org. > > > > > In the body type: > > > > > "FILE > > > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > MIME-encoded form by using the "mpack" utility. > To use this > > > > > feature, insert the command "ENCODING mime" >before the "FILE" > > > > > command. To decode the response(s), you will >need "munpack" or > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > mail readers > > > > > exhibit different behavior, especially when dealing with > > > > > "multipart" MIME messages (i.e. documents which >have been split > > > > > up into multiple messages), so check your local >documentation on > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant >mail reader > > > > > implementation to automatically retrieve the ASCII >version of the > > > > > Internet-Draft. > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Feb 19 10:06:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22621 for ; Tue, 19 Feb 2002 10:06:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2061F91267; Tue, 19 Feb 2002 10:06:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E680491268; Tue, 19 Feb 2002 10:06:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA30691267 for ; Tue, 19 Feb 2002 10:06:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFC025DDAE; Tue, 19 Feb 2002 10:06:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id CB4D35DDAA for ; Tue, 19 Feb 2002 10:06:15 -0500 (EST) Received: from jariws1 ([62.248.144.77]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020219150615.WEBC24910.fep01-app.kolumbus.fi@jariws1>; Tue, 19 Feb 2002 17:06:15 +0200 Message-ID: <03f401c1b957$00eb52c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Frascone" , "Bernard Aboba" Cc: "David Frascone" , , References: <20020219060625.GO5545@newman.frascone.com> <20020219135224.GP5545@newman.frascone.com> Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Tue, 19 Feb 2002 17:06:26 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > SHOULDS, across the board. Security is something that's great to have, but > I think having MUSTs will kill the protocol for small devices. > > On Monday, 18 Feb 2002, Bernard Aboba wrote: > > > The beauty of RADIUS was that it was light weight. Forcing all Diameter > > > clients to support IPSEC just isn't going to happen. Low end devices > > > probably won't even have the CPU to implement it. > > > > What is your proposal for Diameter security, > > then? TLS? CMS-Sec? Nothing? We need to have security. Even RADIUS had mandatory security. This time we are moving the mandatory security out of the protocol itself to another layer (ip or transport), because in many cases support on those layers already exists, and is far better than what e.g. RADIUS had. I don't think leaving security to a SHOULD across the board is acceptable. Jari From owner-aaa-wg@merit.edu Tue Feb 19 10:22:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23465 for ; Tue, 19 Feb 2002 10:22:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6E72791268; Tue, 19 Feb 2002 10:22:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4057891269; Tue, 19 Feb 2002 10:22:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4253A91268 for ; Tue, 19 Feb 2002 10:22:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 278EA5DDD9; Tue, 19 Feb 2002 10:22:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id B25C55DDA2 for ; Tue, 19 Feb 2002 10:22:40 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1JEglU11482; Tue, 19 Feb 2002 06:42:47 -0800 Date: Tue, 19 Feb 2002 06:42:47 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: fmaring@airtel.es, aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE 250: ready for closure? In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCD3@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I've reviewed the previous threads on this & I feel we are ready to close on this. > Below is what I have. Note I have moved to text reference tags - it makes things > somewhat easier. > > Oddly enough, there were no direct references for UDP. In section 4.4 Derived AVP > Data Formats, udp is listed under transport-protocol, for the URI for aaa. How should > we handle the UDP reference? > Can we remove this reference? Otherwise, I'd say make UDP non-normative. From owner-aaa-wg@merit.edu Tue Feb 19 10:38:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24241 for ; Tue, 19 Feb 2002 10:38:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 10DE69126A; Tue, 19 Feb 2002 10:37:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2CFB9126B; Tue, 19 Feb 2002 10:37:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E719A9126A for ; Tue, 19 Feb 2002 10:37:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA6635DDD9; Tue, 19 Feb 2002 10:37:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4CB2A5DDA2 for ; Tue, 19 Feb 2002 10:37:46 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1JEvAt12290; Tue, 19 Feb 2002 06:57:10 -0800 Date: Tue, 19 Feb 2002 06:57:10 -0800 (PST) From: Bernard Aboba To: David Frascone Cc: Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: <20020219144508.GR5545@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I know we removed the CMS requirement from NAS's for this same reason. How > much more lightweight is IPSEC than CMS? Not sure about the requirements for CMS, but the "lightweight" argument was raised in IPS WG, and so we went about looking at implementation code size. We were surprised that there are IKE implementations of 200 KB (pre-shared keys, minimal cert support). Since Diameter only requires IPsec ESP with a non-null transform (say, 3DES), the total code is sufficiently small that it is being implemented on NICs with non-volatile storage of under 2 MB for everything. See draft-ietf-ips-security-09.txt for details on sizes of IKE implementations. From owner-aaa-wg@merit.edu Tue Feb 19 10:38:44 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24267 for ; Tue, 19 Feb 2002 10:38:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 271479126B; Tue, 19 Feb 2002 10:37:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D83C09126C; Tue, 19 Feb 2002 10:37:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55BA29126B for ; Tue, 19 Feb 2002 10:37:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B7F35DDD9; Tue, 19 Feb 2002 10:37:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C708E5DDA2 for ; Tue, 19 Feb 2002 10:37:48 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1JEwUk12340; Tue, 19 Feb 2002 06:58:30 -0800 Date: Tue, 19 Feb 2002 06:58:29 -0800 (PST) From: Bernard Aboba To: Johan Johansson Cc: Don Zick , David Frascone , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: <3C72733A.1070601@ipunplugged.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Wouldn't that, assuming that insecure connections were allowed, be a > policy decision that the contacted server would need to take whether to > allow insecure connections or not based on the network topology? Well, we do need to be clear whether we are talking about mandatory to implement or mandatory to use. From owner-aaa-wg@merit.edu Tue Feb 19 10:58:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25108 for ; Tue, 19 Feb 2002 10:58:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 722D39126D; Tue, 19 Feb 2002 10:58:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 441949126E; Tue, 19 Feb 2002 10:58:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35D219126D for ; Tue, 19 Feb 2002 10:58:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0BC1D5DDA6; Tue, 19 Feb 2002 10:58:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id D4B655DDA2 for ; Tue, 19 Feb 2002 10:58:16 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 16dCeP-000LgF-00 for aaa-wg@merit.edu; Tue, 19 Feb 2002 07:57:53 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64906@esebe004.NOE.Nokia.com> Message-Id: Date: Tue, 19 Feb 2002 07:57:53 -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit why should a security-conscientious ietf not take a position in the vein of o inter-agent authentication of some form is mandatory o inter-agent traffic encryption of some form is mandatory o these must always be on? randy From owner-aaa-wg@merit.edu Tue Feb 19 11:07:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25529 for ; Tue, 19 Feb 2002 11:07:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCEBB9126E; Tue, 19 Feb 2002 11:07:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CC949126F; Tue, 19 Feb 2002 11:07:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9CFC19126E for ; Tue, 19 Feb 2002 11:07:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 755A65DDAD; Tue, 19 Feb 2002 11:07:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 0EDEB5DDA6 for ; Tue, 19 Feb 2002 11:07:23 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1JFSC214051; Tue, 19 Feb 2002 07:28:12 -0800 Date: Tue, 19 Feb 2002 07:28:12 -0800 (PST) From: Bernard Aboba To: Randy Bush Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > why should a security-conscientious ietf not take a position in the vein of > o inter-agent authentication of some form is mandatory > o inter-agent traffic encryption of some form is mandatory > o these must always be on? This makes sense to me. Making security mandatory to implement but not mandatory to use doesn't make sense in this case. After all, with RADIUS security was mandatory to use. From owner-aaa-wg@merit.edu Tue Feb 19 11:53:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27081 for ; Tue, 19 Feb 2002 11:53:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7E0669126F; Tue, 19 Feb 2002 11:52:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 43C3791270; Tue, 19 Feb 2002 11:52:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 254669126F for ; Tue, 19 Feb 2002 11:52:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 046685DDAD; Tue, 19 Feb 2002 11:52:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by segue.merit.edu (Postfix) with ESMTP id C5D105DDAA for ; Tue, 19 Feb 2002 11:52:46 -0500 (EST) Received: from marconi.ih.lucent.com (h135-1-120-108.lucent.com [135.1.120.108]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1JGqLn16520; Tue, 19 Feb 2002 11:52:21 -0500 (EST) Received: from nwsgpb.ih.lucent.com by marconi.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA00257; Tue, 19 Feb 2002 10:52:20 -0600 (CST) Received: by nwsgpb.ih.lucent.com (8.8.8+Sun/EMS-1.5 client sol2) id KAA20401; Tue, 19 Feb 2002 10:52:20 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15474.33476.303003.577374@nwsgpb.ih.lucent.com> Date: Tue, 19 Feb 2002 10:52:20 -0600 (CST) From: Pete McCann To: "Carolina Canales Valenzuela (ECE)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt In-Reply-To: <577066326047D41180AC00508B955DDA06C450E3@eestqnt104.es.eu.ericsson.se> References: <577066326047D41180AC00508B955DDA06C450E3@eestqnt104.es.eu.ericsson.se> X-Mailer: VM 6.75 under 20.4 "Emerald" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Carolina, I agree, we should split PUR into two messges. -Pete Carolina Canales Valenzuela (ECE) writes: > >* Is it technically OK to use a message in both directions > > (client->server and server->client)? I think the answer is yes, > > although most existing Diameter applications don't do this. > > Are there any other considerations of which we should be aware? > > My main concern regarding this is : why do we need to do such thing? > Why not implementing two different commands for each direction, as it has been always done so far? > > I think it more useful having more simple commands for each specific functionality, rather than merging every functionality in the same command, and, apart from that, making that command bi-directional.....I don't really see a reason for having bi-directional commands....(there is no shortage of command-codes). > Could you please explain? > > BR, > Carolina > > > > >jaakko.rajaniemi@nokia.com writes: > > > Hi, > > > > > > > So we would have three commands: > > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > > (Registration-Termination-Request, RTR?). > > > > - One (SSP->AAA) to update registration information and to > > > > pull user data. > > > > > > Right, this was what I had in mind. The > >SIP-Profile-Update-Type AVP could be changed in such a way > >that at least the UPDATE_PROFILE value is removed and the name > >of the AVP could be something else e.g. SIP-Server-Assignment-Type. > > > > > > What about the RETRIEVE_PROFILE value of the > >SIP-Profile-Update-Type AVP? Should we keep it or remove it? > >The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT > >value is not clear. > > > > > > Best Regards, Jaakko > > > > > > > -----Original Message----- > > > > From: ext Miguel-Angel Pallares-Lopez (ECE) > > > > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > > > > Sent: 15 February, 2002 12:37 > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > Hi, > > > > > > > > So we would have three commands: > > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > > (Registration-Termination-Request, RTR?). > > > > - One (SSP->AAA) to update registration information and to > > > > pull user data. > > > > > > > > It seems sensible to me. I agree that their semantic is > > > > different and we are not going to run out of commands codes. > > > > > > > > Best regards, > > > > Miguel > > > > > > > > > -----Original Message----- > > > > > From: jaakko.rajaniemi@nokia.com > >[mailto:jaakko.rajaniemi@nokia.com] > > > > > Sent: Friday, February 15, 2002 10:56 AM > > > > > To: carolina.canales-valenzuela@ece.ericsson.se; > >aaa-wg@merit.edu > > > > > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; > >nhberry@lucent.com; > > > > > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > > > > > mikko.aittola@nokia.com; > >Miguel-Angel.Pallares-Lopez@ece.ericsson.se > > > > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > In addition, PUR/PUA command is also used in the > > > > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > > > > > registering the user, either from the AAAH or the client. > > > > > From the logical point of view the profile updating and > > > > > (-/re/de-) registration are different operations and > > > > > therefore it would be quite natural to separate the profile > > > > > updating from the registration. > > > > > > > > > > This could be done by specifying different command codes for > > > > > the profile and the registration related operations. > > > > > > > > > > Best Regards, Jaakko > > > > > > > > > > > -----Original Message----- > > > > > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > > > > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > > > > > Sent: 13 February, 2002 19:42 > > > > > > To: 'aaa-wg@merit.edu' > > > > > > Cc: Carolina Canales Valenzuela (ECE); > > > > 'mccap@lucent.com'; Rajaniemi > > > > > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > > > > > 'nhberry@lucent.com'; > > > > > > 'dlwarren@nortelnetworks.com'; > > > > > 'peter.schmitt@icn.siemens.de'; Aittola > > > > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > > > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > > > > Hello, > > > > > > taking in account the requirements draft > > > > > > "draft-calhoun-sip-aaa-reqs-03" > > > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > > > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > > > > > requirement for the AAA infrastructure to distribute (*push > > > > > > or pull*)subscriber/service/security profiles to the relevant > > > > > > SIP servers. > > > > > > > > > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > > > > > implemented as an only, bi-directional command, PUR (section > > > > > > 3.5). This command might be issued either by the AAA or by > > > > > > the SIP server, in order to update the user profile in the > > > > > > corresponding node. > > > > > > > > > > > > However, I think it could be useful to split this command in > > > > > > 2 uni-directional commands, one issued from the AAA and > > > > > > another one issued by the SIP server. > > > > > > > > > > > > The fact that such a command can be issued from the same node > > > > > > as a request and as a reply, adds a lot of complexity in the > > > > > > implementation part. Why not using two different commands? I > > > > > > think there is no shortage of command codes, right? ;-). > > > > > > > > > > > > BR, > > > > > > Carolina > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Internet-Drafts@ietf.org > >[mailto:Internet-Drafts@ietf.org] > > > > > > >Sent: Tuesday, February 12, 2002 1:02 PM > > > > > > >Cc: aaa-wg@merit.edu > > > > > > >Subject: I-D > >ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > > > >Internet-Drafts directories. > > > > > > > > > > > > > > > > > > > > > Title : Diameter Multimedia Application > > > > > > > Author(s) : T. Johansson et al. > > > > > > > Filename : > >draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > Pages : 31 > > > > > > > Date : 11-Feb-02 > > > > > > > > > > > > > >This document specifies a Diameter application that allows > > > > > a Diameter > > > > > > >server to authenticate, authorize, and collect accounting > > > > > information > > > > > > >for Session Initiation Protocol (SIP) services rendered > > > > to a client > > > > > > >node. This application, combined with the base Diameter > > > > > protocol and > > > > > > >appropriate SIP extensions, allows SIP User Agents (UAs) > > > > to obtain > > > > > > >services from SIP servers that are connected to a Diameter > > > > > > >infrastructure. When combined with the Inter-Domain > > > > capability of > > > > > > >the base protocol, service may even be obtained from SIP > > > > > servers that > > > > > > >belong to foreign domains, as would be encountered by > > > > > roaming mobile > > > > > > >nodes. > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > > > >>http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > > > > > r-mm-app-01.txt > > > > > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > > > message to > > > > > > ietf-announce-request with the word unsubscribe in the body > > > > > > of the message. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > > > with the username > > > > > > "anonymous" and a password of your e-mail address. After > > > > logging in, > > > > > > type "cd internet-drafts" and then > > > > > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > Send a message to: > > > > > > mailserv@ietf.org. > > > > > > In the body type: > > > > > > "FILE > > > > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > > MIME-encoded form by using the "mpack" utility. > > To use this > > > > > > feature, insert the command "ENCODING mime" > >before the "FILE" > > > > > > command. To decode the response(s), you will > >need "munpack" or > > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > > mail readers > > > > > > exhibit different behavior, especially when dealing with > > > > > > "multipart" MIME messages (i.e. documents which > >have been split > > > > > > up into multiple messages), so check your local > >documentation on > > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > >mail reader > > > > > > implementation to automatically retrieve the ASCII > >version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Feb 19 14:30:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02441 for ; Tue, 19 Feb 2002 14:30:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B85919121E; Tue, 19 Feb 2002 14:29:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 886F391273; Tue, 19 Feb 2002 14:29:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D8CE9121E for ; Tue, 19 Feb 2002 14:29:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id ECD9C5DDAD; Tue, 19 Feb 2002 14:29:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 002285DD96 for ; Tue, 19 Feb 2002 14:29:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1JJTmh15215 for ; Tue, 19 Feb 2002 13:29:48 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1JJTmm26306 for ; Tue, 19 Feb 2002 13:29:48 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA21037 for ; Tue, 19 Feb 2002 13:29:48 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA11230 for ; Tue, 19 Feb 2002 13:29:47 -0600 (CST) Message-ID: <3C72A721.E0B688F4@ericsson.com> Date: Tue, 19 Feb 2002 11:27:29 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Accouting AVP issue... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, In my efforts to update the Diameter MIPv4 application I have stumble on the Accounting AVPs defined and realized that exactly the same AVPs are defined also in the NASREQ application, see below. Unless I have misunderstood something, I would suggest that we move these AVPs to the Base, since they are used by both NASREQ and MIP. Regards, /Tony In MIP: "7.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. 7.2 Accounting-Output-Extended-Octets AVP The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type Unsigned64, and contains the number of octets in IP packets sent to the user. 7.3 Accounting-Session-Time AVP The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, and indicates the length of the current session in seconds. 7.4 Accounting-Input-Extended-Packets AVP The Accounting-Input-Extended-Packets (AVP Code 365) is of type Unsigned64, and contains the number of IP packets received from the user. 7.5 Accounting-Output-Extended-Packets AVP The Accounting-Output-Extended-Packets (AVP Code 366) is of type Unsigned64, and contains the number of IP packets sent to the user." In NASREQ: 8.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received by the user. 8.2 Accounting-Output-Extended-Octets AVP The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type Unsigned64, and contains the number of octets in IP packets sent to the user. 8.3 Accounting-Session-Time AVP The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, and indicates the length of the current session in seconds. 8.4 Accounting-Input-Extended-Packets AVP The Accounting-Input-Extended-Packets (AVP Code 365) is of type Unsigned64, and contains the number of IP packets received by the user. 8.5 Accounting-Output-Extended-Packets AVP The Accounting-Output-Extended-Packets (AVP Code 366) is of type Unsigned64, and contains the number of IP packets sent to the user. From owner-aaa-wg@merit.edu Tue Feb 19 17:39:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07770 for ; Tue, 19 Feb 2002 17:39:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCABA9127C; Tue, 19 Feb 2002 17:39:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8C97E9127D; Tue, 19 Feb 2002 17:39:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FD5A9127C for ; Tue, 19 Feb 2002 17:39:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 360665DDAD; Tue, 19 Feb 2002 17:39:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 032E75DD8C for ; Tue, 19 Feb 2002 17:39:44 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1JMdhS29887 for ; Tue, 19 Feb 2002 16:39:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1JMdhd14315 for ; Tue, 19 Feb 2002 16:39:43 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA14179 for ; Tue, 19 Feb 2002 16:39:42 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA15145 for ; Tue, 19 Feb 2002 16:39:41 -0600 (CST) Message-ID: <3C72D3A3.FAB5FED1@ericsson.com> Date: Tue, 19 Feb 2002 14:37:23 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Remove MIP-Home-Agent-Host AVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Section 4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host AVP and contains the identity of the home agent requested by the mobile node in its registration request. This AVP is used by the AAAH to determine the destination of the HAR. However, this AVP demands changes to the Mobile IP protocol and looking back at the Issue 212 thread (http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html) the consensus was to NOT make use of this AVP. The agreed solution for Issue 212 was instead to require that the new AAAH perform the Server Discovery procedures (defined in the Base) to determine the URL of the Home Agent. So, I believe this AVP is an editorial mistake and should just be removed. Any objections to this? Regards, /Tony From owner-aaa-wg@merit.edu Tue Feb 19 21:28:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10725 for ; Tue, 19 Feb 2002 21:28:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3A7789127D; Tue, 19 Feb 2002 21:28:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 000DD9127E; Tue, 19 Feb 2002 21:28:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9A749127D for ; Tue, 19 Feb 2002 21:28:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id B302D5DDB3; Tue, 19 Feb 2002 21:28:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 51EB35DDAE for ; Tue, 19 Feb 2002 21:28:05 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1K1lXB15999 for ; Tue, 19 Feb 2002 17:47:33 -0800 Date: Tue, 19 Feb 2002 17:47:33 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Filing of issues against CMS-SEC? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'm trying to bring the issues list up to date, and noted quite a few "questions" relating to CMS-SEC that did not appear to result in filed issues. If there are changes you'd like to see made in the CMS-SEC spec that aren't already filed as issues, please submit them ASAP. Thanks! From owner-aaa-wg@merit.edu Wed Feb 20 03:23:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24843 for ; Wed, 20 Feb 2002 03:23:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 180C791285; Wed, 20 Feb 2002 03:23:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5D7091286; Wed, 20 Feb 2002 03:23:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B368891285 for ; Wed, 20 Feb 2002 03:23:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D9015DDB9; Wed, 20 Feb 2002 03:23:17 -0500 (EST) 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 5455E5DDAE for ; Wed, 20 Feb 2002 03:23:16 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1K8Mk322741 for ; Wed, 20 Feb 2002 10:22:46 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Feb 2002 10:23:07 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 10:23:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] Usage of TLS and IPsec Date: Wed, 20 Feb 2002 10:23:06 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64965@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] Usage of TLS and IPsec Thread-Index: AcG5X5GLQb0y8cDISUa1sVZpAVWCZAAiC6Iw From: To: Cc: X-OriginalArrivalTime: 20 Feb 2002 08:23:07.0224 (UTC) FILETIME=[D308D580:01C1B9E7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA24843 Hi Bernard, > This makes sense to me. Making security mandatory to implement but not > mandatory to use doesn't make sense in this case. After all, > with RADIUS security was mandatory to use. Agreed & I feel like we are gaining consensus on this issue. John From owner-aaa-wg@merit.edu Wed Feb 20 04:04:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25396 for ; Wed, 20 Feb 2002 04:04:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 37E2D91257; Wed, 20 Feb 2002 04:03:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1BD291287; Wed, 20 Feb 2002 04:03:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB9E691257 for ; Wed, 20 Feb 2002 04:03:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A67CC5DDBA; Wed, 20 Feb 2002 04:03:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 310765DDA1 for ; Wed, 20 Feb 2002 04:03:51 -0500 (EST) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA10246; Wed, 20 Feb 2002 10:01:36 +0100 From: "Fredrik Johansson" To: "Tony Johansson" , Subject: RE: [AAA-WG]: Remove MIP-Home-Agent-Host AVP Date: Wed, 20 Feb 2002 10:04:04 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3C72D3A3.FAB5FED1@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit yes, I object to this. Since server discovery will not work when a FA or HA is situated behind a NAT. And that is a possible scenario (at least for a FA). Thus server discovery will not work. section 4.5 in draft-ietf-mobileip-nat-traversal-00.txt "The UDP Tunnel Request Extension MAY be used in a Mobile IP Registration Request forwarded by a foreign agent to a home agent when the foreign agent is situated behind a NAT" What changes are required to the Mobile IP protocol? It might be something obvious, but I'm not up to speed after my 3 week skiing vacation. /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Tony Johansson >Sent: den 19 februari 2002 23:37 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Remove MIP-Home-Agent-Host AVP > > >All, > >Section 4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host >AVP and contains the identity of the home agent requested by the mobile >node in its registration request. This AVP is used by the AAAH to >determine the destination of the HAR. > >However, this AVP demands changes to the Mobile IP protocol and looking >back at the Issue 212 thread >(http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html) the >consensus was to NOT make use of this AVP. The agreed solution for Issue >212 was instead to require that the new AAAH perform the Server >Discovery procedures (defined in the Base) to determine the URL of the >Home Agent. > >So, I believe this AVP is an editorial mistake and should just be >removed. Any objections to this? > >Regards, > >/Tony > > > > From owner-aaa-wg@merit.edu Wed Feb 20 04:06:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25426 for ; Wed, 20 Feb 2002 04:06:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 916A391287; Wed, 20 Feb 2002 04:06:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AF3691288; Wed, 20 Feb 2002 04:06:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 42C9591287 for ; Wed, 20 Feb 2002 04:06:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 220FB5DDAE; Wed, 20 Feb 2002 04:06:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3A2AF5DDA1 for ; Wed, 20 Feb 2002 04:06:23 -0500 (EST) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA10301; Wed, 20 Feb 2002 10:04:10 +0100 From: "Fredrik Johansson" To: "Tony Johansson" , Subject: RE: [AAA-WG]: Accouting AVP issue... Date: Wed, 20 Feb 2002 10:06:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3C72A721.E0B688F4@ericsson.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit sounds good to me, btw. why Extended, can't it just be Accounting-Output-Octets... /Fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Tony Johansson >Sent: den 19 februari 2002 20:27 >To: aaa-wg@merit.edu >Subject: [AAA-WG]: Accouting AVP issue... > > >All, > >In my efforts to update the Diameter MIPv4 application I have stumble on >the Accounting AVPs defined and realized that exactly the same AVPs are >defined also in the NASREQ application, see below. > >Unless I have misunderstood something, I would suggest that we move >these AVPs to the Base, since they are used by both NASREQ and MIP. > >Regards, > >/Tony > >In MIP: > >"7.1 Accounting-Input-Extended-Octets AVP > > The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type > Unsigned64, and contains the number of octets in IP packets received > from the user. > > >7.2 Accounting-Output-Extended-Octets AVP > > The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type > Unsigned64, and contains the number of octets in IP packets sent to > the user. > > >7.3 Accounting-Session-Time AVP > > The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, > and indicates the length of the current session in seconds. > > >7.4 Accounting-Input-Extended-Packets AVP > > The Accounting-Input-Extended-Packets (AVP Code 365) is of type > Unsigned64, and contains the number of IP packets received from the > user. > > >7.5 Accounting-Output-Extended-Packets AVP > > The Accounting-Output-Extended-Packets (AVP Code 366) is of type > Unsigned64, and contains the number of IP packets sent to the user." > >In NASREQ: > >8.1 Accounting-Input-Extended-Octets AVP > > The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type > Unsigned64, and contains the number of octets in IP packets received > by the user. > > >8.2 Accounting-Output-Extended-Octets AVP > > The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type > Unsigned64, and contains the number of octets in IP packets sent to > the user. > > >8.3 Accounting-Session-Time AVP > > The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, > and indicates the length of the current session in seconds. > > >8.4 Accounting-Input-Extended-Packets AVP > > The Accounting-Input-Extended-Packets (AVP Code 365) is of type > Unsigned64, and contains the number of IP packets received by the > user. > > >8.5 Accounting-Output-Extended-Packets AVP > > The Accounting-Output-Extended-Packets (AVP Code 366) is of type > Unsigned64, and contains the number of IP packets sent to the user. > From owner-aaa-wg@merit.edu Wed Feb 20 04:54:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26090 for ; Wed, 20 Feb 2002 04:54:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A50709128A; Wed, 20 Feb 2002 04:54:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 647889128B; Wed, 20 Feb 2002 04:54:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 545699128A for ; Wed, 20 Feb 2002 04:54:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A49B5DD98; Wed, 20 Feb 2002 04:54:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id F0D8A5DD8C for ; Wed, 20 Feb 2002 04:54:00 -0500 (EST) Received: from fredrikj (hotel-14.local.ipunplugged.com [192.168.8.14]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA11323; Wed, 20 Feb 2002 10:51:41 +0100 From: "Fredrik Johansson" To: "Tony Johansson" , Subject: RE: [AAA-WG]: Remove MIP-Home-Agent-Host AVP Date: Wed, 20 Feb 2002 10:54:09 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please disregard my previous mail, the HA must have a public address so it will work sorry /fredrik >-----Original Message----- >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >Fredrik Johansson >Sent: den 20 februari 2002 10:04 >To: Tony Johansson; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Remove MIP-Home-Agent-Host AVP > > >yes, I object to this. Since server discovery will not work when a FA or HA >is situated behind a NAT. And that is a possible scenario (at least for a >FA). Thus server discovery will not work. > >section 4.5 in draft-ietf-mobileip-nat-traversal-00.txt >"The UDP Tunnel Request Extension MAY be used in a Mobile IP > Registration Request forwarded by a foreign agent to a home agent > when the foreign agent is situated behind a NAT" > >What changes are required to the Mobile IP protocol? It might be something >obvious, but I'm not up to speed after my 3 week skiing vacation. > >/Fredrik > >>-----Original Message----- >>From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >>Tony Johansson >>Sent: den 19 februari 2002 23:37 >>To: aaa-wg@merit.edu >>Subject: [AAA-WG]: Remove MIP-Home-Agent-Host AVP >> >> >>All, >> >>Section 4.11 in the Diameter MIPv4 appl. defines the MIP-Home-Agent-Host >>AVP and contains the identity of the home agent requested by the mobile >>node in its registration request. This AVP is used by the AAAH to >>determine the destination of the HAR. >> >>However, this AVP demands changes to the Mobile IP protocol and looking >>back at the Issue 212 thread >>(http://www.merit.edu/mail.archives/aaa-wg/2001-11/msg00062.html) the >>consensus was to NOT make use of this AVP. The agreed solution for Issue >>212 was instead to require that the new AAAH perform the Server >>Discovery procedures (defined in the Base) to determine the URL of the >>Home Agent. >> >>So, I believe this AVP is an editorial mistake and should just be >>removed. Any objections to this? >> >>Regards, >> >>/Tony >> >> >> >> From owner-aaa-wg@merit.edu Wed Feb 20 05:38:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26483 for ; Wed, 20 Feb 2002 05:38:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70AA79128B; Wed, 20 Feb 2002 05:38:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A3AC9128C; Wed, 20 Feb 2002 05:38:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF9AA9128B for ; Wed, 20 Feb 2002 05:38:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id C8CF25DD98; Wed, 20 Feb 2002 05:38:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from alvin.loniis.spb.su (gw1.loniis.spb.su [195.201.37.253]) by segue.merit.edu (Postfix) with ESMTP id 8A72A5DD8C for ; Wed, 20 Feb 2002 05:38:05 -0500 (EST) Received: from rts.nio1.loniis (rts.nio1.loniis [192.168.0.143] (may be forged)) by alvin.loniis.spb.su (8.10.0/8.10.0) with ESMTP id g1KAbuX25539 for ; Wed, 20 Feb 2002 13:37:56 +0300 (MSK) Received: from totosha (totosha.rts.nio1.loniis [192.168.100.173]) by rts.nio1.loniis (Postfix) with SMTP id C10F78047 for ; Wed, 20 Feb 2002 13:37:52 +0300 (MSK) Message-ID: <001a01c1b9fb$25dc29c0$ad64a8c0@rts.nio1.loniis> From: "Zarubin Anton" To: Subject: [AAA-WG]: Simple question Date: Wed, 20 Feb 2002 13:41:26 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello all. Sorry for this simple question, not appurtenant to DIAMETER. Please help me to understand why we use one message to authenticate/authorize user and two messages for accounting -start and stop. Example - AA-request, Accounting-Request and Session-Termination Request. Why we wouldn't to combine request for authentication with first request for accounting? If will appear necessity to use separately auth functions and acct functions when possibly to utilize this single message with different attributes. Thanks Anton A. Zarubin Saint-Petersburg, LONIIS e-mail: totosha@rts.loniis.ru From owner-aaa-wg@merit.edu Wed Feb 20 08:37:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00130 for ; Wed, 20 Feb 2002 08:37:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA4FB9128E; Wed, 20 Feb 2002 08:36:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7E7F9128F; Wed, 20 Feb 2002 08:36:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BE709128E for ; Wed, 20 Feb 2002 08:36:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A0E85DDBC; Wed, 20 Feb 2002 08:36:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id E205B5DD8C for ; Wed, 20 Feb 2002 08:36:55 -0500 (EST) Received: (qmail 371 invoked by uid 500); 20 Feb 2002 13:36:27 -0000 Date: Wed, 20 Feb 2002 07:36:27 -0600 From: David Frascone To: Zarubin Anton Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Simple question Message-ID: <20020220133627.GC29510@newman.frascone.com> Mail-Followup-To: Zarubin Anton , aaa-wg@merit.edu References: <001a01c1b9fb$25dc29c0$ad64a8c0@rts.nio1.loniis> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001a01c1b9fb$25dc29c0$ad64a8c0@rts.nio1.loniis> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Comments inline. On Wednesday, 20 Feb 2002, Zarubin Anton wrote: > Hello all. > > Sorry for this simple question, not appurtenant to DIAMETER. > > Please help me to understand why we use one message to > authenticate/authorize user and two messages for accounting -start and stop. > Example - AA-request, Accounting-Request and Session-Termination Request. > > Why we wouldn't to combine request for authentication with first request for > accounting? What if the authentication server and accounting server are on two different machines. (Or, possibly in different realms). -Dave From owner-aaa-wg@merit.edu Wed Feb 20 08:47:56 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00408 for ; Wed, 20 Feb 2002 08:47:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7925E9128F; Wed, 20 Feb 2002 08:47:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2A11D91290; Wed, 20 Feb 2002 08:47:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C89CA9128F for ; Wed, 20 Feb 2002 08:47:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id A13685DDAE; Wed, 20 Feb 2002 08:47:12 -0500 (EST) 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 4C2445DD8C for ; Wed, 20 Feb 2002 08:47:11 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1KDke324701 for ; Wed, 20 Feb 2002 15:46:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Feb 2002 15:47:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 15:41:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE 250: ready for closure? Date: Wed, 20 Feb 2002 15:41:46 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6497C@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE 250: ready for closure? Thread-Index: AcG5WS2xq7aQRbDSSwCgWpEksiIn3QAuxTcw From: To: Cc: , X-OriginalArrivalTime: 20 Feb 2002 13:41:47.0305 (UTC) FILETIME=[577DA990:01C1BA14] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA00408 Hi Bernard, > > I've reviewed the previous threads on this & I feel we are > ready to close on this. > > Below is what I have. Note I have moved to text reference > tags - it makes things > > somewhat easier. > > > > Oddly enough, there were no direct references for UDP. In > section 4.4 Derived AVP > > Data Formats, udp is listed under transport-protocol, for > the URI for aaa. How should > > we handle the UDP reference? > > > > Can we remove this reference? Otherwise, I'd say make UDP > non-normative. I suggest removing it completely. The Diameter base spec isn't using UDP. John From owner-aaa-wg@merit.edu Wed Feb 20 08:53:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00539 for ; Wed, 20 Feb 2002 08:53:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 222D891290; Wed, 20 Feb 2002 08:52:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E400791291; Wed, 20 Feb 2002 08:52:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9B8291290 for ; Wed, 20 Feb 2002 08:52:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A606B5DDBF; Wed, 20 Feb 2002 08:52:53 -0500 (EST) 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 718395DD8C for ; Wed, 20 Feb 2002 08:52:52 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1KDqL327846 for ; Wed, 20 Feb 2002 15:52:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Feb 2002 15:52:50 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 15:42:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE 250: ready for closure? Date: Wed, 20 Feb 2002 15:42:42 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC6497D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE 250: ready for closure? Thread-Index: AcG5VooB0shHKiMxT4agHhyLiNvOawAvdU7g From: To: X-OriginalArrivalTime: 20 Feb 2002 13:42:42.0646 (UTC) FILETIME=[787A0760:01C1BA14] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA00539 Hi Jari, > Just to be on the very safe side, why don't you put the > correct references > to UDP/TCP/SCTP in section 4.4 as well. UDP is RFC 768. This would be > a .... normative reference I think because you have to be > able to understand what the URIs mean. Or? Not needed, as the URIs are well explained within the document. John From owner-aaa-wg@merit.edu Wed Feb 20 09:01:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00738 for ; Wed, 20 Feb 2002 09:01:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C54CD91291; Wed, 20 Feb 2002 09:00:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EE4A91292; Wed, 20 Feb 2002 09:00:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76B7591291 for ; Wed, 20 Feb 2002 09:00:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AE595DDAE; Wed, 20 Feb 2002 09:00:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 4AB5B5DD8C for ; Wed, 20 Feb 2002 09:00:49 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id OAA16396; Wed, 20 Feb 2002 14:58:35 +0100 Message-ID: <3C73B9FF.1070109@ipunplugged.com> Date: Wed, 20 Feb 2002 16:00:15 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Accouting AVP issue... References: <3C72A721.E0B688F4@ericsson.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 Tony Johansson wrote: >All, > >In my efforts to update the Diameter MIPv4 application I have stumble on >the Accounting AVPs defined and realized that exactly the same AVPs are >defined also in the NASREQ application, see below. > >Unless I have misunderstood something, I would suggest that we move >these AVPs to the Base, since they are used by both NASREQ and MIP. > I don't have any objections either, but I think the perspective could be a bit broader. Considering that special provisions are made to ensure that the lifetime of the protocol stretches beyond 2030-something my reasoning is that it seems likely that most accounting application will count both bytes and packets and measure the duration of the session. j From owner-aaa-wg@merit.edu Wed Feb 20 09:17:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01151 for ; Wed, 20 Feb 2002 09:17:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ACF0491292; Wed, 20 Feb 2002 09:17:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DC7591293; Wed, 20 Feb 2002 09:17:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82E5D91292 for ; Wed, 20 Feb 2002 09:17:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5798D5DDBC; Wed, 20 Feb 2002 09:17:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 336F45DD8C for ; Wed, 20 Feb 2002 09:17:23 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1KEHTZ28503 for ; Wed, 20 Feb 2002 16:17:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 20 Feb 2002 16:17:21 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 20 Feb 2002 16:17:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: DNS SRV Issues - More of them Date: Wed, 20 Feb 2002 16:17:20 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64987@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: DNS SRV Issues - More of them Thread-Index: AcGuXDGjXKLMSKL8SR2Q/LKCOJDOigLvIa5A From: To: , Cc: X-OriginalArrivalTime: 20 Feb 2002 14:17:21.0683 (UTC) FILETIME=[4FADE630:01C1BA19] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA01151 Hi Allison, Jonathan R. has mentioned that SIP-SRV should be hitting a IETF-EDITORS list near you today. Do you recommend taking this as the basis for Diameter as well? As I understand, the SIP URI will change, when using secured traffic. It would look something like this: sips:user@host (sip + tls) sip:user@host (sip) in Diameter terms, this may become something like: Diameter-Identity = "aaa://" fqdn [ port ] [ transport ] [ protocol ] Diameter-Identity = "aaas://" fqdn [ port ] [ transport ] [ protocol ] -> with TLS Is my understanding correct? John > -----Original Message----- > From: ext Allison Mankin [mailto:mankin@isi.edu] > Sent: 05 February, 2002 17:45 > To: David Frascone > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: DNS SRV Issues - More of them > > > Hi, David, > > Good issues! > > The SRV text in the Diameter base was modeled on SRV text that had > been reviewed for SIP by the IESG. However, a re-review of sip-srv has > caused major changes. SIP and Diameter are the first major uses of > SRV to try to get published, so there's some discovery of the issues > going on by the ADs too. > > A new sip draft contains the results of the new review. The algorithm > is to use a NAPTR lookup (RFC 2915) to get the transport service and > then use SRV on the NAPTR result to get a choice of servers ready to > provide that srevice. I am sure the IESG will require a version of > this from Diameter as well. It has been reviewed by the DNS folks in > IESG and found satisfactory. > > It is draft-ietf-sip-srv-04.txt. > > sip-srv includes TLS(tcp) as a transport in the NAPTR design, but > several of us have pointed out that this is insecure. The problem is > the ease of bid-down from TLS use to use of an unsecured transport. > DNSSEC is not out there, and will only deploy slowly. It is too easy > for the reply from the DNS to be altered so that TLS is not chosen by > the client. This is an insecure way to treat the TLS secure channel. > > So they have just gotten my AD comments about changing to another > approach - it also involves the question of the special TLS port. It > turns out that this usage is not accepted by IESG (though not for > security reasons) and so my guidance to Pat earlier that it was fine > was not correct. I suggest to Diameter (as well as SIP) a form of > same-port TLS use where the URI provides the reference integrity: > sips: in the SIP case. > > There is a TLS issue with failovers too - there does needs to be > memory in the packets that TLS was in use and required for that hop, > so that a TLS connection can be tried during a failover...from both > directions for the hop. > > Allison > From owner-aaa-wg@merit.edu Wed Feb 20 11:12:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05000 for ; Wed, 20 Feb 2002 11:12:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D04789129A; Wed, 20 Feb 2002 11:12:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95C7D9129C; Wed, 20 Feb 2002 11:12:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EA829129A for ; Wed, 20 Feb 2002 11:12:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C4115DDD5; Wed, 20 Feb 2002 11:12:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from zrtps0kp.nortelnetworks.com (zrtps0kp.nortelnetworks.com [47.140.192.56]) by segue.merit.edu (Postfix) with ESMTP id 8F0D75DDBC for ; Wed, 20 Feb 2002 11:12:30 -0500 (EST) Received: from znsgs01r.europe.nortel.com (znsgs01r.europe.nortel.com [47.137.129.92]) by zrtps0kp.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KGCQC15315; Wed, 20 Feb 2002 11:12:27 -0500 (EST) Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g1KBSQ216037; Wed, 20 Feb 2002 11:28:26 GMT Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <1XS8HK13>; Wed, 20 Feb 2002 11:28:57 -0000 Message-ID: From: "Daniel Warren" To: "'Pete McCann'" , "Carolina Canales Valenzuela (ECE)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Date: Wed, 20 Feb 2002 11:28:42 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BA01.BFFBFA20" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BA01.BFFBFA20 Content-Type: text/plain; charset="iso-8859-1" As a general statement, it would seem sensible that messages going in opposite directions be split (to avoid confusion) and messages with fundamentally different semantics also be split for clarity. That said, whilst we are not ever going to run out of message names, we do want to keep the implementation light, so lets try and consolidate sensibly. It would be all to easy to go too far in one direction or the other, but usually it is fairly obvious when a new message is required and when one is not. Best Regards Dan -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: 19 February 2002 16:52 To: Carolina Canales Valenzuela (ECE) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt Hi, Carolina, I agree, we should split PUR into two messges. -Pete Carolina Canales Valenzuela (ECE) writes: > >* Is it technically OK to use a message in both directions > > (client->server and server->client)? I think the answer is yes, > > although most existing Diameter applications don't do this. > > Are there any other considerations of which we should be aware? > > My main concern regarding this is : why do we need to do such thing? > Why not implementing two different commands for each direction, as it has been always done so far? > > I think it more useful having more simple commands for each specific functionality, rather than merging every functionality in the same command, and, apart from that, making that command bi-directional.....I don't really see a reason for having bi-directional commands....(there is no shortage of command-codes). > Could you please explain? > > BR, > Carolina > > > > >jaakko.rajaniemi@nokia.com writes: > > > Hi, > > > > > > > So we would have three commands: > > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > > (Registration-Termination-Request, RTR?). > > > > - One (SSP->AAA) to update registration information and to > > > > pull user data. > > > > > > Right, this was what I had in mind. The > >SIP-Profile-Update-Type AVP could be changed in such a way > >that at least the UPDATE_PROFILE value is removed and the name > >of the AVP could be something else e.g. SIP-Server-Assignment-Type. > > > > > > What about the RETRIEVE_PROFILE value of the > >SIP-Profile-Update-Type AVP? Should we keep it or remove it? > >The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT > >value is not clear. > > > > > > Best Regards, Jaakko > > > > > > > -----Original Message----- > > > > From: ext Miguel-Angel Pallares-Lopez (ECE) > > > > [mailto:Miguel-Angel.Pallares-Lopez@ece.ericsson.se] > > > > Sent: 15 February, 2002 12:37 > > > > To: aaa-wg@merit.edu > > > > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > Hi, > > > > > > > > So we would have three commands: > > > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?). > > > > - One (AAA->SSP) to de-register the user from AAA to SSP > > > > (Registration-Termination-Request, RTR?). > > > > - One (SSP->AAA) to update registration information and to > > > > pull user data. > > > > > > > > It seems sensible to me. I agree that their semantic is > > > > different and we are not going to run out of commands codes. > > > > > > > > Best regards, > > > > Miguel > > > > > > > > > -----Original Message----- > > > > > From: jaakko.rajaniemi@nokia.com > >[mailto:jaakko.rajaniemi@nokia.com] > > > > > Sent: Friday, February 15, 2002 10:56 AM > > > > > To: carolina.canales-valenzuela@ece.ericsson.se; > >aaa-wg@merit.edu > > > > > Cc: mccap@lucent.com; Johanna.Wild@motorola.com; > >nhberry@lucent.com; > > > > > dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de; > > > > > mikko.aittola@nokia.com; > >Miguel-Angel.Pallares-Lopez@ece.ericsson.se > > > > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > Hi, > > > > > > > > > > In addition, PUR/PUA command is also used in the > > > > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) > > > > > registering the user, either from the AAAH or the client. > > > > > From the logical point of view the profile updating and > > > > > (-/re/de-) registration are different operations and > > > > > therefore it would be quite natural to separate the profile > > > > > updating from the registration. > > > > > > > > > > This could be done by specifying different command codes for > > > > > the profile and the registration related operations. > > > > > > > > > > Best Regards, Jaakko > > > > > > > > > > > -----Original Message----- > > > > > > From: ext carolina.canales-valenzuela@ece.ericsson.se > > > > > > [mailto:carolina.canales-valenzuela@ece.ericsson.se] > > > > > > Sent: 13 February, 2002 19:42 > > > > > > To: 'aaa-wg@merit.edu' > > > > > > Cc: Carolina Canales Valenzuela (ECE); > > > > 'mccap@lucent.com'; Rajaniemi > > > > > > Jaakko (NET/Espoo); 'Johanna.Wild@motorola.com'; > > > > > 'nhberry@lucent.com'; > > > > > > 'dlwarren@nortelnetworks.com'; > > > > > 'peter.schmitt@icn.siemens.de'; Aittola > > > > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE) > > > > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > > > > Hello, > > > > > > taking in account the requirements draft > > > > > > "draft-calhoun-sip-aaa-reqs-03" > > > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa- > > > > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a > > > > > > requirement for the AAA infrastructure to distribute (*push > > > > > > or pull*)subscriber/service/security profiles to the relevant > > > > > > SIP servers. > > > > > > > > > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been > > > > > > implemented as an only, bi-directional command, PUR (section > > > > > > 3.5). This command might be issued either by the AAA or by > > > > > > the SIP server, in order to update the user profile in the > > > > > > corresponding node. > > > > > > > > > > > > However, I think it could be useful to split this command in > > > > > > 2 uni-directional commands, one issued from the AAA and > > > > > > another one issued by the SIP server. > > > > > > > > > > > > The fact that such a command can be issued from the same node > > > > > > as a request and as a reply, adds a lot of complexity in the > > > > > > implementation part. Why not using two different commands? I > > > > > > think there is no shortage of command codes, right? ;-). > > > > > > > > > > > > BR, > > > > > > Carolina > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Internet-Drafts@ietf.org > >[mailto:Internet-Drafts@ietf.org] > > > > > > >Sent: Tuesday, February 12, 2002 1:02 PM > > > > > > >Cc: aaa-wg@merit.edu > > > > > > >Subject: I-D > >ACTION:draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > > > > > > > > > > > > > > >A New Internet-Draft is available from the on-line > > > > > > >Internet-Drafts directories. > > > > > > > > > > > > > > > > > > > > > Title : Diameter Multimedia Application > > > > > > > Author(s) : T. Johansson et al. > > > > > > > Filename : > >draft-johansson-aaa-diameter-mm-app-01.txt > > > > > > > Pages : 31 > > > > > > > Date : 11-Feb-02 > > > > > > > > > > > > > >This document specifies a Diameter application that allows > > > > > a Diameter > > > > > > >server to authenticate, authorize, and collect accounting > > > > > information > > > > > > >for Session Initiation Protocol (SIP) services rendered > > > > to a client > > > > > > >node. This application, combined with the base Diameter > > > > > protocol and > > > > > > >appropriate SIP extensions, allows SIP User Agents (UAs) > > > > to obtain > > > > > > >services from SIP servers that are connected to a Diameter > > > > > > >infrastructure. When combined with the Inter-Domain > > > > capability of > > > > > > >the base protocol, service may even be obtained from SIP > > > > > servers that > > > > > > >belong to foreign domains, as would be encountered by > > > > > roaming mobile > > > > > > >nodes. > > > > > > > > > > > > > >A URL for this Internet-Draft is: > > > > > > > >>http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete > > > > > > r-mm-app-01.txt > > > > > > > > > > > > To remove yourself from the IETF Announcement list, send a > > > > > message to > > > > > > ietf-announce-request with the word unsubscribe in the body > > > > > > of the message. > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login > > > > > > with the username > > > > > > "anonymous" and a password of your e-mail address. After > > > > logging in, > > > > > > type "cd internet-drafts" and then > > > > > > "get draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > > > A list of Internet-Drafts directories can be found in > > > > > > http://www.ietf.org/shadow.html > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > > > > > > > > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > > > > > > > > > Send a message to: > > > > > > mailserv@ietf.org. > > > > > > In the body type: > > > > > > "FILE > > > > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt". > > > > > > > > > > > > NOTE: The mail server at ietf.org can return the document in > > > > > > MIME-encoded form by using the "mpack" utility. > > To use this > > > > > > feature, insert the command "ENCODING mime" > >before the "FILE" > > > > > > command. To decode the response(s), you will > >need "munpack" or > > > > > > a MIME-compliant mail reader. Different MIME-compliant > > > > > > mail readers > > > > > > exhibit different behavior, especially when dealing with > > > > > > "multipart" MIME messages (i.e. documents which > >have been split > > > > > > up into multiple messages), so check your local > >documentation on > > > > > > how to manipulate these messages. > > > > > > > > > > > > > > > > > > Below is the data which will enable a MIME compliant > >mail reader > > > > > > implementation to automatically retrieve the ASCII > >version of the > > > > > > Internet-Draft. > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C1BA01.BFFBFA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: RE: = draft-johansson-aaa-diameter-mm-app-01.txt

As a general statement, it would seem sensible that = messages going in opposite directions be split (to avoid confusion) and = messages with fundamentally different semantics also be split for = clarity. 

That said, whilst we are not ever going to run out of = message names, we do want to keep the implementation light, so lets try = and consolidate sensibly.  It would be all to easy to go too far = in one direction or the other, but usually it is fairly obvious when a = new message is required and when one is not.

Best Regards

Dan

-----Original Message-----
From: Pete McCann [mailto:mccap@lucent.com]
Sent: 19 February 2002 16:52
To: Carolina Canales Valenzuela (ECE)
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: RE: = draft-johansson-aaa-diameter-mm-app-01.txt



Hi, Carolina,

I agree, we should split PUR into two messges.

-Pete

Carolina Canales Valenzuela (ECE) writes:
 > >* Is it technically OK to use a = message in both directions
 > >  (client->server and = server->client)?  I think the answer is yes,
 > >  although most existing = Diameter applications don't do this.
 > >  Are there any other = considerations of which we should be aware?
 >
 > My main concern regarding this is : why = do we need to do such thing?
 > Why not implementing two different = commands for each direction, as it has been always done so far?
 >
 > I think it more useful having more simple = commands for each specific functionality, rather than merging every = functionality in the same command, and, apart from that, making that = command bi-directional.....I don't really see a reason for having = bi-directional commands....(there is no shortage of command-codes). =

 > Could you please explain?
 >
 > BR,
 > Carolina
 > 
 >
 >
 > >jaakko.rajaniemi@nokia.com = writes:
 > > > Hi,
 > > >
 > > > > So we would have three = commands:
 > > > > - One (AAA->SSP) to = update user data (Push-Profile-Request, PPR?).
 > > > > - One (AAA->SSP) to = de-register the user from AAA to SSP
 > > > > = (Registration-Termination-Request, RTR?).
 > > > > - One (SSP->AAA) to = update registration information and to
 > > > > pull user data.
 > > >
 > > > Right, this was what I had in = mind. The
 > >SIP-Profile-Update-Type AVP could be = changed in such  a way
 > >that at least the UPDATE_PROFILE = value is removed and the name
 > >of the AVP could be something else = e.g. SIP-Server-Assignment-Type.
 > > >
 > > > What about the RETRIEVE_PROFILE = value of the
 > >SIP-Profile-Update-Type AVP? Should = we keep it or remove it?
 > >The difference of the = RETRIEVE_PROFILE to the NO_ASSIGNMENT
 > >value is not clear.
 > > >
 > > > Best Regards, Jaakko
 > > >
 > > > > -----Original = Message-----
 > > > > From: ext Miguel-Angel = Pallares-Lopez (ECE)
 > > > > [mailto:Migue= l-Angel.Pallares-Lopez@ece.ericsson.se]
 > > > > Sent: 15 February, 2002 = 12:37
 > > > > To: = aaa-wg@merit.edu
 > > > > Subject: [AAA-WG]: RE: = draft-johansson-aaa-diameter-mm-app-01.txt
 > > > >
 > > > >
 > > > > Hi,
 > > > >
 > > > > So we would have three = commands:
 > > > > - One (AAA->SSP) to = update user data (Push-Profile-Request, PPR?).
 > > > > - One (AAA->SSP) to = de-register the user from AAA to SSP
 > > > > = (Registration-Termination-Request, RTR?).
 > > > > - One (SSP->AAA) to = update registration information and to
 > > > > pull user data.
 > > > >
 > > > > It seems sensible to me. I = agree that their semantic is
 > > > > different and we are not = going to run out of commands codes.
 > > > >
 > > > > Best regards,
 > > > > Miguel
 > > > >
 > > > > > -----Original = Message-----
 > > > > > From: = jaakko.rajaniemi@nokia.com
 > >[mailto:jaakko.rajaniemi@nokia= .com]
 > > > > > Sent: Friday, = February 15, 2002 10:56 AM
 > > > > > To: = carolina.canales-valenzuela@ece.ericsson.se;
 > >aaa-wg@merit.edu
 > > > > > Cc: mccap@lucent.com; = Johanna.Wild@motorola.com;
 > >nhberry@lucent.com;
 > > > > > = dlwarren@nortelnetworks.com; peter.schmitt@icn.siemens.de;
 > > > > > = mikko.aittola@nokia.com;
 > = >Miguel-Angel.Pallares-Lopez@ece.ericsson.se
 > > > > > Subject: RE: = draft-johansson-aaa-diameter-mm-app-01.txt
 > > > > >
 > > > > >
 > > > > > Hi,
 > > > > >
 > > > > > In addition, PUR/PUA = command is also used in the
 > > > > > = draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-)
 > > > > > registering the user, = either from the AAAH or the client.
 > > > > > From the logical = point of view the profile updating and
 > > > > > (-/re/de-) = registration are different operations and
 > > > > > therefore it would be = quite natural to separate the profile
 > > > > > updating from the = registration.
 > > > > >
 > > > > > This could be done by = specifying different command codes for
 > > > > > the profile and the = registration related operations.
 > > > > >
 > > > > > Best Regards, = Jaakko
 > > > > >
 > > > > > > -----Original = Message-----
 > > > > > > From: ext = carolina.canales-valenzuela@ece.ericsson.se
 > > > > > > [mailto:carol= ina.canales-valenzuela@ece.ericsson.se]
 > > > > > > Sent: 13 = February, 2002 19:42
 > > > > > > To: = 'aaa-wg@merit.edu'
 > > > > > > Cc: Carolina = Canales Valenzuela (ECE);
 > > > > 'mccap@lucent.com'; = Rajaniemi
 > > > > > > Jaakko = (NET/Espoo); 'Johanna.Wild@motorola.com';
 > > > > > = 'nhberry@lucent.com';
 > > > > > > = 'dlwarren@nortelnetworks.com';
 > > > > > = 'peter.schmitt@icn.siemens.de'; Aittola
 > > > > > > Mikko = (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE)
 > > > > > > Subject: = RE:draft-johansson-aaa-diameter-mm-app-01.txt
 > > > > > >
 > > > > > >
 > > > > > > Hello,
 > > > > > > taking in = account the requirements draft
 > > > > > > = "draft-calhoun-sip-aaa-reqs-03"
 > > > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-s= ip-aaa-
 > > > > > > reqs-03.txt), in = section 3.0, bullet 4, I can see there's a
 > > > > > > requirement for = the AAA infrastructure  to distribute (*push
 > > > > > > or = pull*)subscriber/service/security profiles to the relevant
 > > > > > > SIP = servers.
 > > > > > >
 > > > > > > In = "draft-johansson-aaa-diameter-mm-app-01" this has been =
 > > > > > > implemented as = an only, bi-directional command, PUR (section
 > > > > > > 3.5). This = command might be issued either by the AAA or by
 > > > > > > the SIP server, = in order to update the user profile in the
 > > > > > > corresponding = node.
 > > > > > >
 > > > > > > However, I think = it could be useful to split this command in
 > > > > > > 2 = uni-directional commands, one issued from the AAA and
 > > > > > > another one = issued by the SIP server.
 > > > > > >
 > > > > > > The fact that = such a command can be issued from the same node
 > > > > > > as a request and = as a reply, adds a lot of complexity in the
 > > > > > > implementation = part. Why not using two different commands? I
 > > > > > > think there is = no shortage of command codes, right? ;-).
 > > > > > >
 > > > > > > BR,
 > > > > > > Carolina
 > > > > > >
 > > > > > >
 > > > > > > = >-----Original Message-----
 > > > > > > >From: = Internet-Drafts@ietf.org
 > >[mailto:Internet-Drafts@ietf.org= ]
 > > > > > > >Sent: = Tuesday, February 12, 2002 1:02 PM
 > > > > > > >Cc: = aaa-wg@merit.edu
 > > > > > > >Subject: I-D =
 > = >ACTION:draft-johansson-aaa-diameter-mm-app-01.txt
 > > > > > > >
 > > > > > > >
 > > > > > > >A New = Internet-Draft is available from the on-line
 > > > > > > = >Internet-Drafts directories.
 > > > > > > >
 > > > > > > >
 > > > > > > >  = Title           : Diameter = Multimedia Application
 > > > > > > >  = Author(s)       : T. Johansson et = al.
 > > > > > > >  = Filename        :
 > = >draft-johansson-aaa-diameter-mm-app-01.txt
 > > > > > > >  = Pages           : = 31
 > > > > > > >  = Date            : = 11-Feb-02
 > > > > > > >  =
 > > > > > > >This = document specifies a Diameter application that allows
 > > > > > a Diameter
 > > > > > > >server to = authenticate, authorize, and collect accounting
 > > > > > information
 > > > > > > >for Session = Initiation Protocol (SIP) services rendered
 > > > > to a client
 > > > > > > >node.  = This application, combined with the base Diameter
 > > > > > protocol and
 > > > > > > >appropriate = SIP extensions, allows SIP User Agents (UAs)
 > > > > to obtain
 > > > > > > >services = from SIP servers that are connected to a Diameter
 > > > > > > = >infrastructure.  When combined with the Inter-Domain
 > > > > capability of
 > > > > > > >the base = protocol, service may even be obtained from SIP
 > > > > > servers that
 > > > > > > >belong to = foreign domains, as would be encountered by
 > > > > > roaming mobile
 > > > > > > = >nodes.
 > > > > > > >
 > > > > > > >A URL for = this Internet-Draft is:
 > > > > > >
 > >>http://www.ietf.org/internet-drafts/draft-johansson-aa= a-diamete
 > > > > > > = r-mm-app-01.txt
 > > > > > >
 > > > > > > To remove = yourself from the IETF Announcement list, send a
 > > > > > message to
 > > > > > > = ietf-announce-request with the word unsubscribe in the body
 > > > > > > of the = message.
 > > > > > >
 > > > > > > Internet-Drafts = are also available by anonymous FTP. Login
 > > > > > > with the = username
 > > > > > > = "anonymous" and a password of your e-mail address. After =
 > > > > logging in,
 > > > > > > type "cd = internet-drafts" and then
 > > > > > >    = "get draft-johansson-aaa-diameter-mm-app-01.txt".
 > > > > > >
 > > > > > > A list of = Internet-Drafts directories can be found in
 > > > > > > http://www.ietf.org/shadow.html
 > > > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
 > > > > > >
 > > > > > >
 > > > > > > Internet-Drafts = can also be obtained by e-mail.
 > > > > > >
 > > > > > > Send a message = to:
 > > > > > >    = mailserv@ietf.org.
 > > > > > > In the body = type:
 > > > > > >    = "FILE
 > > > > > > = /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt".
 > > > > > >    =
 > > > > > > = NOTE:      The mail server at ietf.org can = return the document in
 > > > > > >    = MIME-encoded form by using the "mpack" utility.
 > > To use this
 > > > > > >    = feature, insert the command "ENCODING mime"
 > >before the "FILE"
 > > > > > >    = command.  To decode the response(s), you will
 > >need "munpack" or
 > > > > > >    a = MIME-compliant mail reader.  Different MIME-compliant
 > > > > > > mail = readers
 > > > > > >    = exhibit different behavior, especially when dealing with
 > > > > > >    = "multipart" MIME messages (i.e. documents which
 > >have been split
 > > > > > >    up = into multiple messages), so check your local
 > >documentation on
 > > > > > >    how = to manipulate these messages.
 > > > > > >    =        
 > > > > > >    =        
 > > > > > > Below is the = data which will enable a MIME compliant
 > >mail reader
 > > > > > > implementation = to automatically retrieve the ASCII
 > >version of the
 > > > > > > = Internet-Draft.
 > > > > > >
 > > > > >
 > > > >
 > > >
 > >
 >

------_=_NextPart_001_01C1BA01.BFFBFA20-- From owner-aaa-wg@merit.edu Wed Feb 20 12:21:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07647 for ; Wed, 20 Feb 2002 12:21:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4A00A9121F; Wed, 20 Feb 2002 12:20:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 13E81912A0; Wed, 20 Feb 2002 12:20:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E76169121F for ; Wed, 20 Feb 2002 12:20:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id C97BF5DD94; Wed, 20 Feb 2002 12:20:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id E44305DD8C for ; Wed, 20 Feb 2002 12:20:53 -0500 (EST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g1KHKnd28440 for ; Wed, 20 Feb 2002 12:20:49 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id <1K40C2G2>; Wed, 20 Feb 2002 17:20:43 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB003D34DDB@en0033exch001u.uk.lucent.com> From: "Berry, Nigel Howard (Nigel)" To: aaa-wg@merit.edu Subject: [AAA-WG]: ISSUE: redirect based on user names Date: Wed, 20 Feb 2002 17:20:41 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Kevin, This extra optionality could be very useful. There may a bit more complexity required in the redirect agent but not withstanding this I would like to support the addition of this extra functionality, Regards, Nigel ** included from original e-mail *** Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: February 14th, 2002 Reference: none Document: base-08alpha02 Comment type: Technical Priority: 1 Sections: 2.9.3, 6.12 Rationale/Explanation of issue: Diameter redirect agents currently provide realm to server address resolution. Within a single administrative domain, it could be useful to allow redirect agents to have the option of providing user to server address resolution. Requested change: * change the first paragraph of section 2.9.3 to read: Redirect agents provide Realm to Server address resolution and MAY also provide User to Server address resolution. These redirect agents would make use of the Diameter routing table or optionally, a user table to determine where a given request should be forwarded. When a request is received by a redirect agent, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact directly. * add the following enumerated value in section 6.12: ALL_USER 6 All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP. From owner-aaa-wg@merit.edu Wed Feb 20 19:09:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24346 for ; Wed, 20 Feb 2002 19:09:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7396491224; Wed, 20 Feb 2002 19:09:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D6E0912B9; Wed, 20 Feb 2002 19:09:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 519C091224 for ; Wed, 20 Feb 2002 19:09:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id D677A5DDAE; Wed, 20 Feb 2002 19:09:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 5ED265DDAB for ; Wed, 20 Feb 2002 19:09:12 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1L09QQ28689 for ; Wed, 20 Feb 2002 18:09:26 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 20 Feb 2002 18:09:11 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Feb 2002 18:09:10 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Request for closure on issue 235 Date: Wed, 20 Feb 2002 18:09:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12763@daebe007.NOE.Nokia.com> Thread-Topic: Request for closure on issue 235 Thread-Index: AcG6a9cWlJHPKyYWEdaxoAAAhj/HZA== From: To: X-OriginalArrivalTime: 21 Feb 2002 00:09:10.0995 (UTC) FILETIME=[FCE0EA30:01C1BA6B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA24346 Hello, Issue 235 was discussed at IETF52 and is still open and needs to be closed. I have not seen any negative views on adding the "D" bit as part of the base specification. The "D" bit indicates potential duplicates of accounting messages. The "D" bit provides performance enhancement w.r.t the process of checking for duplicate records. While other mechanisms such as post-processing and brute force (check every record against every other record) are possible, having the "D" bit would make the nodes that process these records only check for those records that are marked as potential duplicates. So the "D" bit can be treated as an optional mechanism for implementations that would prefer to do duplicate checking based on this flag. Resolution on this issue would be one step closer to getting the base Diameter spec out as PS. -Basavaraj The details of the issue and change requested are as follows: ---------------------------------------------------------------- Issue 235: Enabling efficient accounting record uniqueness checking Submitter name: Basavaraj Patil Submitter email address: Basavaraj.Patil@nokia.com Date first submitted: November 9, 2001 Reference: Document: Base-08 Comment type: T Priority: 1 Section: 3.0, 9.4 Rationale/Explanation of issue: See below Requested change: ================= In section 3.0 Diameter Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ would be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E D r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. would get one new flag bit 'D': E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. (possibly) D(uplicated) - This bit is defined only for Accounting Requests, sent by a Diameter node or proxy. If set, the message is possibly a duplicate, and must be later checked by a recipient node if it really is a duplicate. If sending a message for first time, this bit MUST be cleared. This bit MUST NOT be set if an answer message (about e.g. a protocol error) has been got for an earlier similar message. It can be used only in cases where no answer has been got from the primary agent for a message and the message is sent again (e.g. due to a failover, to an alternate agent or to a recovered primary peer node). r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. and in section 9.4 Fault Resilience ==================================== ... Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. the above paragraph would get one sentence to its end: The inspection MUST be performed at least for such records that arrived at the Diameter peer specifically in accounting messages which have the 'D' bit set. Rationale/Explanation of issue: =============================== If a Diameter server does not have any indicator in the received Accounting Requests for the message being potentially duplicated, the Diameter server (or a separate Accounting System) would have to do a vast amount of unnecessary work just for the Accounting Request uniqueness checking. With more and more "hot billing" systems and prepaid billing for packet data becoming prevalent it becomes a requirement for accounting messages (records) to be sent far more frequently and also enabling speedy evaluation for accuracy and uniqueness. For accounting, the section 9.4 (Fault Resilence) defines that duplication detection must be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. The current draft text assumes that every accounting message would be cross-checked with these identifiers against the others, to detect duplicate accounting messages. However it is far more efficient to o first check if the Accounting Request sender has flagged the message to be a potential duplicate. (Duplicate messages may be generated in the exceptional cases when a communication link between Diameter peers goes down. This could happen due to the sending node failure or the receiving node failure or the communication link itself failing. e.g. physically damaged. When the sending node is redirecting the traffic to an alternate peer or able to communicate again after a temporary link failure to the primary peer, it may send again messages that have not yet been acknowledged by a recipient node.) Duplicates are generated very seldom. (Typically just a few packets, for eg. after a link failure case.) Therefore duplicate checking all-against-all, by seems a processing intensive work and one that is unnecessary to be performed by accounting servers (by the Diameter server or a billing system). The 'D' bit would be for all such accounting requests that were pending an application layer ack when the connection went down, whether they are resent on a connection to the same peer or an alternate peer. In failover scenarios, duplicate checking may not necessarily be done in the Diameter Server. It may alternatively be done in a billing engine. In that case the billing engine should get the 'D' bit information from the Diameter header, as delivered together with the payload. (It should be noted that the potentially duplicated accounting message may arrive earlier at the end system than a non-marked original accounting message. This is the case with any duplicate occurrence scenario, but is not a problem as the end system should anyway have some time buffer, e.g. 24h or 12h, for the received accounting records to be checked for duplicates.) The scheme proposed here does does not limit the Diameter Server or billing engine to do the uniqueness checking in any other way. (eg. all accounting records checked against each other, by the long AVP pair octet strings). From owner-aaa-wg@merit.edu Thu Feb 21 02:57:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10418 for ; Thu, 21 Feb 2002 02:57:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 72A3491259; Thu, 21 Feb 2002 02:57:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3A5119125C; Thu, 21 Feb 2002 02:57:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD47E91259 for ; Thu, 21 Feb 2002 02:57:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB5CE5DDE1; Thu, 21 Feb 2002 02:56:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 2B1325DD96 for ; Thu, 21 Feb 2002 02:56:43 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1L7uVZ28170 for ; Thu, 21 Feb 2002 09:56:31 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Feb 2002 09:56:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 09:56:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Thu, 21 Feb 2002 09:56:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64995@esebe004.NOE.Nokia.com> Thread-Topic: Request for closure on issue 235 Thread-Index: AcG6a9cWlJHPKyYWEdaxoAAAhj/HZAAQTWLw From: To: , X-OriginalArrivalTime: 21 Feb 2002 07:56:23.0595 (UTC) FILETIME=[419C37B0:01C1BAAD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10418 Hi Basavaraj, The editors have discussed this issue, and have some possitive feeling towards this. I believe that Jari Arkko was giving this a close examination and should shortly send some comments to the list. thanks, John > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) > Sent: 21 February, 2002 02:09 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Request for closure on issue 235 > > > > Hello, > > Issue 235 was discussed at IETF52 and is still open and needs to be > closed. I have not seen any negative views on adding the "D" bit as > part of the base specification. The "D" bit indicates potential > duplicates of accounting messages. > > The "D" bit provides performance enhancement w.r.t the process of > checking for duplicate records. While other mechanisms such as > post-processing and brute force (check every record against every > other record) are possible, having the "D" bit would make the nodes > that process these records only check for those records that are > marked as potential duplicates. So the "D" bit can be treated as an > optional mechanism for implementations that would prefer to do > duplicate checking based on this flag. > > Resolution on this issue would be one step closer to getting the base > Diameter spec out as PS. > > -Basavaraj > > The details of the issue and change requested are as follows: > > ---------------------------------------------------------------- > > Issue 235: Enabling efficient accounting record uniqueness checking > Submitter name: Basavaraj Patil > Submitter email address: Basavaraj.Patil@nokia.com > Date first submitted: November 9, 2001 > Reference: > Document: Base-08 > Comment type: T > Priority: 1 > Section: 3.0, 9.4 > Rationale/Explanation of issue: See below > > Requested change: > ================= > In section 3.0 Diameter Header > > ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E r r r r r| Command-Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > would be: > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E D r r r r| Command-Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > and > > E(rror) - If set, the message contains a protocol error, > and the message will not conform to the ABNF > described for this command. Messages with the > 'E' bit set is commonly referred to as an error > message. This bit MUST NOT be set in request > messages. See section 7.2. > r(eserved) - these flag bits are reserved for > future use, and > MUST be set to zero, otherwise an error MUST be > sent to the sender. > > would get one new flag bit 'D': > > E(rror) - If set, the message contains a protocol error, > and the message will not conform to the ABNF > described for this command. Messages with the > 'E' bit set is commonly referred to as an error > message. This bit MUST NOT be set in request > messages. See section 7.2. > (possibly) D(uplicated) > - This bit is defined only for > Accounting Requests, > sent by a Diameter node or proxy. > If set, the message is possibly a duplicate, > and must be later checked by a recipient node > if it really is a duplicate. If sending a > message for first time, this bit MUST be > cleared. > This bit MUST NOT be set if an answer message > (about e.g. a protocol error) has been got for > an earlier similar message. It can be used only > in cases where no answer has been got from the > primary agent for a message and the message is > sent again (e.g. due to a failover, to an > alternate agent or to a recovered primary peer > node). > r(eserved) - these flag bits are reserved for > future use, and > MUST be set to zero, otherwise an error MUST be > sent to the sender. > > and in section 9.4 Fault Resilience > ==================================== > ... > Diameter peers acting as clients MUST implement the use of failover > to guard against server failures and certain network failures. > Diameter peers acting as agents or related off-line processing > systems MUST detect duplicate accounting records caused by the > sending of same record to several servers and duplication > of messages in transit. This detection MUST be based on the > inspection of the Session-Id and Accounting-Record-Number > AVP pairs. > > the above paragraph would get one sentence to its end: > > The inspection MUST be performed at least for such records > that arrived at the Diameter peer specifically in accounting > messages which have the 'D' bit set. > > Rationale/Explanation of issue: > =============================== > > If a Diameter server does not have any indicator in the received > Accounting Requests for the message being potentially duplicated, > the Diameter server (or a separate Accounting System) would have > to do a vast amount of unnecessary work just for the Accounting > Request uniqueness checking. > With more and more "hot billing" systems and prepaid billing for > packet data becoming prevalent it becomes a requirement for accounting > messages (records) to be sent far more frequently and also enabling > speedy evaluation for accuracy and uniqueness. > > For accounting, the section 9.4 (Fault Resilence) defines that > duplication detection must be based on the inspection of the > Session-Id and Accounting-Record-Number AVP pairs. The current draft > text assumes that every accounting message would be cross-checked with > these identifiers against the others, to detect duplicate accounting > messages. > > However it is far more efficient to o first check if the Accounting > Request sender has flagged the message to be a potential duplicate. > > (Duplicate messages may be generated in the exceptional cases when a > communication link between Diameter peers goes down. This could happen > due to the sending node failure or the receiving node failure or the > communication link itself failing. e.g. physically damaged. When the > sending node is redirecting the traffic to an alternate peer or able > to communicate again after a temporary link failure to the primary > peer, it may send again messages that have not yet been acknowledged > by a recipient node.) > > Duplicates are generated very seldom. (Typically just a few packets, > for eg. after a link failure case.) Therefore duplicate checking > all-against-all, by seems a processing intensive work and one that is > unnecessary to be performed by accounting servers (by the Diameter > server or a billing system). > > The 'D' bit would be for all such accounting requests that were > pending an application layer ack when the connection went down, > whether they are resent on a connection to the same peer or an > alternate peer. > > In failover scenarios, duplicate checking may not necessarily be done > in the Diameter Server. It may alternatively be done in a billing > engine. In that case the billing engine should get the 'D' bit > information from the Diameter header, as delivered together with the > payload. > > (It should be noted that the potentially duplicated accounting message > may arrive earlier at the end system than a non-marked original > accounting message. This is the case with any duplicate occurrence > scenario, but is not a problem as the end system should anyway have > some time buffer, e.g. 24h or 12h, for the received accounting records > to be checked for duplicates.) > > The scheme proposed here does does not limit the Diameter Server or > billing engine to do the uniqueness checking in any other > way. (eg. all accounting records checked against each other, by the > long AVP pair octet strings). > From owner-aaa-wg@merit.edu Thu Feb 21 04:15:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11538 for ; Thu, 21 Feb 2002 04:15:35 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 640039125C; Thu, 21 Feb 2002 04:15:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D74F9912B9; Thu, 21 Feb 2002 04:15:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F5B39125C for ; Thu, 21 Feb 2002 04:15:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3AB165DD9E; Thu, 21 Feb 2002 04:15:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 4D8DC5DD96 for ; Thu, 21 Feb 2002 04:15:06 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1L9FYi13555 for ; Thu, 21 Feb 2002 11:15:34 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Feb 2002 11:15:05 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 11:15:05 +0200 Received: from essrv103nok148119.ntc.nokia.com ([172.21.148.119]) by esebe013.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Feb 2002 11:15:04 +0200 Subject: [AAA-WG]: Few nits in diameter base-08 From: Aki Niemi To: aaa-wg@merit.edu Cc: john.loughney@nokia.com In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64987@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64987@esebe004.NOE.Nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 21 Feb 2002 12:14:53 +0200 Message-Id: <1014286493.1042.75.camel@essrv103nok148119.ntc.nokia.com> Mime-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2002 09:15:04.0851 (UTC) FILETIME=[3FB2B630:01C1BAB8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was reading through the diameter base protocol -08, and found some nits: - page 81: Chapter 8.0, first sentence "Diameter can provide two different type of ..." s/type/types - page 81: Chapter 8.0, third paragraph "The Auth-Grace-Period AVP contains ... the server will release an state information ..." s/an/all - page 82: first sentence, second line from top "... implies the maximum length the session ..." s/length/length of - page 82: Chapter 8.1, first paragraph, third line "...implementations that makes use ..." s/makes/make - page 102: Chapter 9.5, third paragraph, 6th line "When the initial Accounting-Request is sent for a given session is sent, ..." get rid of the first "is sent" Cheers, Aki From owner-aaa-wg@merit.edu Thu Feb 21 04:20:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11636 for ; Thu, 21 Feb 2002 04:20:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 83F67912B9; Thu, 21 Feb 2002 04:19:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59B45912BA; Thu, 21 Feb 2002 04:19:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DD0B912B9 for ; Thu, 21 Feb 2002 04:19:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA9F55DD9E; Thu, 21 Feb 2002 04:19:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 097B55DD96 for ; Thu, 21 Feb 2002 04:19:51 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1L9KJi16088 for ; Thu, 21 Feb 2002 11:20:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Feb 2002 11:19:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 11:19:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: Few nits in diameter base-08 Date: Thu, 21 Feb 2002 11:19:49 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649A4@esebe004.NOE.Nokia.com> Thread-Topic: Few nits in diameter base-08 Thread-Index: AcG6uEHpAKy3oOupQeGxOXhljEnq3QAAJxmQ From: To: , X-OriginalArrivalTime: 21 Feb 2002 09:19:49.0970 (UTC) FILETIME=[E9A46B20:01C1BAB8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA11636 Hi Aki, Thanks for the nits - I've correct these now. John > -----Original Message----- > From: Niemi Aki (NET/Espoo) > Sent: 21 February, 2002 12:15 > To: aaa-wg@merit.edu > Cc: Loughney John (NRC/Helsinki) > Subject: Few nits in diameter base-08 > > > Hi, > > I was reading through the diameter base protocol -08, and found some > nits: > > - page 81: Chapter 8.0, first sentence "Diameter can provide two > different type of ..." s/type/types > > - page 81: Chapter 8.0, third paragraph "The Auth-Grace-Period AVP > contains ... the server will release an state information > ..." s/an/all > > - page 82: first sentence, second line from top "... implies > the maximum > length the session ..." s/length/length of > > - page 82: Chapter 8.1, first paragraph, third line > "...implementations > that makes use ..." s/makes/make > > - page 102: Chapter 9.5, third paragraph, 6th line "When the initial > Accounting-Request is sent for a given session is sent, ..." > get rid of > the first "is sent" > > Cheers, > Aki > > > From owner-aaa-wg@merit.edu Thu Feb 21 04:21:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11667 for ; Thu, 21 Feb 2002 04:21:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8CB53912BA; Thu, 21 Feb 2002 04:21:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 564CC912BB; Thu, 21 Feb 2002 04:21:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48418912BA for ; Thu, 21 Feb 2002 04:20:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E6D05DD9E; Thu, 21 Feb 2002 04:20:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id 7F7CF5DD96 for ; Thu, 21 Feb 2002 04:20:58 -0500 (EST) Received: from jariws1 ([62.248.146.116]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020221092056.FUR20888.fep01-app.kolumbus.fi@jariws1>; Thu, 21 Feb 2002 11:20:56 +0200 Message-ID: <015401c1bab9$1c3165c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Berry, Nigel Howard (Nigel)" , , References: <475FF955A05DD411980D00508B6D5FB003D34DDB@en0033exch001u.uk.lucent.com> Subject: Re: [AAA-WG]: ISSUE: redirect based on user names Date: Thu, 21 Feb 2002 10:11:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As I understand this, this would make the client store a record for that particular user name until max-cache-time, even beyond the user's session. Kevin, can you explain why ALL_SESSION is not sufficient for this, as it would have a more bounded cache memory requirements? Jari ----- Original Message ----- From: "Berry, Nigel Howard (Nigel)" To: Sent: 20. helmikuuta 2002 19:20 Subject: [AAA-WG]: ISSUE: redirect based on user names > Hi Kevin, > > This extra optionality could be very useful. There may a bit more > complexity required in the redirect agent but not withstanding this I would > like to support the addition of this extra functionality, > > Regards, > Nigel > > > ** included from original e-mail *** > Submitter name: Kevin Purser > Submitter email address: kevin.purser@ericsson.com > Date first submitted: February 14th, 2002 > Reference: none > Document: base-08alpha02 > Comment type: Technical > Priority: 1 > Sections: 2.9.3, 6.12 > Rationale/Explanation of issue: > > Diameter redirect agents currently provide realm to server address > resolution. Within a single administrative domain, it could be useful to > allow redirect agents to have the option of providing user to server address > resolution. > > Requested change: > > * change the first paragraph of section 2.9.3 to read: > > Redirect agents provide Realm to Server address resolution and MAY also > provide User to Server address resolution. These redirect agents would make > use of the Diameter routing table or optionally, a user table to determine > where a given request should be forwarded. When a request is received by a > redirect agent, a special answer is created, which includes the identity of > the Diameter server(s) the originator of the request should contact > directly. > > * add the following enumerated value in section 6.12: > > ALL_USER 6 > All messages for the user requested MAY be sent to the > host specified in the Redirect-Host AVP. > > > > From owner-aaa-wg@merit.edu Thu Feb 21 04:55:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12259 for ; Thu, 21 Feb 2002 04:55:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59154912BB; Thu, 21 Feb 2002 04:55:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26A08912BC; Thu, 21 Feb 2002 04:55:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0862B912BB for ; Thu, 21 Feb 2002 04:55:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C96285DE09; Thu, 21 Feb 2002 04:55:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id CF51A5DD96 for ; Thu, 21 Feb 2002 04:54:59 -0500 (EST) Received: from jariws1 ([62.248.146.116]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.15 201-253-122-118-115-20011108) with SMTP id <20020221095458.TLR20888.fep01-app.kolumbus.fi@jariws1>; Thu, 21 Feb 2002 11:54:58 +0200 Message-ID: <01d201c1babd$ddd20b40$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Fredrik Johansson" , "Tony Johansson" , References: Subject: Re: [AAA-WG]: Accouting AVP issue... Date: Thu, 21 Feb 2002 11:55:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > sounds good to me, Yes. This should be sufficient, and we can make the AVPs optional in the base. As Base 2.3.3 states, Diameter extensions MUST also specify the AVPs that are to be present in the Diameter Accounting messages. This means that individual apps can be pick and choose the AVPs they need. > btw. why Extended, can't it just be Accounting-Output-Octets... Desire to avoid a conflict with a similarly (but not exactly) named RADIUS attribute that has different contents? Acct-Output-Octets, 32 bits. Jari From owner-aaa-wg@merit.edu Thu Feb 21 06:01:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13062 for ; Thu, 21 Feb 2002 06:01:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 492AF912BC; Thu, 21 Feb 2002 06:01:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A39B3912BD; Thu, 21 Feb 2002 06:01:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAF78912BC for ; Thu, 21 Feb 2002 06:01:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 857A45DDFE; Thu, 21 Feb 2002 06:01:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 22B025DDBB for ; Thu, 21 Feb 2002 06:01:08 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1LB1GZ20550 for ; Thu, 21 Feb 2002 13:01:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 21 Feb 2002 13:01:06 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Feb 2002 13:01:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE: redirect based on user names Date: Thu, 21 Feb 2002 13:01:05 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649B2@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE: redirect based on user names Thread-Index: AcG6vGLPTf2iv6NbQ36qi3lK283AoAACpd5w From: To: , , X-OriginalArrivalTime: 21 Feb 2002 11:01:06.0431 (UTC) FILETIME=[0F7EC8F0:01C1BAC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA13062 Hi Jari, > As I understand this, this would make the client store a > record for that > particular user name until max-cache-time, even beyond the user's > session. Kevin, can you explain why ALL_SESSION is not sufficient > for this, as it would have a more bounded cache memory requirements? That is good point. Kevin, could you provide extra justification for this? John From owner-aaa-wg@merit.edu Thu Feb 21 07:00:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13814 for ; Thu, 21 Feb 2002 07:00:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9BEFC912BE; Thu, 21 Feb 2002 06:59:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65808912BF; Thu, 21 Feb 2002 06:59:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47390912BE for ; Thu, 21 Feb 2002 06:59:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29FC25DE0C; Thu, 21 Feb 2002 06:59:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id F20355DDBB for ; Thu, 21 Feb 2002 06:59:46 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1LBxiB22518 for ; Thu, 21 Feb 2002 12:59:44 +0100 (MET) Received: FROM esealnt745.al.sw.ericsson.se BY esealnt461 ; Thu Feb 21 12:58:44 2002 +0100 Received: by ESEALNT745.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Feb 2002 12:59:40 +0100 Message-ID: <577066326047D41180AC00508B955DDA06C450F1@eestqnt104.es.eu.ericsson.se> From: "Carolina Canales Valenzuela (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Kevin Purser (EUS)" , "Tony Johansson (EUS)" , "'Jari Arkko'" Subject: RE: [AAA-WG]: ISSUE: redirect based on user names Date: Thu, 21 Feb 2002 12:53:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Jari, as far as I understand the issue, the client would store a record with the name of the server sent in the Redirect-Host AVP. Like this, the client will know that the rest of the messages related with that user, independently on whether the session is maintained or not, should be sent to the server stored. I think that ALL_SESSION is not valid because sometimes the session might not be maintained, but even in that case, as the messages belong to the same user, they must go to the same server (this is the new added functionality that is required). The rest of the defined values in section 6.12 are not valid either. I don't know if this is an answer to your question, or I misunderstood it.... BR, Carolina >-----Original Message----- >From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] >Sent: Thursday, February 21, 2002 9:11 AM >To: Berry, Nigel Howard (Nigel); aaa-wg@merit.edu; >kevin.purser@ericsson.com >Subject: Re: [AAA-WG]: ISSUE: redirect based on user names > > >As I understand this, this would make the client store a >record for that >particular user name until max-cache-time, even beyond the user's >session. Kevin, can you explain why ALL_SESSION is not sufficient >for this, as it would have a more bounded cache memory requirements? > >Jari > >----- Original Message ----- >From: "Berry, Nigel Howard (Nigel)" >To: >Sent: 20. helmikuuta 2002 19:20 >Subject: [AAA-WG]: ISSUE: redirect based on user names > > >> Hi Kevin, >> >> This extra optionality could be very useful. There may a bit more >> complexity required in the redirect agent but not >withstanding this I would >> like to support the addition of this extra functionality, >> >> Regards, >> Nigel >> >> >> ** included from original e-mail *** >> Submitter name: Kevin Purser >> Submitter email address: kevin.purser@ericsson.com >> Date first submitted: February 14th, 2002 >> Reference: none >> Document: base-08alpha02 >> Comment type: Technical >> Priority: 1 >> Sections: 2.9.3, 6.12 >> Rationale/Explanation of issue: >> >> Diameter redirect agents currently provide realm to server address >> resolution. Within a single administrative domain, it could >be useful to >> allow redirect agents to have the option of providing user >to server address >> resolution. >> >> Requested change: >> >> * change the first paragraph of section 2.9.3 to read: >> >> Redirect agents provide Realm to Server address resolution >and MAY also >> provide User to Server address resolution. These redirect >agents would make >> use of the Diameter routing table or optionally, a user >table to determine >> where a given request should be forwarded. When a request is >received by a >> redirect agent, a special answer is created, which includes >the identity of >> the Diameter server(s) the originator of the request should contact >> directly. >> >> * add the following enumerated value in section 6.12: >> >> ALL_USER 6 >> All messages for the user requested MAY be sent to the >> host specified in the Redirect-Host AVP. >> >> >> >> > > > From owner-aaa-wg@merit.edu Thu Feb 21 08:32:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16487 for ; Thu, 21 Feb 2002 08:32:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BDBC29121A; Thu, 21 Feb 2002 08:31:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 899A391249; Thu, 21 Feb 2002 08:31:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8365E9121A for ; Thu, 21 Feb 2002 08:31:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FC075DE0D; Thu, 21 Feb 2002 08:31:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 4AFEA5DDBB for ; Thu, 21 Feb 2002 08:31:44 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 1631279; Thu, 21 Feb 2002 08:31:44 -0500 (EST) From: "Bob Kopacz" To: "Fredrik Johansson" , "Tony Johansson" , Subject: RE: [AAA-WG]: Accouting AVP issue... Date: Thu, 21 Feb 2002 08:30:56 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Frederick > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Fredrik Johansson > Sent: Wednesday, February 20, 2002 4:07 AM > To: Tony Johansson; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Accouting AVP issue... > > > sounds good to me, > btw. why Extended, can't it just be Accounting-Output-Octets... I had something to do with this. See issue#182. Basically, a while back these attributes had numbers in the RADIUS attribute space, they were the same as RADIUS attributes Acct-Input-Octets et al, but had 64-bit values rather than 32-bit value. I asked that these AVPs be assigned Diameter AVP codes, and given names different from the RADIUS dictionary names for the corresponding attributes. I tossed out "extended" as an indication that their precision was greater. However, the RADIUS attributes are named "Acct-...", while the corresponding Diameter ones are named "Accounting-...". Since the Diameter ones have a different name, I don't have any complaints if the "-Extended" is removed from the name, as it certainly isn't obvious what "extended" means. Bob K. > /Fredrik > From owner-aaa-wg@merit.edu Thu Feb 21 08:48:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16917 for ; Thu, 21 Feb 2002 08:48:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 669E191249; Thu, 21 Feb 2002 08:47:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D4F7912C2; Thu, 21 Feb 2002 08:47:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C28D391249 for ; Thu, 21 Feb 2002 08:47:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9916A5DDFF; Thu, 21 Feb 2002 08:47:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id EE2FA5DDF4 for ; Thu, 21 Feb 2002 08:47:51 -0500 (EST) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA07165; Thu, 21 Feb 2002 14:45:14 +0100 From: "Fredrik Johansson" To: "Bob Kopacz" , "Tony Johansson" , Subject: RE: [AAA-WG]: Accouting AVP issue... Date: Thu, 21 Feb 2002 14:47:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, It was just for curiosity that I asked. I have no problem with them beeing called somehting Extended /Fredrik >-----Original Message----- >From: Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] >Sent: den 21 februari 2002 14:31 >To: Fredrik Johansson; Tony Johansson; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Accouting AVP issue... > > >Hi Frederick > >> -----Original Message----- >> From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of >> Fredrik Johansson >> Sent: Wednesday, February 20, 2002 4:07 AM >> To: Tony Johansson; aaa-wg@merit.edu >> Subject: RE: [AAA-WG]: Accouting AVP issue... >> >> >> sounds good to me, >> btw. why Extended, can't it just be Accounting-Output-Octets... > >I had something to do with this. See issue#182. > >Basically, a while back these attributes had numbers in the >RADIUS attribute space, they were the same as RADIUS attributes >Acct-Input-Octets et al, but had 64-bit values rather than 32-bit >value. > >I asked that these AVPs be assigned Diameter AVP codes, and given >names different from the RADIUS dictionary names for the corresponding >attributes. I tossed out "extended" as an indication that their >precision was greater. > >However, the RADIUS attributes are named "Acct-...", while the >corresponding >Diameter ones are named "Accounting-...". > >Since the Diameter ones have a different name, I don't have any complaints >if the "-Extended" is removed from the name, as it certainly isn't obvious >what "extended" means. > >Bob K. > > >> /Fredrik >> From owner-aaa-wg@merit.edu Thu Feb 21 08:58:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17361 for ; Thu, 21 Feb 2002 08:58:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9760912C2; Thu, 21 Feb 2002 08:58:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 80CC8912C3; Thu, 21 Feb 2002 08:58:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72EC8912C2 for ; Thu, 21 Feb 2002 08:58:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B3D375DE02; Thu, 21 Feb 2002 08:57:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A0D455DDF4 for ; Thu, 21 Feb 2002 08:57:55 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6637C79; Thu, 21 Feb 2002 08:57:40 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: Mobile-IP accounting -- 3 thoughts Date: Thu, 21 Feb 2002 08:56:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's a few Mobile-IP accounting thoughts. I don't feel strongly enough about them to submit as issues, but I will do so if anyone thinks they are "issue-worthy". 1. The MIP-Feature-Vector is disallowed in AMA and HAA answer messages. Maybe the MIP-Feature-Vector should be returned in answer messages, for a couple of reasons: (a) The MIP-Feature-Vector is required in Mobile IP accounting messages. However the value which the FA originates in his AMR may be modified by the AAAF, so the HA sees a different value. Then accounting messages sent by the FA and HA for the same session will reflect different values for the MIP-Feature-Vector. (b) Perhaps in the future, more bits may be added to the MIP-Feature-Vector so that the AAAH or HA can use the MIP-Feature-Vector to pass information. Or maybe a new bit is set by the AAAF that the FA needs to know about. If so, then returning the MIP-Feature-Vector in answer messages makes sure this information is conveyed to all parties. 2. Both the NASREQ draft and the Mobile-IP draft require, in their AVP occurrence rules, that the following AVPs be present in an Accounting Request message: Accounting-Input-Extended-Octets Accounting-Input-Extended-Packets Accounting-Output-Extended-Octets Accounting-Output-Extended-Packets Accounting-Session-Time (= duration, in seconds) In the case of an Accounting-Start, these values are all zero. Are these AVP supposed to be required (with zero values) in this case, or is this just an oversight when putting together the occurrence rules? 3. The only AVP that conveys time information is the Accounting-Session-Time, which indicates the session's duration, in seconds. So the server timestamps a received accounting message with the server's notion of current time. When processing accounting messages, the session start time would be calculated by subtracting the duration from the time the message was received. This means the session's calculated start time can vary message-to-message for the same session. This also means that accounting messages convey no notion of the access device's time. Should originators of accounting messages convey a session start time and a current-time in some new AVPs? Bob K. From owner-aaa-wg@merit.edu Thu Feb 21 09:35:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18495 for ; Thu, 21 Feb 2002 09:35:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5F2E7912C5; Thu, 21 Feb 2002 09:34:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EAAE912C6; Thu, 21 Feb 2002 09:34:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18AA3912C5 for ; Thu, 21 Feb 2002 09:34:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id E90615DE03; Thu, 21 Feb 2002 09:34:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 274215DDB2 for ; Thu, 21 Feb 2002 09:34:28 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020221143415.JAYY9552.fep02-svc.swip.net@ipunplugged.com>; Thu, 21 Feb 2002 15:34:15 +0100 Message-ID: <3C751398.3080000@ipunplugged.com> Date: Thu, 21 Feb 2002 15:34:48 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: Tony Johansson , aaa-wg Subject: Re: [AAA-WG]: Mobile-IP accounting -- 3 thoughts References: 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 Bob Kopacz wrote: >3. The only AVP that conveys time information is the >Accounting-Session-Time, which indicates the session's duration, in >seconds. So the server timestamps a received accounting message with >the server's notion of current time. When processing accounting >messages, the session start time would be calculated by subtracting >the duration from the time the message was received. This means the >session's calculated start time can vary message-to-message for the >same session. This also means that accounting messages convey no >notion of the access device's time. Should originators of accounting >messages convey a session start time and a current-time in some new >AVPs? > We've been wondering about the same thing. One possible explanation why there is no way for the access device's time to be carried could be that the requirement for Diameter is real-time accounting and batch accounting is explicitly unsupported, and so there *should* be no significant differences, but I'm just guessing here. I think it would be nice but not essential to be able to pass the time to the server. j From owner-aaa-wg@merit.edu Thu Feb 21 10:34:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20627 for ; Thu, 21 Feb 2002 10:34:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 48E139121D; Thu, 21 Feb 2002 10:34:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF540912C7; Thu, 21 Feb 2002 10:34:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCAB79121D for ; Thu, 21 Feb 2002 10:34:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 96E235DE03; Thu, 21 Feb 2002 10:34:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id F203B5DD9E for ; Thu, 21 Feb 2002 10:34:19 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep03-svc.swip.net with ESMTP id <20020221153412.KELI22198.fep03-svc.swip.net@ipunplugged.com>; Thu, 21 Feb 2002 16:34:12 +0100 Message-ID: <3C7521A3.5080507@ipunplugged.com> Date: Thu, 21 Feb 2002 16:34:43 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Mobile-IP accounting -- 3 thoughts References: <3C751398.3080000@ipunplugged.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 Johan Johansson wrote: > Bob Kopacz wrote: > >> 3. The only AVP that conveys time information is the >> Accounting-Session-Time, which indicates the session's duration, in >> seconds. So the server timestamps a received accounting message with >> the server's notion of current time. When processing accounting >> messages, the session start time would be calculated by subtracting >> the duration from the time the message was received. This means the >> session's calculated start time can vary message-to-message for the >> same session. This also means that accounting messages convey no >> notion of the access device's time. Should originators of accounting >> messages convey a session start time and a current-time in some new >> AVPs? >> > We've been wondering about the same thing. One possible explanation > why there is no way for the access device's time to be carried could > be that the requirement for Diameter is real-time accounting and batch > accounting is explicitly unsupported, and so there *should* be no > significant differences, but I'm just guessing here. I think it would > be nice but not essential to be able to pass the time to the server. A clarification: the timestamp would be useful in the case mentioned in the base draft (9.4): Upon a reboot, the client MUST starting sending the records in the non-volatile memory to the accounting server with appropriate modifications in termination cause, session length, and other relevant information in the records. j From owner-aaa-wg@merit.edu Thu Feb 21 13:18:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27673 for ; Thu, 21 Feb 2002 13:18:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A3FA8912CA; Thu, 21 Feb 2002 13:17:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63582912CB; Thu, 21 Feb 2002 13:17:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 898B7912CA for ; Thu, 21 Feb 2002 13:17:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B3AA5DDBE; Thu, 21 Feb 2002 13:17:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 132095DDB1 for ; Thu, 21 Feb 2002 13:17:27 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R99J>; Thu, 21 Feb 2002 10:17:25 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Tony Johansson'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Accouting AVP issue... Date: Thu, 21 Feb 2002 10:17:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB03.FE99C1B0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB03.FE99C1B0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A few revisions ago, the base included the accounting AVPs. An issue was created by Glen Zorn, and with WG concensus the AVPs were moved to the application specs. If we want to now go back in time, we should go back and understand the original reasoning for moving the AVPs to the application specs. PatC - -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Tuesday, February 19, 2002 11:27 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Accouting AVP issue... All, In my efforts to update the Diameter MIPv4 application I have stumble on the Accounting AVPs defined and realized that exactly the same AVPs are defined also in the NASREQ application, see below. Unless I have misunderstood something, I would suggest that we move these AVPs to the Base, since they are used by both NASREQ and MIP. Regards, /Tony In MIP: "7.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. 7.2 Accounting-Output-Extended-Octets AVP The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type Unsigned64, and contains the number of octets in IP packets sent to the user. 7.3 Accounting-Session-Time AVP The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, and indicates the length of the current session in seconds. 7.4 Accounting-Input-Extended-Packets AVP The Accounting-Input-Extended-Packets (AVP Code 365) is of type Unsigned64, and contains the number of IP packets received from the user. 7.5 Accounting-Output-Extended-Packets AVP The Accounting-Output-Extended-Packets (AVP Code 366) is of type Unsigned64, and contains the number of IP packets sent to the user." In NASREQ: 8.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received by the user. 8.2 Accounting-Output-Extended-Octets AVP The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of type Unsigned64, and contains the number of octets in IP packets sent to the user. 8.3 Accounting-Session-Time AVP The Accounting-Session-Time AVP (AVP Code 46) is of type Unsigned32, and indicates the length of the current session in seconds. 8.4 Accounting-Input-Extended-Packets AVP The Accounting-Input-Extended-Packets (AVP Code 365) is of type Unsigned64, and contains the number of IP packets received by the user. 8.5 Accounting-Output-Extended-Packets AVP The Accounting-Output-Extended-Packets (AVP Code 366) is of type Unsigned64, and contains the number of IP packets sent to the user. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHU5rTN1fXKoxmisEQIduQCfTGlvh7AT0o4jQfl8xiad56pwwfEAoOrP zGhWH9Fs/wwmEj291svkxjoH =hmKz -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BB03.FE99C1B0 Content-Type: text/html RE: [AAA-WG]: Accouting AVP issue...

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A few revisions ago, the base included the accounting AVPs. An issue
was created by Glen Zorn, and with WG concensus the AVPs were moved
to the application specs.

If we want to now go back in time, we should go back and understand
the original reasoning for moving the AVPs to the application specs.

PatC

- -----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Tuesday, February 19, 2002 11:27 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Accouting AVP issue...


All,

In my efforts to update the Diameter MIPv4 application I have stumble
on the Accounting AVPs defined and realized that exactly the same
AVPs are defined also in the NASREQ application, see below.

Unless I have misunderstood something, I would suggest that we move
these AVPs to the Base, since they are used by both NASREQ and MIP.

Regards,

/Tony

In MIP:

"7.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets
received
   from the user.


7.2  Accounting-Output-Extended-Octets AVP

   The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of
type
   Unsigned64, and contains the number of octets in IP packets sent
to
   the user.


7.3  Accounting-Session-Time AVP

   The Accounting-Session-Time AVP (AVP Code 46) is of type
Unsigned32,
   and indicates the length of the current session in seconds.


7.4  Accounting-Input-Extended-Packets AVP

   The Accounting-Input-Extended-Packets (AVP Code 365) is of type
   Unsigned64, and contains the number of IP packets received from
the
   user.


7.5  Accounting-Output-Extended-Packets AVP

   The Accounting-Output-Extended-Packets (AVP Code 366) is of type
   Unsigned64, and contains the number of IP packets sent to the
user."

In NASREQ:

8.1  Accounting-Input-Extended-Octets AVP

   The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type
   Unsigned64, and contains the number of octets in IP packets
received
   by the user.


8.2  Accounting-Output-Extended-Octets AVP

   The Accounting-Output-Extended-Octets AVP (AVP Code 364) is of
type
   Unsigned64, and contains the number of octets in IP packets sent
to
   the user.


8.3  Accounting-Session-Time AVP

   The Accounting-Session-Time AVP (AVP Code 46) is of type
Unsigned32,
   and indicates the length of the current session in seconds.


8.4  Accounting-Input-Extended-Packets AVP

   The Accounting-Input-Extended-Packets (AVP Code 365) is of type
   Unsigned64, and contains the number of IP packets received by the
   user.


8.5  Accounting-Output-Extended-Packets AVP

   The Accounting-Output-Extended-Packets (AVP Code 366) is of type
   Unsigned64, and contains the number of IP packets sent to the
user.


-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPHU5rTN1fXKoxmisEQIduQCfTGlvh7AT0o4jQfl8xiad56pwwfEAoOrP
zGhWH9Fs/wwmEj291svkxjoH
=hmKz
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BB03.FE99C1B0-- From owner-aaa-wg@merit.edu Thu Feb 21 15:02:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01782 for ; Thu, 21 Feb 2002 15:02:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F241C91258; Thu, 21 Feb 2002 15:00:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BC56912CB; Thu, 21 Feb 2002 15:00:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C4FA91258 for ; Thu, 21 Feb 2002 15:00:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2DE755DE06; Thu, 21 Feb 2002 14:57:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id E07605DD9D for ; Thu, 21 Feb 2002 14:57:19 -0500 (EST) Subject: [AAA-WG]: Diameter CCA: Number of sessions per user To: aaa-wg@merit.edu Cc: harri.hakala@lmf.ericsson.se, stefan.karlsson@epk.ericsson.se X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Thu, 21 Feb 2002 18:11:55 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/21/2002 08:57:20 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi All, In the point 3.2 of the document 'Diameter Credit Control Application', is described the Service Credit Control using several interrogations (session control). When a session is opened (START_RECORD), the client ask for the server an amount of credit (stated in money, service units and so on....) which is reserved until the next request (ACR) of the multi-interrogations dialogue is received (INTERIM_RECORD or STOP_RECORD). When this new ACR is recived, a new amount of credit asked by the client is reserved. As described in the document this amount of credit 'reserved' for the user is stored in the server, so when the client finishes the dialogue (STOP_RECORD), the ACR includes the 'Used-Service-Units' AVP indicating the real amount of credit consumed since the previous interrogation. Then, the credit not consumed must be returned back to the user account, it means the money to return back is the 'reserved' credit minus the credit corrsponding to the 'Used-Service-Units'.... Is it OK? The question is: What happens when the user has serveral sessions opened at time? There is nothing about that in the document but I suppose that we can not establish limits for the number of sessions a user can have at time. A user could be downloading a document at the same time he is looking for the neares restaurant or buying the tickets for the last Swertzeneger film. I suppose the server must be able to identify which ACR corresponds to which session, however.... How could the server identify this session? Maybe I'm confused but I did not find neither an AVP able to identify it, nor a field corresponding to the Diameter Base protocol able to be used to identify the session (I understand the server cannot use neither the 'Hop-by-Hop' nor the 'End-to-End' identifier to associate that a received request corresponds to a specific session opened. This way, when a user has several sessions opened and receives a request (INTERIM_RECORD as an example) must be able to know which session must delete the stored credit and reserve a new credit again. I have been thinking about two solutions: 1.- Not to store the reserved credit in the server. The client could ask for the credit and receive it in the 'Granted-Service-Units' AVP, when the session is finished the client could send a different AVP called 'Remaining-Service-Units' instead of the 'Used-Service-Units' AVP. This way the session have not to be controlled by the server. This solution could have a problem, the fraud produced due to the lack of the session by the server. The server must trust the client, because the client could set the 'Remaining-Service-Units' AVP to a random value.... It could be difficult if the home domain receives request from clients from visited domains, a formal agreement must exists in this scenario to avoid fraud. 2.- Introduce in the request and answer the AVP called 'Session-ID' (code 263) to identify the session. This way the session is always identified for session oriented service control (several queries). In my humble oppinion, the second one is the best option to be able to solve this problem. regards, Paco. From owner-aaa-wg@merit.edu Thu Feb 21 16:48:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05390 for ; Thu, 21 Feb 2002 16:48:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E81129120C; Thu, 21 Feb 2002 16:46:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5F7F912CB; Thu, 21 Feb 2002 16:46:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62A829120C for ; Thu, 21 Feb 2002 16:46:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 437675DDC3; Thu, 21 Feb 2002 16:46:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id BBD355DD9D for ; Thu, 21 Feb 2002 16:46:51 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1LLkPS25222; Thu, 21 Feb 2002 15:46:25 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1LLkOh06819; Thu, 21 Feb 2002 15:46:24 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA13355; Thu, 21 Feb 2002 15:46:24 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA29620; Thu, 21 Feb 2002 15:46:23 -0600 (CST) Message-ID: <3C756A23.5D93740B@ericsson.com> Date: Thu, 21 Feb 2002 13:44:03 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: Mobile-IP accounting -- 3 thoughts References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Bob, Please, find comments embedded. BR, /Tony Bob Kopacz wrote: > Hi Tony, > > Here's a few Mobile-IP accounting thoughts. I don't feel strongly > enough about them to submit as issues, but I will do so if anyone > thinks they are "issue-worthy". > > 1. The MIP-Feature-Vector is disallowed in AMA and HAA answer > messages. > > Maybe the MIP-Feature-Vector should be returned in answer messages, > for a couple of reasons: > > (a) The MIP-Feature-Vector is required in Mobile IP accounting > messages. However the value which the FA originates in his AMR may > be modified by the AAAF, so the HA sees a different value. Then > accounting messages sent by the FA and HA for the same session will > reflect different values for the MIP-Feature-Vector. > > > (b) Perhaps in the future, more bits may be added to the > MIP-Feature-Vector so that the AAAH or HA can use the > MIP-Feature-Vector to pass information. > Or maybe a new bit is set by > the AAAF that the FA needs to know about. If so, then returning the > MIP-Feature-Vector in answer messages makes sure this information is > conveyed to all parties. To echo back the MIP-Feature-Vector in the AMA sound reasonable, so that we can grantee that the FA and the HA uses the same values. For HAA I'm not so sure. The main purpose of the MIP-Feature-Vector is to support the AAAH in how to authorize the MN (HA assignment, etc.). Why would we need to pass info from the HA to the AAAH? I may be wrong here but I don't see why we should allow the MIP-Feature-Vector in the HAA unless we see a good reason. Others, comments? > > > 2. Both the NASREQ draft and the Mobile-IP draft require, > in their AVP occurrence rules, that the following AVPs be > present in an Accounting Request message: > > Accounting-Input-Extended-Octets > Accounting-Input-Extended-Packets > Accounting-Output-Extended-Octets > Accounting-Output-Extended-Packets > Accounting-Session-Time (= duration, in seconds) > > In the case of an Accounting-Start, these values are all zero. > Are these AVP supposed to be required (with zero values) in this case, > or is this just an oversight when putting together the occurrence > rules? Good question, but I believe that they should be required. True, they are all zero, but instead of making exception the first time I would think it is better to always send them and not only in all interims. From owner-aaa-wg@merit.edu Thu Feb 21 17:16:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05951 for ; Thu, 21 Feb 2002 17:16:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1954F912CC; Thu, 21 Feb 2002 17:08:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0F61912D3; Thu, 21 Feb 2002 17:08:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 65B0D912CC for ; Thu, 21 Feb 2002 17:08:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A6225DE1D; Thu, 21 Feb 2002 17:08:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D6A8C5DDF5 for ; Thu, 21 Feb 2002 17:08:46 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1LM8kS04701 for ; Thu, 21 Feb 2002 16:08:46 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1LM8kh13650 for ; Thu, 21 Feb 2002 16:08:46 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA15534 for ; Thu, 21 Feb 2002 16:08:45 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA00057 for ; Thu, 21 Feb 2002 16:08:44 -0600 (CST) Message-ID: <3C756F5F.646DD4B3@ericsson.com> Date: Thu, 21 Feb 2002 14:06:24 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: ISSUE 250: ready for closure? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit All, Here is an update reference section with Normative and Informative sub sections. Comments / objections? /Tony ----------------------------------------------- 11.0 References 11.1 Normative [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt, IETF work in progress, November 2001. [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con­ siderations Section in RFCs", BCP 26, RFC 2434, October 1998 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 2002, Octo­ ber 1996. [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions". RFC 3012. November 2000. [NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. January 1999. [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in progress, November 2001. [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- Hashing for Message Authentication. RFC 2104, February 1997. [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in progress, July 2001. 11.2 Informative [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica­ tion, Authorization, and Accounting Requirements". RFC 2977. October 2000. [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro­ tocols", RFC 2477, January 1999. [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden­ tifier Extension", RFC 2794, March 2000. [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random­ ness Recommendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994. From owner-aaa-wg@merit.edu Thu Feb 21 17:33:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06276 for ; Thu, 21 Feb 2002 17:33:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 45E2B912CE; Thu, 21 Feb 2002 17:32:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 07158912CF; Thu, 21 Feb 2002 17:32:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87F6D912CE for ; Thu, 21 Feb 2002 17:32:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67EB55DE05; Thu, 21 Feb 2002 17:32:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 08C6C5DDF5 for ; Thu, 21 Feb 2002 17:32:44 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7R0JC>; Thu, 21 Feb 2002 14:32:39 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Tony Johansson'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: ISSUE 250: ready for closure? Date: Thu, 21 Feb 2002 14:32:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB27.A832E170" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BB27.A832E170 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Looks right to me PatC - -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Thursday, February 21, 2002 2:06 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: ISSUE 250: ready for closure? All, Here is an update reference section with Normative and Informative sub sections. Comments / objections? /Tony - ----------------------------------------------- 11.0 References 11.1 Normative [DIAMBASE] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter Base Protocol", draft-ietf-aaa-diameter-08.txt, IETF work in progress, November 2001. [IANA] Narten, Alvestrand,"Guidelines for Writing an IANA Con- siderations Section in RFCs", BCP 26, RFC 2434, October 1998 [MOBILEIP] C. Perkins, Editor. IP Mobility Support. RFC 2002, Octo- ber 1996. [MIPCHAL] C. Perkins, P. Calhoun, "Mobile IP Challenge/Response Extensions". RFC 3012. November 2000. [NAI] B. Aboba, M. Beadles "The Network Access Identifier." RFC 2486. January 1999. [CMS] P. Calhoun, W. Bulley, S. Farrell, "Diameter CMS Security Application", draft-ietf-aaa-diameter-cms-sec-03.txt, IETF work in progress, November 2001. [HMAC] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed- Hashing for Message Authentication. RFC 2104, February 1997. [MIPKEYS] C. Perkins, P. Calhoun, "AAA Registration Keys for Mobile IP", draft-ietf-mobileip-aaa-key-08.txt, IETF work in progress, July 2001. 11.2 Informative [MIPREQ] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentica- tion, Authorization, and Accounting Requirements". RFC 2977. October 2000. [CDMA2000] T. Hiller and al, "CDMA2000 Wireless Data Requirements for AAA", RFC 3141, June 2001. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [EVALROAM] B. Aboba, G. Zorn, "Criteria for Evaluating Roaming Pro- tocols", RFC 2477, January 1999. [MIPNAI] P. Calhoun, C. Perkins, "Mobile IP Network Address Iden- tifier Extension", RFC 2794, March 2000. [RANDOM] D. Eastlake, 3rd, S. Crocker, and J. Schiller. Random- ness Recommendations for Security. Request for Comments (Informational) 1750, Internet Engineering Task Force, December 1994. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHV1gjN1fXKoxmisEQIRQwCcDhNxbf3xMFQ8SqwtloMBZpsZe+8An37k QXvIOfmn3mXAwqi7AQIh+rnL =T06E -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BB27.A832E170 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: ISSUE 250: ready for closure?

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Looks right to me

PatC

- -----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericss= on.com]
Sent: Thursday, February 21, 2002 2:06 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: ISSUE 250: ready for = closure?


All,

Here is an update reference section with Normative = and Informative
sub sections.

Comments / objections?

/Tony

- = -----------------------------------------------

11.0 References

11.1 Normative

[DIAMBASE]     P. Calhoun, H. = Akhtar, J. Arkko, E. Guttman, A.
Rubens,
          &nb= sp;    "Diameter Base Protocol",
draft-ietf-aaa-diameter-08.txt,

          &nb= sp;    IETF work in progress, November 2001.

[IANA]         Narten, = Alvestrand,"Guidelines for Writing an IANA
Con­
          &nb= sp;    siderations Section in RFCs", BCP 26, RFC = 2434,
October
          &nb= sp;    1998

[MOBILEIP]     C. Perkins, = Editor. IP Mobility Support. RFC 2002,
Octo­
          &nb= sp;    ber 1996.

[MIPCHAL]      C. Perkins, = P. Calhoun, "Mobile IP Challenge/Response
          &nb= sp;    Extensions". RFC 3012. November 2000.

[NAI]          B. = Aboba, M. Beadles "The Network Access Identifier."
RFC

          &nb= sp;    2486.  January 1999.

[CMS]          P. = Calhoun, W. Bulley, S. Farrell, "Diameter CMS
Security

          &nb= sp;    Application", = draft-ietf-aaa-diameter-cms-sec-03.txt,
          &nb= sp;    IETF work in progress, November 2001.

[HMAC]         H. = Krawczyk, M. Bellare, and R. Cannetti.  HMAC:
Keyed-
          &nb= sp;    Hashing for Message Authentication.  RFC = 2104,
February
          &nb= sp;    1997.

[MIPKEYS]      C. Perkins, = P. Calhoun, "AAA Registration Keys for
Mobile

          &nb= sp;    IP", draft-ietf-mobileip-aaa-key-08.txt, = IETF work in
          &nb= sp;    progress, July 2001.


11.2 Informative

[MIPREQ]       S. = Glass, S. Jacobs, C. Perkins, "Mobile IP
Authentica­
          &nb= sp;    tion, Authorization, and Accounting = Requirements". RFC
          &nb= sp;    2977. October 2000.

[CDMA2000]     T. Hiller and al, = "CDMA2000 Wireless Data Requirements
          &nb= sp;    for AAA", RFC 3141, June 2001.

[KEYWORDS]     S. Bradner, = "Key words for use in RFCs to Indicate
          &nb= sp;    Requirement Levels", BCP 14, RFC 2119, March = 1997.

[EVALROAM]     B. Aboba, G. Zorn, = "Criteria for Evaluating Roaming
Pro­
          &nb= sp;    tocols", RFC 2477, January 1999.

[MIPNAI]       P. = Calhoun, C. Perkins, "Mobile IP Network Address
Iden­
          &nb= sp;    tifier Extension", RFC 2794, March = 2000.

[RANDOM]       D. = Eastlake, 3rd, S. Crocker, and J. Schiller.
Random­
          &nb= sp;    ness Recommendations for Security.  Request = for
Comments
          &nb= sp;    (Informational) 1750, Internet Engineering Task = Force,
          &nb= sp;    December 1994.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHV1gjN1fXKoxmisEQIRQwCcDhNxbf3xMFQ8SqwtloMBZpsZe+8An37= k
QXvIOfmn3mXAwqi7AQIh+rnL
=3DT06E
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BB27.A832E170-- From owner-aaa-wg@merit.edu Thu Feb 21 17:39:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06390 for ; Thu, 21 Feb 2002 17:39:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B185912CF; Thu, 21 Feb 2002 17:39:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DBDD912D0; Thu, 21 Feb 2002 17:39:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07C5B912CF for ; Thu, 21 Feb 2002 17:39:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCFEA5DE0E; Thu, 21 Feb 2002 17:39:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9AF585DD9D for ; Thu, 21 Feb 2002 17:39:24 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6565B79; Thu, 21 Feb 2002 17:39:24 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: Mobile-IP accounting -- 3 thoughts Date: Thu, 21 Feb 2002 17:38:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C756A23.5D93740B@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Tony Johansson > Sent: Thursday, February 21, 2002 4:44 PM > To: Bob Kopacz > Cc: aaa-wg > Subject: [AAA-WG]: Re: Mobile-IP accounting -- 3 thoughts > > Hello Bob, > > Please, find comments embedded. > > BR, > > /Tony > > Bob Kopacz wrote: > > > Hi Tony, > > > > Here's a few Mobile-IP accounting thoughts. I don't feel strongly > > enough about them to submit as issues, but I will do so if anyone > > thinks they are "issue-worthy". > > > > 1. The MIP-Feature-Vector is disallowed in AMA and HAA answer > > messages. > > > > Maybe the MIP-Feature-Vector should be returned in answer messages, > > for a couple of reasons: > > > > (a) The MIP-Feature-Vector is required in Mobile IP accounting > > messages. However the value which the FA originates in his AMR may > > be modified by the AAAF, so the HA sees a different value. Then > > accounting messages sent by the FA and HA for the same session will > > reflect different values for the MIP-Feature-Vector. > > > > > > > (b) Perhaps in the future, more bits may be added to the > > MIP-Feature-Vector so that the AAAH or HA can use the > > MIP-Feature-Vector to pass information. > > > Or maybe a new bit is set by > > the AAAF that the FA needs to know about. If so, then returning the > > MIP-Feature-Vector in answer messages makes sure this information is > > conveyed to all parties. > > To echo back the MIP-Feature-Vector in the AMA sound reasonable, so that > we can grantee that the FA and the HA uses the same values. For HAA I'm > not so sure. The main purpose of the MIP-Feature-Vector is to support the > AAAH in how to authorize the MN (HA assignment, etc.). Why would we need > to pass info from the HA to the AAAH? I may be wrong here but I don't see > why we should allow the MIP-Feature-Vector in the HAA unless we see a good > reason. > > Others, comments? That's fine. This was just an 11th hour thought I was spewing out. The reason I suggested allowing the MIP-Feature-Vector in the HAA was that my notion of the MIP-Feature-Vector was that it was a general purpose flagword, so it could just as well be used by the HA to convey something back to the AAAH (or FA). But if the MIP-Feature-Vector is more for the purpose of informing the AAAH about how to authorize the MN, then it probably doesn't belong in the HAA, unless the HA has something of this nature to feed back to the AAAH that might affect the AAAH's thinking. > > > > > > > 2. Both the NASREQ draft and the Mobile-IP draft require, > > in their AVP occurrence rules, that the following AVPs be > > present in an Accounting Request message: > > > > Accounting-Input-Extended-Octets > > Accounting-Input-Extended-Packets > > Accounting-Output-Extended-Octets > > Accounting-Output-Extended-Packets > > Accounting-Session-Time (= duration, in seconds) > > > > In the case of an Accounting-Start, these values are all zero. > > Are these AVP supposed to be required (with zero values) in this case, > > or is this just an oversight when putting together the occurrence > > rules? > > Good question, but I believe that they should be required. True, they are > all > zero, but instead of making exception the first time I would think it is > better to always send them and not only in all interims. That's fine with me. Just a question. > > Bob K. From owner-aaa-wg@merit.edu Thu Feb 21 18:01:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06870 for ; Thu, 21 Feb 2002 18:01:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C3B8B912D2; Thu, 21 Feb 2002 18:00:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 891DD912D3; Thu, 21 Feb 2002 18:00:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 466D1912D2 for ; Thu, 21 Feb 2002 18:00:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BAB25DE06; Thu, 21 Feb 2002 18:00:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (unknown [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 3C6895DE05 for ; Thu, 21 Feb 2002 18:00:19 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1LMwwh22071 for ; Thu, 21 Feb 2002 16:58:58 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1LMwwh27384 for ; Thu, 21 Feb 2002 16:58:58 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA20462 for ; Thu, 21 Feb 2002 16:58:58 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA00992 for ; Thu, 21 Feb 2002 16:58:57 -0600 (CST) Message-ID: <3C757B25.7FA45951@ericsson.com> Date: Thu, 21 Feb 2002 14:56:37 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: ISSUE 266: ready for closure? Content-Type: multipart/alternative; boundary="------------9FDC63282720CB8F8FE1CD61" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------9FDC63282720CB8F8FE1CD61 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Here is the text proposal for issue 266 based on the outcome of the previous thread discussion regarding issue 266: "Returning AAAF-Generated FA-HA Key to FA". This proposal is based on CMS in case of encryption and the fact the we are allowed to issue DSA messages between two servers, even in the case where non of the servers belong to the users home domain (see http://www.merit.edu/mail.archives/aaa-wg/thismonth/msg00042.html). Stephen, Jari and other CMS knowledge people please let me know if you have any comments / objection to the usage of CMS in the case of encryption of the FA-HA Key below. Comments / objections /Tony .................................................................................................................................... 1.4 Allocation of Home Agent in Foreign Network The Diameter Mobile IP application allows a Home Agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home- Agent- Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to zero. When the AAAF receives an AMR message with the Home-Agent-Requested flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP to inform the AAAH that it is willing and able to assign a Home Agent for the Mobile Node. When doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- Agent-Host AVP contains the identity of the home agent that would be assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP contains the identity of the AAAF. In the event that the mobile node requests a home agent in the foreign network, and the AAAF authorizes its use, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. This could happen when the AAA request is sent to "extend" a mobile node's current session. When the AAAH receives an AMR message, it first checks the authentication data supplied by the mobile node, according to the MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether to authorize the mobile node. If the AMR indicates that the AAAF has offered to allocate a home agent for the mobile node, then the AAAH must decide whether its local policy would allow the user to have a Home Agent in the foreign network. If so, and after checking authorization from the data in the AMR message, the AAAH sends the HAR message to the AAAF that does not contain the MIP-Home-Agent- Address, but includes the Destination-Host AVP set to the value of the AMR's MIP-Candidate-Home-Agent-Host AVP. If the HA hasn't yet been allocated by the foreign domain, the HAR sent by the AAAH back to the foreign realm will not necessarily be received by the same AAAF which sent the AMR. Therefore the AAAH MUST always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message to the HAR message. In cases when another AAAF, which may not reside in the same domain, receives the HAR, thus the new AAAF will use the MIP-Originating-Foreign-AAA-AVP for policy decisions, such as determining if the FA-HA Key should be encrypted or not. .............. 4.11 MIP-Originating-Foreign-AAA AVP The MIP-Originating-Foreign-AAA AVP (AVP Code TBD) if of type Grouped, and contains the identity of the AAAF which issues the AMR to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used in cases when the home agent is or may be allocated in a foreign domain. If present in the AMR, the AAAH MUST copy the MIP- Originating-Foreign-AAA AVP into the HAR. MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > { Origin-Realm } { Origin-Host } * [ AVP ] .............. 5.4 Distributing the Foreign-Home Session Key If the home agent is in the home realm, then the AAAH has to generate the Foreign-Home session key. Otherwise, it is generated by AAAF. In the cases when the AAAH generates the Foreign-Home session key, the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and includes the AVP as part of the HAR message sent to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAH until the HAA is received. Upon receipt of the HAR, the home agent recovers the Foreign-Home session key, allocates an SPI to be used with the key. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the AMA. In the cases when the AAAF generates the Foreign-Home session key (home agent in foreign domain), the AAAF will, upon receipt of the HAR message, generate the Foreign-Home session key and include the session key in the MIP-HA-to-FA-Key AVP as part of the HAR message forwarded to the home agent. The corresponding session key that is to be sent to the foreign agent is cached in the AAAF until the HAA is received. Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the Foreign-Home session key destined for the foreign agent needs to be encrypted. If the session key needs to be encrypted, the AAAF will check if a security association can be established using DSA messages defined in the CMS application [CMS] with the originating host found in the MIP- Originating-Foreign-AAA AVP. If the DSA establishment is successful, the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted- Data AVP with the AAAF as originator and the recipient copied from the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is included by the AAAF in the HAA destined for the AAAH. Otherwise, if the DSA establishment fails, the AAAF MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If the session key does not need to be encrypted, the AAAF will add MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the HAA to the AAAH . Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA Key AVP if present or the CMS-Ecrypted-data AVP if present and not destined for the AAAH into the AMA. If a Foreign-Home session key was present in the AMA, the foreign agent MUST include the Mobile-Foreign authentication extension in the Registration Reply, using the newly distributed key. ......... --------------9FDC63282720CB8F8FE1CD61 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit All,

Here is the text proposal for issue 266 based on the outcome of the previous thread discussion regarding issue 266: "Returning AAAF-Generated FA-HA Key to FA".

This proposal is based on CMS in case of encryption and the fact the we are allowed to issue DSA messages between two servers, even in the case where non of the servers belong to the users home domain (see http://www.merit.edu/mail.archives/aaa-wg/thismonth/msg00042.html).  Stephen, Jari and other CMS knowledge people please let me know if you have any comments / objection to the usage of CMS in the case of encryption of the FA-HA Key below.

Comments / objections
 

/Tony

....................................................................................................................................

1.4  Allocation of Home Agent in Foreign Network

   The Diameter Mobile IP application allows a Home Agent to be
   allocated in a foreign network, as required in [MIPREQ, CDMA2000].
   When a foreign agent detects that the mobile node has a home agent
   address equal to 0.0.0.0 or 255.255.255.255 in the Registration
   Request message, it MUST add a MIP-Feature-Vector AVP with the Home-
   Agent- Requested flag set to one. If the home agent address is equal
   to 255.255.255.255, then the foreign agent also MUST set the Home-
   Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home
   agent address is set to 0.0.0.0, the foreign agent MUST set the Home-
   Address-Allocatable-Only-in-Home-Realm flag equal to zero.

   When the AAAF receives an AMR message with the Home-Agent-Requested
   flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm
   flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available
   flag in the MIP-Feature-Vector AVP to inform the AAAH that it is
   willing and able to assign a Home Agent for the Mobile Node. When
   doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP
   and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-
   Agent-Host AVP contains the identity of the home agent that would be
   assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP
   contains the identity of the AAAF.

   In the event that the mobile node requests a home agent in the
   foreign network, and the AAAF authorizes its use, the AAAF MUST set
   the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
   This could happen when the AAA request is sent to "extend" a mobile
   node's current session.

   When the AAAH receives an AMR message, it first checks the
   authentication data supplied by the mobile node, according to the
   MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether
   to authorize the mobile node.  If the AMR indicates that the AAAF has
   offered to allocate a home agent for the mobile node, then the AAAH
   must decide whether its local policy would allow the user to have a
   Home Agent in the foreign network. If so, and after checking
   authorization from the data in the AMR message, the AAAH sends the
   HAR message to the AAAF that does not contain the MIP-Home-Agent-
   Address, but includes the Destination-Host AVP set to the value of
   the AMR's MIP-Candidate-Home-Agent-Host AVP.

   If the HA hasn't yet been allocated by the foreign domain, the HAR
   sent by the AAAH back to the foreign realm will not necessarily be
   received by the same AAAF which sent the AMR. Therefore the AAAH MUST
   always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message
   to the HAR message. In cases when another AAAF, which may not reside
   in the same domain, receives the HAR, thus the new AAAF will use the
   MIP-Originating-Foreign-AAA-AVP for policy decisions, such as
   determining if the FA-HA Key should be encrypted or not.

      ..............
 

4.11 MIP-Originating-Foreign-AAA AVP

   The MIP-Originating-Foreign-AAA AVP (AVP Code TBD) if of type
   Grouped, and contains the identity of the AAAF which issues the AMR
   to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used
   in cases when the home agent is or may be allocated in a foreign
   domain. If present in the AMR, the AAAH MUST copy the MIP-
   Originating-Foreign-AAA AVP into the HAR.

      MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ >
                                   { Origin-Realm }
                                   { Origin-Host }
                                 * [ AVP ]
 

       ..............

5.4  Distributing the Foreign-Home Session Key

   If the home agent is in the home realm, then the AAAH has to generate
   the Foreign-Home session key. Otherwise, it is generated by AAAF.

   In the cases when the AAAH generates the Foreign-Home session key,
   the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and
   includes the AVP as part of the HAR message sent to the home agent.
   The corresponding session key that is to be sent to the foreign agent
   is cached in the AAAH until the HAA is received.

   Upon receipt of the HAR, the home agent recovers the Foreign-Home
   session key, allocates an SPI to be used with the key. The allocated
   SPI is included in the HAA's MIP-FA-to-HA SPI AVP.

   Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP,
   using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the
   AMA.

   In the cases when the AAAF generates the Foreign-Home session key
   (home agent in foreign domain), the AAAF will, upon receipt of the
   HAR message, generate the Foreign-Home session key and include the
   session key in the MIP-HA-to-FA-Key AVP as part of the HAR message
   forwarded to the home agent. The corresponding session key that is to
   be sent to the foreign agent is cached in the AAAF until the HAA is
   received.

   Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP,
   using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the
   Foreign-Home session key destined for the foreign agent needs to be
   encrypted.

   If the session key needs to be encrypted, the AAAF will check if a
   security association can be established using DSA messages defined in
   the CMS application [CMS] with the originating host found in the MIP-
   Originating-Foreign-AAA AVP. If the DSA establishment is successful,
   the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-
   Data AVP with the AAAF as originator and the recipient copied from
   the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is
   included by the AAAF in the HAA destined for the AAAH. Otherwise, if
   the DSA establishment fails, the AAAF MUST return a Result-Code AVP
   with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.

   If the session key does not need to be encrypted, the AAAF will add
   MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the
   HAA to the AAAH .

   Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA
   Key AVP if present or the CMS-Ecrypted-data AVP if present and not
   destined for the AAAH into the AMA.

   If a Foreign-Home session key was present in the AMA, the foreign
   agent MUST include the Mobile-Foreign authentication extension in the
   Registration Reply, using the newly distributed key.

   .........
  --------------9FDC63282720CB8F8FE1CD61-- From owner-aaa-wg@merit.edu Fri Feb 22 08:33:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01430 for ; Fri, 22 Feb 2002 08:33:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B59B591227; Fri, 22 Feb 2002 08:32:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 797B79122A; Fri, 22 Feb 2002 08:32:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 240A691227 for ; Fri, 22 Feb 2002 08:32:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE60E5DE18; Fri, 22 Feb 2002 08:32:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 358C35DD9D for ; Fri, 22 Feb 2002 08:32:46 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1MDWsZ13555 for ; Fri, 22 Feb 2002 15:32:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 22 Feb 2002 15:32:44 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 22 Feb 2002 15:32:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Accouting AVP issue... Date: Fri, 22 Feb 2002 15:32:44 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC649EF@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Accouting AVP issue... Thread-Index: AcG7BC6hVNpsTueyQOaIpUxB+9RFdAAoN4qg From: To: , , X-OriginalArrivalTime: 22 Feb 2002 13:32:45.0050 (UTC) FILETIME=[691B9DA0:01C1BBA5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA01430 Hi all, > A few revisions ago, the base included the accounting AVPs. An issue > vwas created by Glen Zorn, and with WG concensus the AVPs were moved > to the application specs. > If we want to now go back in time, we should go back and understand > the original reasoning for moving the AVPs to the application specs. I'm going to side with Pat on this. I think we can forever go back and forth, and get nowhere. Let's keep the current text/solution. John From owner-aaa-wg@merit.edu Fri Feb 22 08:39:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01581 for ; Fri, 22 Feb 2002 08:39:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C92079122A; Fri, 22 Feb 2002 08:39:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9501591280; Fri, 22 Feb 2002 08:39:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D0319122A for ; Fri, 22 Feb 2002 08:39:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7A7C65DDCD; Fri, 22 Feb 2002 08:39:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 65B7B5DD9D for ; Fri, 22 Feb 2002 08:39:21 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 3BAD379; Fri, 22 Feb 2002 08:39:21 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: Pending Issue about MIP-Key-Lifetime AVP Date: Fri, 22 Feb 2002 08:38:30 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > Yes I agree, could you please submit a new issue for this. > So, we don't forget it. The above is from an email you sent me on 1-Feb, Subj: "Re: [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA", where I had asked a few questions about the MIP-Key-Lifetime. I just now rediscovered that I never did submit this issue. However, before I submit an issue about MIP-Key-Lifetime AVP, I want to get your take on a few further things regarding MIP-Key-Lifetime, so I can submit a more complete issue. My questions reflect my ignorance. The following is a numbered list. The "-->" indicates either a question, or what I believe is the answer. The "-->" things are what is to be addressed in the pending MIP-Key-Lifetime AVP issue. (1) There is a single MIP-Key-Lifetime AVP which contains the lifetime that applies to all the keys. --> The draft should add the following clarifications: "Since the AAAH is the owner of the MN, the AAAH specifies the key lifetime for the keys it generates as well for as the HA-FA key, if generated by the destination AAAF. Therefore, even if the AAAH isn't generating any keys and the only key being generated is the HA-FA key by the destination AAAF, the AAAH must remember to pass the MIP-Key-Lifetime AVP in the HAR." (2) Section 1.2 of the mobile-ip draft says: | "The expiration time of the | authorization (and session keys, if allocated by the AAA server) is | communicated through the Authorization-Lifetime AVP in the AA-Mobile- | Node-Answer from the AAAH." --> The sentence should be rephrased to remove the parenthesized phrase, or to remove the parenthesized phrase and add the sentence "The expiration time of the session keys is communicated through the MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the AAAH." (3) The base draft says a number of things about the Auth-Lifetime AVP, such as: 3a. The relationship of the Auth-Lifetime value and the Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout value) 3b. The state transitions and actions that take place, for both the server and the access device, when the Auth-Lifetime (+grace period) expires. 3c. How the client can send the Auth-Lifetime as a "hint" to the server. draft-mobileip-08 doesn't say nearly so much about the MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with "Auth-Lifetime" replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c above). What draft-mobileip-08 says is the following: | 6.13 MIP-Key-Lifetime AVP | | The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and | represents the period of time (in seconds) for which the session key | is valid. The session key MUST NOT be used if the lifetime has | expired; if the key lifetime expires while the session to which it | applies is still active, either the session key MUST be changed or | the or the session MUST be terminated. So ... (4) The draft-base-08 says the following things about the Authorization-Lifetime AVP, and the "-->" indicates that the same sorts of things should be addressed for the MIP-Key-Lifetime AVP: | base-08 Section 2.0 "Protocol Overview" says: | | Session state (associated with a Session-Id) MUST be freed upon | receipt of the Session-Termination-Request, Session-Termination- | Answer, expiration of authorized service time in the Session-Timeout | AVP, and according to rules established in a particular Diameter | application. | | | base-08 Section 8.1 "Authorization Session State Machine" says: | | Open Authorization-Lifetime (and Cleanup Discon | Auth-Grace-Period) expires | on home server. | | Open Session-Timeout expires on Cleanup Discon | home server | | Open Authorization-Lifetime + send STR Discon | Auth-Grace-Period expires on | access device | | Open Session-Timeout Expires on send STR Discon | Access Device --> draft-mobileip should specify the actions of both the server and the access device when the MIP-Key-Lifetime AVP expires. Presumably the access device should send an STR, while the server quietly cleans out the session. --> should draft-mobileip (and the other application drafts) add an "Authorization Session State Machine" and "Accounting Session State Machine" section, indicating application-specific extensions to the base state machine? e.g. mobileip-08 would add "Open Key-Lifetime Expires on Access Device send STR Discon" --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so, is a new MIP-Key-Lifetime-Grace-Period AVP needed? | base-08 Section 8.4 "Session Termination" says: | | A Diameter server also MUST clean up resources when the Session- | Timeout expires, or when the Authorization-Lifetime and the Auth- | Grace-Period AVPs expires without receipt of a re-authorization | request, regardless of whether an STR for that session is received. | The access device is not expected to provide service beyond the | expiration of these timers; thus, expiration of either of these | timers implies that the access device may have unexpectedly shut | down. | | base-08 Section 8.9 "Authorization-Lifetime AVP" says: | | If both this AVP and the Session-Timeout AVP are present in a | message, the value of the latter MUST NOT be smaller than the | Authorization-Lifetime AVP. | | This AVP MAY be provided by the client as a hint of the maximum | lifetime that it is willing to accept. However, the server MAY return | a value that is equal to, or smaller, than the one provided by the | client. --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ? --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as some sort of hint? | base-08 Section 8.12 "Re-Auth-Request-Type AVP" says: | | The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and | is included in application-specific auth answers to inform the client | of the action expected upon expiration of the Authorization-Lifetime. | The following values are defined: | | AUTHORIZE_ONLY 0 | An authorization only re-auth is expected upon expiration of | the Authorization-Lifetime. This is the default value if the | AVP is not present in answer messages that include the | Authorization-Lifetime. | | AUTHORIZE_AUTHENTICATE 1 | An authentication and authorization re-auth is expected upon | expiration of the Authorization-Lifetime. --> Should the server convey something akin to the above, to tell the client what action to take upon MIP-Key-Lifetime expiration? Can the client request a "key refresh"? Bob K. From owner-aaa-wg@merit.edu Fri Feb 22 13:54:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16490 for ; Fri, 22 Feb 2002 13:54:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DC5E391230; Fri, 22 Feb 2002 13:54:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC73891295; Fri, 22 Feb 2002 13:54:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A00A091230 for ; Fri, 22 Feb 2002 13:54:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F2635DDC4; Fri, 22 Feb 2002 13:54:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 68CE45DDB8 for ; Fri, 22 Feb 2002 13:54:35 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 184617D for ; Fri, 22 Feb 2002 13:54:35 -0500 (EST) Message-ID: <3C7693EE.194EC2FA@Interlinknetworks.com> Date: Fri, 22 Feb 2002 13:54:38 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] AAA URI is Overloaded Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] AAA URI is Overloaded Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: 2/21/02 Reference: Document: Base Comment type: T Priority: S Section: 4.4 Rationale/Explanation of issue: Some Background --------------- The AAA URI provides two different kinds of information. 1. It identifies a Diameter node. A Diameter node is a Diameter process running on some host or device. It is possible to have more than one Diameter process running on a host. 2. It provides information about how to connect to the Diameter node -- what transport protocol to use, what transport level security to use, and even what AAA protocol to use (although we are only concerned about one, namely Diameter). The AAA URI also serves two different purposes. 1. It is used in the peer-to-peer protocol to identify a peer and indicate certain parameters concerning how to connect to that peer. This use requires the full URI including the prefix, the fqdn, the port number, and the options. A URI for this purpose may be stored in a local configuration file or on a remote server to enable dynamic peer discovery (see sec. 5.2). 2. It is used in the Diameter routing and forwarding decisions to identify the Diameter node to which a Diameter message is addressed. This use requires those portions of the URI that identify the Diameter node but does not require (and can be confused by) the information about how to connect to the node as a peer. This is the use made of the URI as transmitted in all AVPs of type DiameterIdentity. The Problem ----------- The problem is that the URI format is currently defined in only one place (sec. 4.4 under the "DiameterIdentity" type) and makes no distinction between its use for the two different purposes described above. Operational Difficulties if the Problem Isn't Fixed --------------------------------------------------- Section 4.4 states: Unless a Diameter node is sitting on the border of two routing domains (e.g. private and public), a Diameter node MUST advertise the same identity on all connections, via the CER and CEA's Origin-Host AVP. Suppose a Diameter node has two peers. It connects to the first peer using SCTP. It connects to the second peer using TCP. In order to obey this requirement, the node would have to include the string "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA message to the second peer even though it is using TCP to connect to that peer. So the identity advertised is not the identity used. This seems odd, but as we shall see, it is actually necessary in order to make the routing mechanism work. Section 4.4 goes on to state: The same identity advertised in a connection's CER and CEA MUST be used in any AVP of type DiameterIdentity sent on that connection. Now suppose an implementor misses the oddity required by the first sentence and does the obvious thing -- suppose the implementation always includes in the CER the parameters actually in use on the peer connection. Then the implementation will have a very hard time meeting this requirement too. It would have to know how it will route the message at the time it generates the message, a horrible violation of modularity. Supposing it does know how it will route the message and sets the value of the Origin-Host AVP in the message to the same value used in the CER or CEA sent to the peer to which it will route it. Now suppose something goes wrong when sending the message to this peer, and the message is subsequently retransmitted to a backup peer. Oops. Now the Origin-Host AVP is wrong for that connection and it can't be changed. So we'll just have to assume that all implementors pick up on the oddity. But wait -- we're still not out of the woods. Suppose, at the time a session begins, the Diameter client supporting the session uses TCP on its peer link. So it includes the string "transport=tcp" in the auth request that begins the session. Suppose that several hours later the session is still in progress, but the client has reinitialized its peer link and is now using SCTP. Now suppose the home server sends an Abort-Session-Request message to the client for this session. The Abort-Session-Request will include a Destination-Host AVP that contains the string "transport=tcp". The message eventually reaches the peer connected to the client. The peer matches the URI in the Destination-Host AVP with the ones in its peer table. It finds no match because "transport=tcp" does not match "transport=sctp". So it discards the message. Interaction With Issue 273 -------------------------- Another issue urges that Diameter nodes not use different port numbers for TLS versus non-TLS connections. I am guessing that issue 273 is the one that encompasses this change. The question of port number use for TLS versus non-TLS was raised by Allison Mankin in: http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html The outcome of issue 273 (if that is the issue that includes this question) is critical to the resolution of this issue as well. The reason is that we use the combination of fqdn and port number to identify a diameter node. If more than one Diameter node (Diameter daemon) runs on a host, they will use different port numbers. But if a Diameter node listens on more than one port number, then it may use two different URIs and there will be no way for a peer to know that the URI from the Destination-Host AVP of a message it is routing matches the URI of one of its peers if the port number differs. John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS is used in: http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html If this suggestion is adopted, then the "s" in aaas: will need to be ignored when doing routing matches against entries in the peer table. Requested change: Define the format of the URI somewhere other than section 4.4. In the definition of the DiameterIdentity type in section 4.4, specify that only the prefix, fqdn, and port number portions of the URI are included in AVP value fields of this type. The sentences cited above may now be left in section 4.4 because they no longer cause a problem. If the resolution of issue 273 allows a Diameter node to listen on different ports for TLS vs. non-TLS connections, then section 4.4 needs to emphasize that a single port number MUST be used in all AVPs of type DiameterIdentity. If the resolution of 273 requires use of the same port for TLS and non-TLS connections, then it would still be a good idea to include text in section 4.4 following the first sentence cited above that emphasizes that the same port number MUST be used in all AVPs of type DiameterIdentity even if a peer connection request was received on a different port. If the URI prefix may either be aaa: or aaas: depending on transport security, then text should be added to section 6 stating that when matching URIs for routing purposes, the "s" in aaas: should be dropped before the compare is made. From owner-aaa-wg@merit.edu Fri Feb 22 14:50:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19161 for ; Fri, 22 Feb 2002 14:50:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87891912DA; Fri, 22 Feb 2002 14:47:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B0A191295; Fri, 22 Feb 2002 14:47:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCF26912DA for ; Fri, 22 Feb 2002 14:46:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id A174E5DDB8; Fri, 22 Feb 2002 14:46:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by segue.merit.edu (Postfix) with ESMTP id 103EC5DDC4 for ; Fri, 22 Feb 2002 14:46:34 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep01-svc.swip.net with ESMTP id <20020222194630.PTOW27078.fep01-svc.swip.net@ipunplugged.com>; Fri, 22 Feb 2002 20:46:30 +0100 Message-ID: <3C76AE02.2030504@ipunplugged.com> Date: Fri, 22 Feb 2002 21:45:54 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <3C7693EE.194EC2FA@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Spence wrote: >Section 4.4 states: > > Unless a Diameter node is sitting on the border of two routing > domains (e.g. private and public), a Diameter node MUST > advertise the same identity on all connections, via the CER > and CEA's Origin-Host AVP. > > Suppose a Diameter node has two peers. It connects to the first peer > using SCTP. It connects to the second peer using TCP. In order to > obey this requirement, the node would have to include the string > "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA > message to the second peer even though it is using TCP to connect to > that peer. So the identity advertised is not the identity used. > This seems odd, but as we shall see, it is actually necessary in order > to make the routing mechanism work. > > Section 4.4 goes on to state: > > The same identity advertised in a connection's CER and CEA MUST > be used in any AVP of type DiameterIdentity sent on that > connection. > > Now suppose an implementor misses the oddity required by the first > sentence and does the obvious thing -- suppose the implementation > always includes in the CER the parameters actually in use on the peer > connection. Then the implementation will have a very hard time > meeting this requirement too. It would have to know how it will > route the message at the time it generates the message, a horrible > violation of modularity. Supposing it does know how it will route > the message and sets the value of the Origin-Host AVP in the message > to the same value used in the CER or CEA sent to the peer to which it > will route it. Now suppose something goes wrong when sending the > message to this peer, and the message is subsequently retransmitted > to a backup peer. Oops. Now the Origin-Host AVP is wrong for that > connection and it can't be changed. > > So we'll just have to assume that all implementors pick up on the > oddity. But wait -- we're still not out of the woods. Suppose, at > the time a session begins, the Diameter client supporting the session > uses TCP on its peer link. So it includes the string "transport=tcp" > in the auth request that begins the session. Suppose that several > hours later the session is still in progress, but the client has > reinitialized its peer link and is now using SCTP. Now suppose the > home server sends an Abort-Session-Request message to the client for > this session. The Abort-Session-Request will include a > Destination-Host AVP that contains the string "transport=tcp". The > message eventually reaches the peer connected to the client. The > peer matches the URI in the Destination-Host AVP with the ones in its > peer table. It finds no match because "transport=tcp" does not match > "transport=sctp". So it discards the message. > Yes. I have been using transport security as my example in my concerns about the same problem that I have posted now and then for the last months. The only way to obey the spec as written is that everyone in the network runs the same protocol with the same security or that an artificial routing domain border is introduced. > > John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS > is used in: > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html > > If this suggestion is adopted, then the "s" in aaas: will need to be > ignored when doing routing matches against entries in the peer table. > Well, there is already a way to specify TLS. I'm not sure why he decided to introduce another way, but if I recall correctly it was related to how it was specified in sip. The effect is however the same. I really don't see why nodes several hops would need to know how the next to last node connects to the last node, which is what in effect happens when you use sessions with state and use the Origin-Host of the received response as Destination-Host in subsequent requests. Making the URI simply that - an identifier - would at least make me happy. j From owner-aaa-wg@merit.edu Fri Feb 22 16:48:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27040 for ; Fri, 22 Feb 2002 16:48:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 35C32912DC; Fri, 22 Feb 2002 16:48:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 075E6912DE; Fri, 22 Feb 2002 16:48:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15D35912DC for ; Fri, 22 Feb 2002 16:48:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF8B65DDF9; Fri, 22 Feb 2002 16:48:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id CC4885DDEC for ; Fri, 22 Feb 2002 16:48:23 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 8C8EF7E for ; Fri, 22 Feb 2002 16:48:23 -0500 (EST) Message-ID: <3C76BCAA.7CAA2E9B@Interlinknetworks.com> Date: Fri, 22 Feb 2002 16:48:26 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Ambiguities in AVP Flag rules tables Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Ambiguities in AVP Flag rules tables Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: 2/22/2 Reference: Document: base, cms-sec Comment type: T Priority: 1 Section: base sec. 4.6, cms-sec sec. 6.0 Rationale/Explanation of issue: Several AVPs listed in the table in sec. 4.6 of the base draft do not include all three flags in the AVP Flag rules columns. This leads to ambiguities. For example, how should I set the 'M' flag in the Error-Message AVP? 'M' is not listed in the MAY column so I guess I can't set it, but then 'M' is not listed in the MUST NOT column so perhaps I can set it. In the AVP Flag rules table in sec. 6.0 of the cms-sec draft, in the DSA-TTL row, the 'P' flag is listed twice. It appears in both the MAY and MUST NOT columns. Requested change: The following rows in the table in sec. 4.6 of the base draft need to be fixed: Error-Message Error-Reporting-Host Product-Name Redirect-Host The following row in the table in sec 6.0 of the cms-sec draft needs to be fixed: DSA-TTL From owner-aaa-wg@merit.edu Fri Feb 22 17:49:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29718 for ; Fri, 22 Feb 2002 17:49:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6852F91209; Fri, 22 Feb 2002 17:48:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C607912DE; Fri, 22 Feb 2002 17:48:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 27EF691209 for ; Fri, 22 Feb 2002 17:48:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEFE85DE28; Fri, 22 Feb 2002 17:48:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by segue.merit.edu (Postfix) with ESMTP id D204E5DE27 for ; Fri, 22 Feb 2002 17:48:48 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel13.hp.com (Postfix) with ESMTP id C06B9400984 for ; Fri, 22 Feb 2002 14:48:42 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id OAA02049 for ; Fri, 22 Feb 2002 14:50:06 -0800 (PST) Date: Fri, 22 Feb 2002 14:50:04 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: AAA Working Group Subject: [AAA-WG]: HA sending AMR Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, This is regarding AAA Mobile IP application. Consider the scenario when a MN returns home and sends a registration request to the HA for deregistration. Also, the MN-HA key has expired and the MN makes the deregistration request a AAA request. I am assuming that no standards prevent the MN using a AAA request for deregistration. While it is clear that the HA can send an AMR for a AAA request with a co-located COA, it is not clear as to what the HA should do in the de-registration case. And if the HA "can" send an AMR, current standards imply that the registration would go through the AMR-HAR-HAA-AMA cycle, all exchanged between the AAAH and the HA. (It seems like the AAAH directly sends an AMA for an AMR only if the co-located bit is set in the mip-feature-vector). I am guessing that the Mobile IP draft implicitly addresses this case and that going through AMR-HAR-HAA-AMA cycle is the implied solution. If so, can we optimize it similar to the co-located COA MN and have the HA and the AAAH just exchange AMR and AMA messages (maybe an extra bit in the feature vector). If going though the AMR-HAR-HAA-AMA cycle is not the implied solution, can someone tell me how this case is handled by the HA (and the AAAH)? If the draft does not cosider this scenario at all and all the "implied solution" is my imagination, can we specify what the HA should do in this case? thanks! Siva From owner-aaa-wg@merit.edu Fri Feb 22 17:51:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29807 for ; Fri, 22 Feb 2002 17:51:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EEDC912DE; Fri, 22 Feb 2002 17:50:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D28E7912DF; Fri, 22 Feb 2002 17:50:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C09DD912DE for ; Fri, 22 Feb 2002 17:50:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1EF85DE27; Fri, 22 Feb 2002 17:50:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 565795DDD8 for ; Fri, 22 Feb 2002 17:50:53 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SANL>; Fri, 22 Feb 2002 14:50:32 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Sivasundar Ramamurthy'" , AAA Working Group Subject: RE: [AAA-WG]: HA sending AMR Date: Fri, 22 Feb 2002 14:50:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBF3.50070950" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBF3.50070950 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Upon deregistration, shouldn't the HA send a Session-Termination-Request? PatC - -----Original Message----- From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] Sent: Friday, February 22, 2002 2:50 PM To: AAA Working Group Subject: [AAA-WG]: HA sending AMR Hello, This is regarding AAA Mobile IP application. Consider the scenario when a MN returns home and sends a registration request to the HA for deregistration. Also, the MN-HA key has expired and the MN makes the deregistration request a AAA request. I am assuming that no standards prevent the MN using a AAA request for deregistration. While it is clear that the HA can send an AMR for a AAA request with a co-located COA, it is not clear as to what the HA should do in the de-registration case. And if the HA "can" send an AMR, current standards imply that the registration would go through the AMR-HAR-HAA-AMA cycle, all exchanged between the AAAH and the HA. (It seems like the AAAH directly sends an AMA for an AMR only if the co-located bit is set in the mip-feature-vector). I am guessing that the Mobile IP draft implicitly addresses this case and that going through AMR-HAR-HAA-AMA cycle is the implied solution. If so, can we optimize it similar to the co-located COA MN and have the HA and the AAAH just exchange AMR and AMA messages (maybe an extra bit in the feature vector). If going though the AMR-HAR-HAA-AMA cycle is not the implied solution, can someone tell me how this case is handled by the HA (and the AAAH)? If the draft does not cosider this scenario at all and all the "implied solution" is my imagination, can we specify what the HA should do in this case? thanks! Siva -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHbLLzN1fXKoxmisEQK8BgCdEFYNA3ZtCHFgWgCWbV0Ya7OysD8Anjhm DXJQ8qkml9O/GL8OFvuQSSeW =rqAL -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BBF3.50070950 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: HA sending AMR

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Upon deregistration, shouldn't the HA send a
Session-Termination-Request?

PatC
- -----Original Message-----
From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com]
Sent: Friday, February 22, 2002 2:50 PM
To: AAA Working Group
Subject: [AAA-WG]: HA sending AMR



Hello,

This is regarding AAA Mobile IP application.

Consider the scenario when a MN returns home and = sends a registration
request to the HA for deregistration. Also, the = MN-HA key has expired
and the MN makes the deregistration request a AAA = request. I am
assuming that no standards prevent the MN using a = AAA request for
deregistration.

While it is clear that the HA can send an AMR for a = AAA request with
a co-located COA, it is not clear as to what the HA = should do in the
de-registration case. And if the HA "can" = send an AMR, current
standards imply that the registration would go = through the
AMR-HAR-HAA-AMA cycle, all exchanged between the = AAAH and the HA. (It
seems like the AAAH directly sends an AMA for an AMR = only if the
co-located bit is set in the = mip-feature-vector).

I am guessing that the Mobile IP draft implicitly = addresses this case
and that going through AMR-HAR-HAA-AMA cycle is the = implied solution.
If so, can we optimize it similar to the co-located = COA MN and have
the HA and the AAAH just exchange AMR and AMA = messages (maybe an
extra bit in the feature vector).

If going though the AMR-HAR-HAA-AMA cycle is not the = implied
solution, can someone tell me how this case is = handled by the HA (and
the AAAH)?

If the draft does not cosider this scenario at all = and all the
"implied solution" is my imagination, can = we specify what the HA
should do in this case?



thanks!

Siva

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHbLLzN1fXKoxmisEQK8BgCdEFYNA3ZtCHFgWgCWbV0Ya7OysD8Anjh= m
DXJQ8qkml9O/GL8OFvuQSSeW
=3DrqAL
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BBF3.50070950-- From owner-aaa-wg@merit.edu Fri Feb 22 18:03:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00233 for ; Fri, 22 Feb 2002 18:03:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BA5A8912E0; Fri, 22 Feb 2002 18:02:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 879B3912E8; Fri, 22 Feb 2002 18:02:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E08AD912E0 for ; Fri, 22 Feb 2002 18:02:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id C48815DDF9; Fri, 22 Feb 2002 18:02:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id 98CD35DDD8 for ; Fri, 22 Feb 2002 18:02:24 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 9E5E4600A5A; Fri, 22 Feb 2002 15:02:21 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id PAA02123; Fri, 22 Feb 2002 15:03:45 -0800 (PST) Date: Fri, 22 Feb 2002 15:03:43 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: "Pat R. Calhoun" Cc: AAA Working Group Subject: RE: [AAA-WG]: HA sending AMR In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello Pat, > Upon deregistration, shouldn't the HA send a > Session-Termination-Request? > > PatC It probably should (eventually), but how does the HA authenticate the deregistration request, given that there is no MN-HA authentication ext in the request? It seems like the HA needs to use the AAA infrastructure to authenticate the request.... Also, the HA MUST reply to the MN. For the MN to accept this reply, it probably needs to add a MN-HA auth ext, using the keys that the AAA server provides it when authenticating the user.... Is my thinking correct? thanks, Siva > - -----Original Message----- > From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] > Sent: Friday, February 22, 2002 2:50 PM > To: AAA Working Group > Subject: [AAA-WG]: HA sending AMR > > > > Hello, > > This is regarding AAA Mobile IP application. > > Consider the scenario when a MN returns home and sends a registration > request to the HA for deregistration. Also, the MN-HA key has expired > and the MN makes the deregistration request a AAA request. I am > assuming that no standards prevent the MN using a AAA request for > deregistration. > > While it is clear that the HA can send an AMR for a AAA request with > a co-located COA, it is not clear as to what the HA should do in the > de-registration case. And if the HA "can" send an AMR, current > standards imply that the registration would go through the > AMR-HAR-HAA-AMA cycle, all exchanged between the AAAH and the HA. (It > seems like the AAAH directly sends an AMA for an AMR only if the > co-located bit is set in the mip-feature-vector). > > I am guessing that the Mobile IP draft implicitly addresses this case > and that going through AMR-HAR-HAA-AMA cycle is the implied solution. > If so, can we optimize it similar to the co-located COA MN and have > the HA and the AAAH just exchange AMR and AMA messages (maybe an > extra bit in the feature vector). > > If going though the AMR-HAR-HAA-AMA cycle is not the implied > solution, can someone tell me how this case is handled by the HA (and > the AAAH)? > > If the draft does not cosider this scenario at all and all the > "implied solution" is my imagination, can we specify what the HA > should do in this case? > > > > thanks! > > Siva > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPHbLLzN1fXKoxmisEQK8BgCdEFYNA3ZtCHFgWgCWbV0Ya7OysD8Anjhm > DXJQ8qkml9O/GL8OFvuQSSeW > =rqAL > -----END PGP SIGNATURE----- > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== From owner-aaa-wg@merit.edu Fri Feb 22 18:09:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00494 for ; Fri, 22 Feb 2002 18:09:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 78E0D912E1; Fri, 22 Feb 2002 18:08:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 484DA912E2; Fri, 22 Feb 2002 18:08:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 32655912E1 for ; Fri, 22 Feb 2002 18:08:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0A6035DDD8; Fri, 22 Feb 2002 18:08:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id A0FD25DDF9 for ; Fri, 22 Feb 2002 18:08:53 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SA3A>; Fri, 22 Feb 2002 15:08:53 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Sivasundar Ramamurthy'" Cc: AAA Working Group Subject: RE: [AAA-WG]: HA sending AMR Date: Fri, 22 Feb 2002 15:08:44 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BBF5.E01C3090" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BBF5.E01C3090 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yes - you are thinking correctly. PatC - -----Original Message----- From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] Sent: Friday, February 22, 2002 3:04 PM To: Pat R. Calhoun Cc: AAA Working Group Subject: RE: [AAA-WG]: HA sending AMR Hello Pat, > Upon deregistration, shouldn't the HA send a > Session-Termination-Request? > > PatC It probably should (eventually), but how does the HA authenticate the deregistration request, given that there is no MN-HA authentication ext in the request? It seems like the HA needs to use the AAA infrastructure to authenticate the request.... Also, the HA MUST reply to the MN. For the MN to accept this reply, it probably needs to add a MN-HA auth ext, using the keys that the AAA server provides it when authenticating the user.... Is my thinking correct? thanks, Siva > - -----Original Message----- > From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com] > Sent: Friday, February 22, 2002 2:50 PM > To: AAA Working Group > Subject: [AAA-WG]: HA sending AMR > > > > Hello, > > This is regarding AAA Mobile IP application. > > Consider the scenario when a MN returns home and sends a > registration request to the HA for deregistration. Also, the MN-HA > key has expired and the MN makes the deregistration request a AAA > request. I am > assuming that no standards prevent the MN using a AAA request for > deregistration. > > While it is clear that the HA can send an AMR for a AAA request > with a co-located COA, it is not clear as to what the HA should do > in the de-registration case. And if the HA "can" send an AMR, > current > standards imply that the registration would go through the > AMR-HAR-HAA-AMA cycle, all exchanged between the AAAH and the HA. > (It seems like the AAAH directly sends an AMA for an AMR only if > the > co-located bit is set in the mip-feature-vector). > > I am guessing that the Mobile IP draft implicitly addresses this > case and that going through AMR-HAR-HAA-AMA cycle is the implied > solution. If so, can we optimize it similar to the co-located COA > MN and have the HA and the AAAH just exchange AMR and AMA messages > (maybe an extra bit in the feature vector). > > If going though the AMR-HAR-HAA-AMA cycle is not the implied > solution, can someone tell me how this case is handled by the HA > (and the AAAH)? > > If the draft does not cosider this scenario at all and all the > "implied solution" is my imagination, can we specify what the HA > should do in this case? > > > > thanks! > > Siva > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > > iQA/AwUBPHbLLzN1fXKoxmisEQK8BgCdEFYNA3ZtCHFgWgCWbV0Ya7OysD8Anjhm > DXJQ8qkml9O/GL8OFvuQSSeW > =rqAL > -----END PGP SIGNATURE----- > Thanks, Siva ==================================== Sivasundar Ramamurthy (She-va-su-ndar Ra-ma-moor-thee) Engineer, Mobile IP Project Hewlett Packard (408) 447 7255 ==================================== -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHbPfDN1fXKoxmisEQL4gQCfU6xJnLkJwd8IYUgjObtv1gNmrOEAoMuz Gw5Lss9HK2nPxyfNhr8NS0Pv =g1aC -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BBF5.E01C3090 Content-Type: text/html RE: [AAA-WG]: HA sending AMR

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes - you are thinking correctly.

PatC

- -----Original Message-----
From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com]
Sent: Friday, February 22, 2002 3:04 PM
To: Pat R. Calhoun
Cc: AAA Working Group
Subject: RE: [AAA-WG]: HA sending AMR



Hello Pat,

> Upon deregistration, shouldn't the HA send a
> Session-Termination-Request?
>
> PatC

It probably should (eventually), but how does the HA authenticate the
deregistration request, given that there is no MN-HA authentication
ext in the request? It seems like the HA needs to use the AAA
infrastructure to authenticate the request....

Also, the HA MUST reply to the MN. For the MN to accept this reply,
it probably needs to add a MN-HA auth ext, using the keys that the
AAA server provides it when authenticating the user....

Is my thinking correct?


thanks,

Siva


> - -----Original Message-----
> From: Sivasundar Ramamurthy [mailto:sramam@cup.hp.com]
> Sent: Friday, February 22, 2002 2:50 PM
> To: AAA Working Group
> Subject: [AAA-WG]: HA sending AMR
>
>
>
> Hello,
>
> This is regarding AAA Mobile IP application.
>
> Consider the scenario when a MN returns home and sends a
> registration  request to the HA for deregistration. Also, the MN-HA
> key has expired  and the MN makes the deregistration request a AAA
> request. I am
> assuming that no standards prevent the MN using a AAA request for
> deregistration.
>
> While it is clear that the HA can send an AMR for a AAA request
> with a  co-located COA, it is not clear as to what the HA should do
> in the  de-registration case. And if the HA "can" send an AMR,
> current
> standards imply that the registration would go through the
> AMR-HAR-HAA-AMA cycle, all exchanged between the AAAH and the HA.
> (It  seems like the AAAH directly sends an AMA for an AMR only if
> the
> co-located bit is set in the mip-feature-vector).
>
> I am guessing that the Mobile IP draft implicitly addresses this
> case  and that going through AMR-HAR-HAA-AMA cycle is the implied
> solution.  If so, can we optimize it similar to the co-located COA
> MN and have  the HA and the AAAH just exchange AMR and AMA messages
> (maybe an extra  bit in the feature vector).
>
> If going though the AMR-HAR-HAA-AMA cycle is not the implied
> solution,  can someone tell me how this case is handled by the HA
> (and the AAAH)? 
>
> If the draft does not cosider this scenario at all and all the
> "implied solution" is my imagination, can we specify what the HA
> should do in this case?
>
>
>
> thanks!
>
> Siva
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPfreeware 7.0.3 for non-commercial use
> <http://www.pgp.com> 
>
> iQA/AwUBPHbLLzN1fXKoxmisEQK8BgCdEFYNA3ZtCHFgWgCWbV0Ya7OysD8Anjhm
> DXJQ8qkml9O/GL8OFvuQSSeW
> =rqAL
> -----END PGP SIGNATURE-----
>


Thanks,

Siva


====================================
Sivasundar Ramamurthy          
(She-va-su-ndar Ra-ma-moor-thee)

Engineer, Mobile IP Project
Hewlett Packard
(408) 447 7255
====================================



-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPHbPfDN1fXKoxmisEQL4gQCfU6xJnLkJwd8IYUgjObtv1gNmrOEAoMuz
Gw5Lss9HK2nPxyfNhr8NS0Pv
=g1aC
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BBF5.E01C3090-- From owner-aaa-wg@merit.edu Fri Feb 22 18:35:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01093 for ; Fri, 22 Feb 2002 18:35:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 36EB491234; Fri, 22 Feb 2002 18:35:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04D209125B; Fri, 22 Feb 2002 18:35:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA64091234 for ; Fri, 22 Feb 2002 18:35:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id BC78E5DDF9; Fri, 22 Feb 2002 18:35:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 89F2E5DDD8 for ; Fri, 22 Feb 2002 18:35:41 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1MNZch04300; Fri, 22 Feb 2002 17:35:38 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1MNZbh20546; Fri, 22 Feb 2002 17:35:38 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA08530; Fri, 22 Feb 2002 17:35:37 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA25673; Fri, 22 Feb 2002 17:35:36 -0600 (CST) Message-ID: <3C76D53C.A4ACC6A0@ericsson.com> Date: Fri, 22 Feb 2002 15:33:16 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Sivasundar Ramamurthy Cc: AAA Working Group Subject: Re: [AAA-WG]: HA sending AMR References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Sivasundar, Sivasundar Ramamurthy wrote: > Hello, > > This is regarding AAA Mobile IP application. > > Consider the scenario when a MN returns home and sends a registration > request to the HA for deregistration. Also, the MN-HA key has expired > and the MN makes the deregistration request a AAA request. I am > assuming that no standards prevent the MN using a AAA request for > deregistration. In the scenario that you describe above the MN Keys has expired, which also means that the MN knows that if it doesn't issues a re-registration the MN will be de-registered, since the HA will issue an STR to the AAAH. So why would the MN issue a de-registration in this case? /Tony From owner-aaa-wg@merit.edu Fri Feb 22 19:14:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02061 for ; Fri, 22 Feb 2002 19:14:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 68A1E9122D; Fri, 22 Feb 2002 19:14:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EBE09125B; Fri, 22 Feb 2002 19:14:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A3E69122D for ; Fri, 22 Feb 2002 19:14:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B2A45DDF9; Fri, 22 Feb 2002 19:14:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by segue.merit.edu (Postfix) with ESMTP id E1AC65DDD8 for ; Fri, 22 Feb 2002 19:14:26 -0500 (EST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id 94E32600306; Fri, 22 Feb 2002 16:14:26 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA02253; Fri, 22 Feb 2002 16:15:50 -0800 (PST) Date: Fri, 22 Feb 2002 16:15:48 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: Tony Johansson Cc: AAA Working Group Subject: Re: [AAA-WG]: HA sending AMR In-Reply-To: <3C76D53C.A4ACC6A0@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Tony, > Sivasundar Ramamurthy wrote: > > > Hello, > > > > This is regarding AAA Mobile IP application. > > > > Consider the scenario when a MN returns home and sends a registration > > request to the HA for deregistration. Also, the MN-HA key has expired > > and the MN makes the deregistration request a AAA request. I am > > assuming that no standards prevent the MN using a AAA request for > > deregistration. > > In the scenario that you describe above the MN Keys has expired, which > also means that the MN knows that if it doesn't issues a re-registration > the MN will be de-registered, since the HA will issue an STR to the AAAH. > So why would the MN issue a de-registration in this case? > > /Tony So the MN need not bother to de-register if the key to the HA is expired, since the registration would have been terminated by the HA anyway...that makes sense. Some MN(s) might have a policy to re-request keys much before the keys expire, like re-registering before the previous registration expires. For such MN, it is possible that it is deregistering when its time to re-request keys - a AAA de-registration request! Even in such cases the MN should probably not send the request and simply let the registration terminate on its own... And as far as the HA is concerned, it need not bother to process a de-registration AAA request in case some MN unnecessarily sends it (even with a co-located COA). It will drop such requests and will simply allow the registration to terminate "on its own" (registration lifetime or key lifetime expiration). Thanks for the clarification! Siva From owner-aaa-wg@merit.edu Fri Feb 22 19:22:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02169 for ; Fri, 22 Feb 2002 19:22:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2C1B79125B; Fri, 22 Feb 2002 19:21:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA1BC912E2; Fri, 22 Feb 2002 19:21:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9AD5B9125B for ; Fri, 22 Feb 2002 19:21:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 829615DE08; Fri, 22 Feb 2002 19:21:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 1E91C5DDD8 for ; Fri, 22 Feb 2002 19:21:54 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1N0Lph16759; Fri, 22 Feb 2002 18:21:51 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1N0Lpc17022; Fri, 22 Feb 2002 18:21:51 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA12581; Fri, 22 Feb 2002 18:21:50 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA26361; Fri, 22 Feb 2002 18:21:49 -0600 (CST) Message-ID: <3C76E011.5633D39E@ericsson.com> Date: Fri, 22 Feb 2002 16:19:29 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello Bob and All, To decouple the Authorization-Lifetime and the key lifetime was introduced in issue 186. I've been trying to come up with an explanation to issue 186 and what Bob states below, but the more I think about this the more unsure I become to why we need this decoupling. In the Base we have the Session-Timeout AVP , which contains the maximum number of seconds of service to be provided to the user before termination of the session, and the the Authorization-Lifetime AVP, which contains the maximum number of seconds before a re-auth needs to be done. Unless I've missed something here, I don't see why we introduced a third timer in MIP appl. When the keys are distributed to the MN, FA and HA we also tell the number of seconds they all are valid that, to me, also applies the number of seconds before re-auth, which is exactly the definition of the Authorization-Lifetime AVP. Comments please. /Tony Bob Kopacz wrote: > Hi Tony, > > > Yes I agree, could you please submit a new issue for this. > > So, we don't forget it. > > The above is from an email you sent me on 1-Feb, Subj: "Re: [AAA-WG]: > [issue] Returning AAAF-Generated FA-HA Key to FA", where I had asked a > few questions about the MIP-Key-Lifetime. > > I just now rediscovered that I never did submit this issue. > > However, before I submit an issue about MIP-Key-Lifetime AVP, I want > to get your take on a few further things regarding MIP-Key-Lifetime, > so I can submit a more complete issue. My questions reflect my > ignorance. > > > The following is a numbered list. The "-->" indicates either a > question, or what I believe is the answer. The "-->" things are what > is to be addressed in the pending MIP-Key-Lifetime AVP issue. > > > (1) There is a single MIP-Key-Lifetime AVP which contains the lifetime > that applies to all the keys. > > --> The draft should add the following clarifications: > > "Since the AAAH is the owner of the MN, the AAAH specifies the key > lifetime for the keys it generates as well for as the HA-FA key, if > generated by the destination AAAF. Therefore, even if the AAAH isn't > generating any keys and the only key being generated is the HA-FA key > by the destination AAAF, the AAAH must remember to pass the > MIP-Key-Lifetime AVP in the HAR." > > > (2) Section 1.2 of the mobile-ip draft says: > > | "The expiration time of the > | authorization (and session keys, if allocated by the AAA server) is > | communicated through the Authorization-Lifetime AVP in the AA-Mobile- > | Node-Answer from the AAAH." > > --> The sentence should be rephrased to remove the parenthesized > phrase, or to remove the parenthesized phrase and add the sentence > "The expiration time of the session keys is communicated through the > MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the AAAH." > > > (3) The base draft says a number of things about the Auth-Lifetime > AVP, such as: > > 3a. The relationship of the Auth-Lifetime value and the > Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout > value) > > 3b. The state transitions and actions that take place, for both the > server and the access device, when the Auth-Lifetime (+grace period) > expires. > > 3c. How the client can send the Auth-Lifetime as a "hint" to the server. > > draft-mobileip-08 doesn't say nearly so much about the > MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with "Auth-Lifetime" > replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c above). > > What draft-mobileip-08 says is the following: > > | 6.13 MIP-Key-Lifetime AVP > | > | The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 and > | represents the period of time (in seconds) for which the session key > | is valid. The session key MUST NOT be used if the lifetime has > | expired; if the key lifetime expires while the session to which it > | applies is still active, either the session key MUST be changed or > | the or the session MUST be terminated. > > So ... > > (4) The draft-base-08 says the following things about the > Authorization-Lifetime AVP, and the "-->" indicates that the same > sorts of things should be addressed for the MIP-Key-Lifetime AVP: > > | base-08 Section 2.0 "Protocol Overview" says: > | > | Session state (associated with a Session-Id) MUST be freed upon > | receipt of the Session-Termination-Request, Session-Termination- > | Answer, expiration of authorized service time in the Session-Timeout > | AVP, and according to rules established in a particular Diameter > | application. > | > | > | base-08 Section 8.1 "Authorization Session State Machine" says: > | > | Open Authorization-Lifetime (and Cleanup Discon > | Auth-Grace-Period) expires > | on home server. > | > | Open Session-Timeout expires on Cleanup Discon > | home server > | > | Open Authorization-Lifetime + send STR Discon > | Auth-Grace-Period expires on > | access device > | > | Open Session-Timeout Expires on send STR Discon > | Access Device > > --> draft-mobileip should specify the actions of both the server and > the access device when the MIP-Key-Lifetime AVP expires. Presumably > the access device should send an STR, while the server quietly cleans > out the session. > > --> should draft-mobileip (and the other application > drafts) add an "Authorization Session State Machine" and > "Accounting Session State Machine" section, indicating > application-specific extensions to the base state machine? > e.g. mobileip-08 would add > "Open Key-Lifetime Expires on Access Device send STR Discon" > > --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so, is > a new MIP-Key-Lifetime-Grace-Period AVP needed? > > | base-08 Section 8.4 "Session Termination" says: > | > | A Diameter server also MUST clean up resources when the Session- > | Timeout expires, or when the Authorization-Lifetime and the Auth- > | Grace-Period AVPs expires without receipt of a re-authorization > | request, regardless of whether an STR for that session is received. > | The access device is not expected to provide service beyond the > | expiration of these timers; thus, expiration of either of these > | timers implies that the access device may have unexpectedly shut > | down. > | > | base-08 Section 8.9 "Authorization-Lifetime AVP" says: > | > | If both this AVP and the Session-Timeout AVP are present in a > | message, the value of the latter MUST NOT be smaller than the > | Authorization-Lifetime AVP. > | > | This AVP MAY be provided by the client as a hint of the maximum > | lifetime that it is willing to accept. However, the server MAY return > | a value that is equal to, or smaller, than the one provided by the > | client. > > --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ? > > --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as > some sort of hint? > > | base-08 Section 8.12 "Re-Auth-Request-Type AVP" says: > | > | The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and > | is included in application-specific auth answers to inform the client > | of the action expected upon expiration of the Authorization-Lifetime. > | The following values are defined: > | > | AUTHORIZE_ONLY 0 > | An authorization only re-auth is expected upon expiration of > | the Authorization-Lifetime. This is the default value if the > | AVP is not present in answer messages that include the > | Authorization-Lifetime. > | > | AUTHORIZE_AUTHENTICATE 1 > | An authentication and authorization re-auth is expected upon > | expiration of the Authorization-Lifetime. > > --> Should the server convey something akin to the above, to tell the > client what action to take upon MIP-Key-Lifetime expiration? Can the > client request a "key refresh"? > > Bob K. From owner-aaa-wg@merit.edu Fri Feb 22 19:47:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02591 for ; Fri, 22 Feb 2002 19:47:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4C3C79125D; Fri, 22 Feb 2002 19:46:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17DED912E2; Fri, 22 Feb 2002 19:46:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03B4D9125D for ; Fri, 22 Feb 2002 19:46:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCF275DDD8; Fri, 22 Feb 2002 19:46:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 0BEFA5DDD0 for ; Fri, 22 Feb 2002 19:46:52 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020223004650.CAL22932.fep02-svc.swip.net@ipunplugged.com>; Sat, 23 Feb 2002 01:46:50 +0100 Message-ID: <3C76F4AE.2080103@ipunplugged.com> Date: Sat, 23 Feb 2002 01:47:26 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Johansson Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP References: <3C76E011.5633D39E@ericsson.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 Tony Johansson wrote: >Hello Bob and All, > >To decouple the Authorization-Lifetime and the key lifetime was introduced in >issue 186. I've been trying to come up with an explanation to issue 186 and >what Bob states below, but the more I think about this the more unsure I >become to why we need this decoupling. > What was the reason that the key lifetime was introduced in the first place? Was it to provide the possibility to allow some keys to live longer than others? I have a vague memory of a vague impression through Fredrik (any misinterpretations are of course mine) that this might be the case. Unfortunately this would mean that key life times need to be multiples of the mobile node's keys since the client can't make a spontaneous reauthentication and so I think the decision was made to move it from the individual keys and only allow one per AMA. >In the Base we have the Session-Timeout AVP , which contains the maximum >number of seconds of service to be provided to >the user before termination of the session, and the the >Authorization-Lifetime AVP, which contains the maximum number of seconds >before a re-auth needs to be done. > Is it correct that 4s before Session-Timeout we could reauthenticate and get an authorization life time of 300s? j From owner-aaa-wg@merit.edu Fri Feb 22 20:05:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02967 for ; Fri, 22 Feb 2002 20:05:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 792B2912E2; Fri, 22 Feb 2002 20:05:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4281D912E3; Fri, 22 Feb 2002 20:05:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C8AC912E2 for ; Fri, 22 Feb 2002 20:05:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0AE345DE08; Fri, 22 Feb 2002 20:05:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id 85F025DDD0 for ; Fri, 22 Feb 2002 20:05:00 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at client62-2-82-80.hispeed.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@62.2.82.80) by smtp.mail.vip.sc5.yahoo.com with SMTP; 23 Feb 2002 01:04:59 -0000 Message-Id: <5.1.0.14.0.20020223015515.03921090@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 23 Feb 2002 02:03:50 +0100 To: David Spence From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: AAA Working Group In-Reply-To: <3C7693EE.194EC2FA@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I agree that the use of DiameterIdentity as it currently stands is a bad idea. See my mail from last august: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html which became issue #114. The decision at the time as that the "protocol worked fine as it was". I still think separating URIs (used to reference another host) and identities (to uniquely identify a host, e.g. for CER/CEA purposes) would make things a lot simpler, especially with the complexity Diameter URIs have gotten into... Jacques. At 19:54 22/02/2002, David Spence wrote: >Subject: [issue] AAA URI is Overloaded > >Submitter name: David Spence >Submitter email address: DSpence@Interlinknetworks.com >Date first submitted: 2/21/02 >Reference: >Document: Base >Comment type: T >Priority: S >Section: 4.4 >Rationale/Explanation of issue: > > Some Background > --------------- > > The AAA URI provides two different kinds of information. > > 1. It identifies a Diameter node. A Diameter node is a Diameter > process running on some host or device. It is possible to have > more than one Diameter process running on a host. > > 2. It provides information about how to connect to the Diameter node > -- what transport protocol to use, what transport level security > to use, and even what AAA protocol to use (although we are only > concerned about one, namely Diameter). > > The AAA URI also serves two different purposes. > > 1. It is used in the peer-to-peer protocol to identify a peer and > indicate certain parameters concerning how to connect to that > peer. This use requires the full URI including the prefix, the > fqdn, the port number, and the options. A URI for this purpose > may be stored in a local configuration file or on a remote server > to enable dynamic peer discovery (see sec. 5.2). > > 2. It is used in the Diameter routing and forwarding decisions to > identify the Diameter node to which a Diameter message is > addressed. This use requires those portions of the URI that > identify the Diameter node but does not require (and can be > confused by) the information about how to connect to the node as a > peer. This is the use made of the URI as transmitted in all AVPs > of type DiameterIdentity. > > > The Problem > ----------- > > The problem is that the URI format is currently defined in only one > place (sec. 4.4 under the "DiameterIdentity" type) and makes no > distinction between its use for the two different purposes described > above. > > > Operational Difficulties if the Problem Isn't Fixed > --------------------------------------------------- > > Section 4.4 states: > > Unless a Diameter node is sitting on the border of two routing > domains (e.g. private and public), a Diameter node MUST > advertise the same identity on all connections, via the CER > and CEA's Origin-Host AVP. > > Suppose a Diameter node has two peers. It connects to the first peer > using SCTP. It connects to the second peer using TCP. In order to > obey this requirement, the node would have to include the string > "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA > message to the second peer even though it is using TCP to connect to > that peer. So the identity advertised is not the identity used. > This seems odd, but as we shall see, it is actually necessary in order > to make the routing mechanism work. > > Section 4.4 goes on to state: > > The same identity advertised in a connection's CER and CEA MUST > be used in any AVP of type DiameterIdentity sent on that > connection. > > Now suppose an implementor misses the oddity required by the first > sentence and does the obvious thing -- suppose the implementation > always includes in the CER the parameters actually in use on the peer > connection. Then the implementation will have a very hard time > meeting this requirement too. It would have to know how it will > route the message at the time it generates the message, a horrible > violation of modularity. Supposing it does know how it will route > the message and sets the value of the Origin-Host AVP in the message > to the same value used in the CER or CEA sent to the peer to which it > will route it. Now suppose something goes wrong when sending the > message to this peer, and the message is subsequently retransmitted > to a backup peer. Oops. Now the Origin-Host AVP is wrong for that > connection and it can't be changed. > > So we'll just have to assume that all implementors pick up on the > oddity. But wait -- we're still not out of the woods. Suppose, at > the time a session begins, the Diameter client supporting the session > uses TCP on its peer link. So it includes the string "transport=tcp" > in the auth request that begins the session. Suppose that several > hours later the session is still in progress, but the client has > reinitialized its peer link and is now using SCTP. Now suppose the > home server sends an Abort-Session-Request message to the client for > this session. The Abort-Session-Request will include a > Destination-Host AVP that contains the string "transport=tcp". The > message eventually reaches the peer connected to the client. The > peer matches the URI in the Destination-Host AVP with the ones in its > peer table. It finds no match because "transport=tcp" does not match > "transport=sctp". So it discards the message. > > > Interaction With Issue 273 > -------------------------- > > Another issue urges that Diameter nodes not use different port > numbers for TLS versus non-TLS connections. I am guessing that issue > 273 is the one that encompasses this change. The question of port > number use for TLS versus non-TLS was raised by Allison Mankin in: > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html > > The outcome of issue 273 (if that is the issue that includes this > question) is critical to the resolution of this issue as well. The > reason is that we use the combination of fqdn and port number to > identify a diameter node. If more than one Diameter node (Diameter > daemon) runs on a host, they will use different port numbers. But if > a Diameter node listens on more than one port number, then it may use > two different URIs and there will be no way for a peer to know that > the URI from the Destination-Host AVP of a message it is routing > matches the URI of one of its peers if the port number differs. > > John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS > is used in: > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html > > If this suggestion is adopted, then the "s" in aaas: will need to be > ignored when doing routing matches against entries in the peer table. > > >Requested change: > > Define the format of the URI somewhere other than section 4.4. In > the definition of the DiameterIdentity type in section 4.4, specify > that only the prefix, fqdn, and port number portions of the URI are > included in AVP value fields of this type. The sentences cited above > may now be left in section 4.4 because they no longer cause a > problem. > > If the resolution of issue 273 allows a Diameter node to listen on > different ports for TLS vs. non-TLS connections, then section 4.4 > needs to emphasize that a single port number MUST be used in all AVPs > of type DiameterIdentity. If the resolution of 273 requires use of > the same port for TLS and non-TLS connections, then it would still be > a good idea to include text in section 4.4 following the first > sentence cited above that emphasizes that the same port number MUST > be used in all AVPs of type DiameterIdentity even if a peer > connection request was received on a different port. > > If the URI prefix may either be aaa: or aaas: depending on transport > security, then text should be added to section 6 stating that when > matching URIs for routing purposes, the "s" in aaas: should be > dropped before the compare is made. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Feb 22 21:29:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03999 for ; Fri, 22 Feb 2002 21:29:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1C33091236; Fri, 22 Feb 2002 21:29:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8241912C4; Fri, 22 Feb 2002 21:29:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CBDCD91236 for ; Fri, 22 Feb 2002 21:29:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9D95C5DDD0; Fri, 22 Feb 2002 21:29:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 0522E5DDAF for ; Fri, 22 Feb 2002 21:29:16 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SASQ>; Fri, 22 Feb 2002 18:29:15 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Tony Johansson'" , Bob Kopacz Cc: aaa-wg Subject: RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP Date: Fri, 22 Feb 2002 18:29:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BC11.DE1AAA80" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BC11.DE1AAA80 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If memory serves, Glen Z can provide more info, but tying the authorization lifetime to the key lifetime were considered inappropriate. It is possible to have a key that spans many authorization lifetimes (and the protocol does allow requesting authorization without a key). However, if memory serves this issue spawned from the NASREQ document. PatC - -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Friday, February 22, 2002 4:19 PM To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP Hello Bob and All, To decouple the Authorization-Lifetime and the key lifetime was introduced in issue 186. I've been trying to come up with an explanation to issue 186 and what Bob states below, but the more I think about this the more unsure I become to why we need this decoupling. In the Base we have the Session-Timeout AVP , which contains the maximum number of seconds of service to be provided to the user before termination of the session, and the the Authorization-Lifetime AVP, which contains the maximum number of seconds before a re-auth needs to be done. Unless I've missed something here, I don't see why we introduced a third timer in MIP appl. When the keys are distributed to the MN, FA and HA we also tell the number of seconds they all are valid that, to me, also applies the number of seconds before re-auth, which is exactly the definition of the Authorization-Lifetime AVP. Comments please. /Tony Bob Kopacz wrote: > Hi Tony, > > > Yes I agree, could you please submit a new issue for this. So, we > > don't forget it. > > The above is from an email you sent me on 1-Feb, Subj: "Re: > [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA", where > I had asked a few questions about the MIP-Key-Lifetime. > > I just now rediscovered that I never did submit this issue. > > However, before I submit an issue about MIP-Key-Lifetime AVP, I > want to get your take on a few further things regarding > MIP-Key-Lifetime, so I can submit a more complete issue. My > questions reflect my > ignorance. > > > The following is a numbered list. The "-->" indicates either a > question, or what I believe is the answer. The "-->" things are > what is to be addressed in the pending MIP-Key-Lifetime AVP issue. > > > (1) There is a single MIP-Key-Lifetime AVP which contains the > lifetime that applies to all the keys. > > --> The draft should add the following clarifications: > > "Since the AAAH is the owner of the MN, the AAAH specifies the > key > lifetime for the keys it generates as well for as the HA-FA > key, if > generated by the destination AAAF. Therefore, even if the AAAH > isn't > generating any keys and the only key being generated is the > HA-FA key > by the destination AAAF, the AAAH must remember to pass the > MIP-Key-Lifetime AVP in the HAR." > > > (2) Section 1.2 of the mobile-ip draft says: > > | "The expiration time of the > | authorization (and session keys, if allocated by the AAA server) > | is communicated through the Authorization-Lifetime AVP in the > | AA-Mobile- Node-Answer from the AAAH." > > --> The sentence should be rephrased to remove the parenthesized > phrase, or to remove the parenthesized phrase and add the sentence > "The expiration time of the session keys is communicated through > the MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the > AAAH." > > > (3) The base draft says a number of things about the Auth-Lifetime > AVP, such as: > > 3a. The relationship of the Auth-Lifetime value and the > Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout > value) > > 3b. The state transitions and actions that take place, for both > the server and the access device, when the Auth-Lifetime (+grace > period) expires. > > 3c. How the client can send the Auth-Lifetime as a "hint" to the > server. > > draft-mobileip-08 doesn't say nearly so much about the > MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with > "Auth-Lifetime" replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c > above). > > What draft-mobileip-08 says is the following: > > | 6.13 MIP-Key-Lifetime AVP > | > | The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 > | and represents the period of time (in seconds) for which the > | session key is valid. The session key MUST NOT be used if the > | lifetime has expired; if the key lifetime expires while the > | session to which it applies is still active, either the session > | key MUST be changed or the or the session MUST be terminated. > > So ... > > (4) The draft-base-08 says the following things about the > Authorization-Lifetime AVP, and the "-->" indicates that the same > sorts of things should be addressed for the MIP-Key-Lifetime AVP: > > | base-08 Section 2.0 "Protocol Overview" says: > | > | Session state (associated with a Session-Id) MUST be freed upon > | receipt of the Session-Termination-Request, Session-Termination- > | Answer, expiration of authorized service time in the > | Session-Timeout AVP, and according to rules established in a > | particular Diameter application. > | > | > | base-08 Section 8.1 "Authorization Session State Machine" says: > | > | Open Authorization-Lifetime (and Cleanup Discon > | Auth-Grace-Period) expires > | on home server. > | > | Open Session-Timeout expires on Cleanup Discon > | home server > | > | Open Authorization-Lifetime + send STR Discon > | Auth-Grace-Period expires on > | access device > | > | Open Session-Timeout Expires on send STR Discon > | Access Device > > --> draft-mobileip should specify the actions of both the server > and the access device when the MIP-Key-Lifetime AVP expires. > Presumably the access device should send an STR, while the server > quietly cleans out the session. > > --> should draft-mobileip (and the other application > drafts) add an "Authorization Session State Machine" and > "Accounting Session State Machine" section, indicating > application-specific > extensions to the base state machine? e.g. mobileip-08 would add > "Open Key-Lifetime Expires on Access Device send STR Discon" > > --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so, > is a new MIP-Key-Lifetime-Grace-Period AVP needed? > > | base-08 Section 8.4 "Session Termination" says: > | > | A Diameter server also MUST clean up resources when the Session- > | Timeout expires, or when the Authorization-Lifetime and the > | Auth- Grace-Period AVPs expires without receipt of a > | re-authorization request, regardless of whether an STR for that > | session is received. The access device is not expected to > | provide service beyond the expiration of these timers; thus, > | expiration of either of these timers implies that the access > | device may have unexpectedly shut down. > | > | base-08 Section 8.9 "Authorization-Lifetime AVP" says: > | > | If both this AVP and the Session-Timeout AVP are present in a > | message, the value of the latter MUST NOT be smaller than the > | Authorization-Lifetime AVP. > | > | This AVP MAY be provided by the client as a hint of the maximum > | lifetime that it is willing to accept. However, the server MAY > | return a value that is equal to, or smaller, than the one > | provided by the client. > > --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ? > > --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as > some sort of hint? > > | base-08 Section 8.12 "Re-Auth-Request-Type AVP" says: > | > | The Re-Auth-Request-Type AVP (AVP Code 285) is of type > | Enumerated and is included in application-specific auth answers > | to inform the client of the action expected upon expiration of > | the > | Authorization-Lifetime. The following values are defined: > | > | AUTHORIZE_ONLY 0 > | An authorization only re-auth is expected upon expiration > | of > | the Authorization-Lifetime. This is the default value if > | the > | AVP is not present in answer messages that include the > | Authorization-Lifetime. > | > | AUTHORIZE_AUTHENTICATE 1 > | An authentication and authorization re-auth is expected > | upon > | expiration of the Authorization-Lifetime. > > --> Should the server convey something akin to the above, to tell > the client what action to take upon MIP-Key-Lifetime expiration? > Can the client request a "key refresh"? > > Bob K. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHb+cTN1fXKoxmisEQKHpACfZ3o3rm/fqEBL9DyJ7GmcTyT4ep0AoMwA vkpp6LB9mVPym6M5ORY/ESQd =0Eq7 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BC11.DE1AAA80 Content-Type: text/html RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If memory serves, Glen Z can provide more info, but tying the
authorization lifetime to the key lifetime were considered
inappropriate. It is possible to have a key that spans many
authorization lifetimes (and the protocol does allow requesting
authorization without a key).

However, if memory serves this issue spawned from the NASREQ
document.

PatC

- -----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Friday, February 22, 2002 4:19 PM
To: Bob Kopacz
Cc: aaa-wg
Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP


Hello Bob and All,

To decouple the Authorization-Lifetime and the key lifetime was
introduced in issue 186.  I've been trying to come up with an
explanation to issue 186 and what Bob states below, but the more I
think about this the more unsure I become to why we need this
decoupling.

In the Base we have the Session-Timeout AVP , which contains the
maximum number of seconds of service to be provided to the user
before termination of the session, and the the Authorization-Lifetime
AVP, which contains the maximum number of seconds before a re-auth
needs to be done. Unless I've missed something here, I don't see why
we introduced a third timer in MIP appl.

When the keys are distributed to the MN, FA and HA we also tell the
number of seconds they all are valid that, to me, also applies the
number of seconds before re-auth, which is exactly the definition of
the Authorization-Lifetime AVP.

Comments please.

/Tony

Bob Kopacz wrote:

> Hi Tony,
>
> > Yes I agree, could you please submit a new issue for this. So, we
> >  don't forget it.
>
> The above is from an email you sent me on 1-Feb, Subj: "Re:
> [AAA-WG]:  [issue] Returning AAAF-Generated FA-HA Key to FA", where
> I had asked a  few questions about the MIP-Key-Lifetime.
>
> I just now rediscovered that I never did submit this issue.
>
> However, before I submit an issue about MIP-Key-Lifetime AVP, I
> want  to get your take on a few further things regarding
> MIP-Key-Lifetime,  so I can submit a more complete issue.  My
> questions reflect my
> ignorance.
>
>
> The following is a numbered list.  The "-->" indicates either a
> question, or what I believe is the answer.  The "-->" things are
> what  is to be addressed in the pending MIP-Key-Lifetime AVP issue.
>
>
> (1) There is a single MIP-Key-Lifetime AVP which contains the
> lifetime  that applies to all the keys.
>
> --> The draft should add the following clarifications:
>
>     "Since the AAAH is the owner of the MN, the AAAH specifies the
> key
>     lifetime for the keys it generates as well for as the HA-FA
> key, if
>     generated by the destination AAAF.  Therefore, even if the AAAH
> isn't
>     generating any keys and the only key being generated is the
> HA-FA key
>     by the destination AAAF, the AAAH must remember to pass the
>     MIP-Key-Lifetime AVP in the HAR."
>
>
> (2) Section 1.2 of the mobile-ip draft says:
>
> |  "The expiration time of the
> |  authorization (and session keys, if allocated by the AAA server)
> | is   communicated through the Authorization-Lifetime AVP in the
> | AA-Mobile-  Node-Answer from the AAAH."
>
> --> The sentence should be rephrased to remove the parenthesized
> phrase, or to remove the parenthesized phrase and add the sentence
> "The expiration time of the session keys is communicated through
> the  MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the
> AAAH."
>
>
> (3) The base draft says a number of things about the Auth-Lifetime
> AVP, such as:
>
> 3a.  The relationship of the Auth-Lifetime value and the
> Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout
> value)
>
> 3b.  The state transitions and actions that take place, for both
> the  server and the access device, when the Auth-Lifetime (+grace
> period)  expires.
>
> 3c.  How the client can send the Auth-Lifetime as a "hint" to the
> server.
>
> draft-mobileip-08 doesn't say nearly so much about the
> MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with
> "Auth-Lifetime"  replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c
> above).
>
> What draft-mobileip-08 says is the following:
>
> |  6.13 MIP-Key-Lifetime AVP
> |
> |  The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32
> | and   represents the period of time (in seconds) for which the
> | session key   is valid.  The session key MUST NOT be used if the
> | lifetime has   expired; if the key lifetime expires while the
> | session to which it   applies is still active, either the session
> | key MUST be changed or   the or the session MUST be terminated.
>
> So ...
>
> (4) The draft-base-08 says the following things about the
> Authorization-Lifetime AVP, and the "-->" indicates that the same
> sorts of things should be addressed for the MIP-Key-Lifetime AVP:
>
> |  base-08 Section 2.0 "Protocol Overview" says:
> |
> |  Session state (associated with a Session-Id) MUST be freed upon
> |  receipt of the Session-Termination-Request, Session-Termination-
> |   Answer, expiration of authorized service time in the
> | Session-Timeout   AVP, and according to rules established in a
> | particular Diameter   application.
> |
> |
> |  base-08 Section 8.1 "Authorization Session State Machine" says:
> |
> |     Open      Authorization-Lifetime (and    Cleanup    Discon
> |               Auth-Grace-Period) expires
> |               on home server.
> |
> |     Open      Session-Timeout expires on     Cleanup    Discon
> |               home server
> |
> |     Open      Authorization-Lifetime +       send STR   Discon
> |               Auth-Grace-Period expires on
> |               access device
> |
> |     Open      Session-Timeout Expires on     send STR   Discon
> |               Access Device
>
> --> draft-mobileip should specify the actions of both the server
> and the access device when the MIP-Key-Lifetime AVP expires.
> Presumably  the access device should send an STR, while the server
> quietly cleans  out the session.
>
> --> should draft-mobileip (and the other application
> drafts) add an "Authorization Session State Machine" and
> "Accounting  Session State Machine" section, indicating
> application-specific
> extensions to the base state machine? e.g. mobileip-08 would add
> "Open  Key-Lifetime Expires on Access Device  send STR Discon"
>
> --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so,
> is a new MIP-Key-Lifetime-Grace-Period AVP needed?
>
> |  base-08 Section 8.4 "Session Termination" says:
> |
> |  A Diameter server also MUST clean up resources when the Session-
> |   Timeout expires, or when the Authorization-Lifetime and the
> | Auth-   Grace-Period AVPs expires without receipt of a
> | re-authorization   request, regardless of whether an STR for that
> | session is received.   The access device is not expected to
> | provide service beyond the   expiration of these timers; thus,
> | expiration of either of these   timers implies that the access
> | device may have unexpectedly shut   down.
> |
> |  base-08 Section 8.9 "Authorization-Lifetime AVP" says:
> |
> |  If both this AVP and the Session-Timeout AVP are present in a 
> | message, the value of the latter MUST NOT be smaller than the 
> | Authorization-Lifetime AVP.
> |
> |  This AVP MAY be provided by the client as a hint of the maximum
> |  lifetime that it is willing to accept. However, the server MAY
> | return  a value that is equal to, or smaller, than the one
> | provided  by the  client.
>
> --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ?
>
> --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as
> some sort of hint?
>
> |  base-08 Section 8.12 "Re-Auth-Request-Type AVP" says:
> |
> |  The Re-Auth-Request-Type AVP (AVP Code 285) is of type
> | Enumerated  and  is included in application-specific auth answers
> | to inform the  client  of the action expected upon expiration of
> | the
> | Authorization-Lifetime.  The following values are defined:
> |
> |     AUTHORIZE_ONLY             0
> |        An authorization only re-auth is expected upon expiration
> | of
> |        the Authorization-Lifetime. This is the default value if
> | the
> |        AVP is not present in answer messages that include the
> |        Authorization-Lifetime.
> |
> |     AUTHORIZE_AUTHENTICATE     1
> |        An authentication and authorization re-auth is expected
> | upon
> |        expiration of the Authorization-Lifetime.
>
> --> Should the server convey something akin to the above, to tell
> the client what action to take upon MIP-Key-Lifetime expiration?
> Can the  client request a "key refresh"?
>
> Bob K.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPHb+cTN1fXKoxmisEQKHpACfZ3o3rm/fqEBL9DyJ7GmcTyT4ep0AoMwA
vkpp6LB9mVPym6M5ORY/ESQd
=0Eq7
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BC11.DE1AAA80-- From owner-aaa-wg@merit.edu Sat Feb 23 01:24:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08608 for ; Sat, 23 Feb 2002 01:24:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A85D791237; Sat, 23 Feb 2002 01:24:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C1E6912C4; Sat, 23 Feb 2002 01:24:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A05F91237 for ; Sat, 23 Feb 2002 01:24:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 496595DDF9; Sat, 23 Feb 2002 01:24:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 5BC605DDEC for ; Sat, 23 Feb 2002 01:24:11 -0500 (EST) Received: (qmail 27013 invoked by uid 500); 23 Feb 2002 06:24:10 -0000 Date: Sat, 23 Feb 2002 00:24:10 -0600 From: David Frascone To: Jacques Caron Cc: David Spence , AAA Working Group Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Message-ID: <20020223062410.GQ26340@newman.frascone.com> Mail-Followup-To: Jacques Caron , David Spence , AAA Working Group References: <3C7693EE.194EC2FA@Interlinknetworks.com> <5.1.0.14.0.20020223015515.03921090@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.0.20020223015515.03921090@pop.mail.yahoo.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Plus, implementations need to keep track of ipaddress+port to track incomming connections too. Since URIs can be spoofed, when a server gets a connection, all it really knows is an IP address + port. And, the IP address might not have reverse resolution to anything meaningful :( -Dave On Saturday, 23 Feb 2002, Jacques Caron wrote: > Hi, > > I agree that the use of DiameterIdentity as it currently stands is a bad > idea. See my mail from last august: > > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html > > which became issue #114. The decision at the time as that the "protocol > worked fine as it was". > > I still think separating URIs (used to reference another host) and > identities (to uniquely identify a host, e.g. for CER/CEA purposes) would > make things a lot simpler, especially with the complexity Diameter URIs > have gotten into... > > Jacques. > > At 19:54 22/02/2002, David Spence wrote: > >Subject: [issue] AAA URI is Overloaded > > > >Submitter name: David Spence > >Submitter email address: DSpence@Interlinknetworks.com > >Date first submitted: 2/21/02 > >Reference: > >Document: Base > >Comment type: T > >Priority: S > >Section: 4.4 > >Rationale/Explanation of issue: > > > > Some Background > > --------------- > > > > The AAA URI provides two different kinds of information. > > > > 1. It identifies a Diameter node. A Diameter node is a Diameter > > process running on some host or device. It is possible to have > > more than one Diameter process running on a host. > > > > 2. It provides information about how to connect to the Diameter node > > -- what transport protocol to use, what transport level security > > to use, and even what AAA protocol to use (although we are only > > concerned about one, namely Diameter). > > > > The AAA URI also serves two different purposes. > > > > 1. It is used in the peer-to-peer protocol to identify a peer and > > indicate certain parameters concerning how to connect to that > > peer. This use requires the full URI including the prefix, the > > fqdn, the port number, and the options. A URI for this purpose > > may be stored in a local configuration file or on a remote server > > to enable dynamic peer discovery (see sec. 5.2). > > > > 2. It is used in the Diameter routing and forwarding decisions to > > identify the Diameter node to which a Diameter message is > > addressed. This use requires those portions of the URI that > > identify the Diameter node but does not require (and can be > > confused by) the information about how to connect to the node as a > > peer. This is the use made of the URI as transmitted in all AVPs > > of type DiameterIdentity. > > > > > > The Problem > > ----------- > > > > The problem is that the URI format is currently defined in only one > > place (sec. 4.4 under the "DiameterIdentity" type) and makes no > > distinction between its use for the two different purposes described > > above. > > > > > > Operational Difficulties if the Problem Isn't Fixed > > --------------------------------------------------- > > > > Section 4.4 states: > > > > Unless a Diameter node is sitting on the border of two routing > > domains (e.g. private and public), a Diameter node MUST > > advertise the same identity on all connections, via the CER > > and CEA's Origin-Host AVP. > > > > Suppose a Diameter node has two peers. It connects to the first peer > > using SCTP. It connects to the second peer using TCP. In order to > > obey this requirement, the node would have to include the string > > "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA > > message to the second peer even though it is using TCP to connect to > > that peer. So the identity advertised is not the identity used. > > This seems odd, but as we shall see, it is actually necessary in order > > to make the routing mechanism work. > > > > Section 4.4 goes on to state: > > > > The same identity advertised in a connection's CER and CEA MUST > > be used in any AVP of type DiameterIdentity sent on that > > connection. > > > > Now suppose an implementor misses the oddity required by the first > > sentence and does the obvious thing -- suppose the implementation > > always includes in the CER the parameters actually in use on the peer > > connection. Then the implementation will have a very hard time > > meeting this requirement too. It would have to know how it will > > route the message at the time it generates the message, a horrible > > violation of modularity. Supposing it does know how it will route > > the message and sets the value of the Origin-Host AVP in the message > > to the same value used in the CER or CEA sent to the peer to which it > > will route it. Now suppose something goes wrong when sending the > > message to this peer, and the message is subsequently retransmitted > > to a backup peer. Oops. Now the Origin-Host AVP is wrong for that > > connection and it can't be changed. > > > > So we'll just have to assume that all implementors pick up on the > > oddity. But wait -- we're still not out of the woods. Suppose, at > > the time a session begins, the Diameter client supporting the session > > uses TCP on its peer link. So it includes the string "transport=tcp" > > in the auth request that begins the session. Suppose that several > > hours later the session is still in progress, but the client has > > reinitialized its peer link and is now using SCTP. Now suppose the > > home server sends an Abort-Session-Request message to the client for > > this session. The Abort-Session-Request will include a > > Destination-Host AVP that contains the string "transport=tcp". The > > message eventually reaches the peer connected to the client. The > > peer matches the URI in the Destination-Host AVP with the ones in its > > peer table. It finds no match because "transport=tcp" does not match > > "transport=sctp". So it discards the message. > > > > > > Interaction With Issue 273 > > -------------------------- > > > > Another issue urges that Diameter nodes not use different port > > numbers for TLS versus non-TLS connections. I am guessing that issue > > 273 is the one that encompasses this change. The question of port > > number use for TLS versus non-TLS was raised by Allison Mankin in: > > > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html > > > > The outcome of issue 273 (if that is the issue that includes this > > question) is critical to the resolution of this issue as well. The > > reason is that we use the combination of fqdn and port number to > > identify a diameter node. If more than one Diameter node (Diameter > > daemon) runs on a host, they will use different port numbers. But if > > a Diameter node listens on more than one port number, then it may use > > two different URIs and there will be no way for a peer to know that > > the URI from the Destination-Host AVP of a message it is routing > > matches the URI of one of its peers if the port number differs. > > > > John Loughney suggested use of aaa: vs. aaas: to indicate whether TLS > > is used in: > > > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html > > > > If this suggestion is adopted, then the "s" in aaas: will need to be > > ignored when doing routing matches against entries in the peer table. > > > > > >Requested change: > > > > Define the format of the URI somewhere other than section 4.4. In > > the definition of the DiameterIdentity type in section 4.4, specify > > that only the prefix, fqdn, and port number portions of the URI are > > included in AVP value fields of this type. The sentences cited above > > may now be left in section 4.4 because they no longer cause a > > problem. > > > > If the resolution of issue 273 allows a Diameter node to listen on > > different ports for TLS vs. non-TLS connections, then section 4.4 > > needs to emphasize that a single port number MUST be used in all AVPs > > of type DiameterIdentity. If the resolution of 273 requires use of > > the same port for TLS and non-TLS connections, then it would still be > > a good idea to include text in section 4.4 following the first > > sentence cited above that emphasizes that the same port number MUST > > be used in all AVPs of type DiameterIdentity even if a peer > > connection request was received on a different port. > > > > If the URI prefix may either be aaa: or aaas: depending on transport > > security, then text should be added to section 6 stating that when > > matching URIs for routing purposes, the "s" in aaas: should be > > dropped before the compare is made. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > From owner-aaa-wg@merit.edu Sat Feb 23 11:19:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21353 for ; Sat, 23 Feb 2002 11:19:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 84E139123B; Sat, 23 Feb 2002 11:19:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4EC959123C; Sat, 23 Feb 2002 11:19:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AD4C9123B for ; Sat, 23 Feb 2002 11:19:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E45A5DE2B; Sat, 23 Feb 2002 11:19:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 25BCF5DDA0 for ; Sat, 23 Feb 2002 11:19:04 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id F3E7B7E; Sat, 23 Feb 2002 11:19:03 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: Question about where FA sends STR (draft-mobileip-08) Date: Sat, 23 Feb 2002 11:18:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's a couple questions regarding the sending of Session-Termination-Request messages by the FA and HA. Question#1: Does the FA, when sending an STR, send it to his local AAAF or to the AAAH? The draft-mobileip-08 is inconsistent. Here's the story: base-08, section 8.4 "Session Termination", says the FA's STR goes to the AAAH: | When a user session that required Diameter authorization terminates, | the access device that provided the service MUST issue a Session- | Termination- Request (STR) message to the Diameter server that | authorized the service. mobileip-08, figure 3, shows the FA's STR going to the AAAH: | STR, Session-Id = foo STR, Session-Id = bar | ---------------------> <-------------------- | +----+ +------+ +------+ +----+ | | FA | | AAAF | | AAAH | | HA | | +----+ +------+ +------+ +----+ | <--------------------- ---------------------> | STA, Session-Id = foo STA, Session-Id = bar | Figure 3: Session Termination and Session Identifiers mobileip-08, section 1.6 "Diameter Session Termination", says the FA's STR goes to his AAAF: | In order for the | Diameter Server to release any resources allocated to a specific | mobile node, the mobility agents MUST send a Session-Termination- | Request (STR) to their respective Diameter servers. Possible follow up to question#1: If the FA's STR is to be sent to his AAAF, how does the FA determine the DiameterIdentity of the AAAF (to send as the value of the STR's Destionation-Host AVP)? Question#2: If a server receives an STR for an unknown session, does the server return an STA(Result-Code=Success) or an STA(Result-Code=Unknown-Session-Id)? I would think STA(Result-Code=Success) because of timing. The server and MA may have simulateously timed out a session, the MA's STR arrives soon after. Or a previous FA sends an STR after a handoff to a new FA. That sort of thing. Bob K. From owner-aaa-wg@merit.edu Sat Feb 23 15:01:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23386 for ; Sat, 23 Feb 2002 15:01:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D4EE791207; Sat, 23 Feb 2002 15:00:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 849099120A; Sat, 23 Feb 2002 15:00:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C8E091207 for ; Sat, 23 Feb 2002 15:00:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 335495DD99; Sat, 23 Feb 2002 15:00:22 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 502DB5DE3E for ; Sat, 23 Feb 2002 15:00:20 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1NK0JS16955; Sat, 23 Feb 2002 14:00:19 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1NK0Jc01630; Sat, 23 Feb 2002 14:00:19 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA18006; Sat, 23 Feb 2002 14:00:18 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA06897; Sat, 23 Feb 2002 14:00:17 -0600 (CST) Message-ID: <3C77F443.8077F8FE@ericsson.com> Date: Sat, 23 Feb 2002 11:57:55 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: Question about where FA sends STR (draft-mobileip-08) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, It should be as state in Base-08 and as in figure 3 in mobileip-08. Thus, the STR is issued to the Diameter server that authorized the service. I'll go ahead and submit an issue and propose new text in mobileip-08, section 1.6 and ask for wg consensus. Thanks, /Tony Bob Kopacz wrote: > Hi Tony, > > Here's a couple questions regarding the sending of > Session-Termination-Request messages by the FA and HA. > > Question#1: Does the FA, when sending an STR, send it to his local > AAAF or to the AAAH? The draft-mobileip-08 is inconsistent. Here's > the story: > > base-08, section 8.4 "Session Termination", says the FA's STR goes to > the AAAH: > > | When a user session that required Diameter authorization terminates, > | the access device that provided the service MUST issue a Session- > | Termination- Request (STR) message to the Diameter server that > | authorized the service. > > mobileip-08, figure 3, shows the FA's STR going to the AAAH: > > | STR, Session-Id = foo STR, Session-Id = bar > | ---------------------> <-------------------- > | +----+ +------+ +------+ +----+ > | | FA | | AAAF | | AAAH | | HA | > | +----+ +------+ +------+ +----+ > | <--------------------- ---------------------> > | STA, Session-Id = foo STA, Session-Id = bar > | Figure 3: Session Termination and Session Identifiers > > mobileip-08, section 1.6 "Diameter Session Termination", says the FA's > STR goes to his AAAF: > > | In order for the > | Diameter Server to release any resources allocated to a specific > | mobile node, the mobility agents MUST send a Session-Termination- > | Request (STR) to their respective Diameter servers. > > Possible follow up to question#1: If the FA's STR is to be sent to his > AAAF, how does the FA determine the DiameterIdentity of the AAAF (to > send as the value of the STR's Destionation-Host AVP)? > > Question#2: If a server receives an STR for an unknown session, does > the server return an STA(Result-Code=Success) or an > STA(Result-Code=Unknown-Session-Id)? > > I would think STA(Result-Code=Success) because of timing. > The server and MA may have simulateously timed out a session, the MA's STR > arrives soon after. Or a previous FA sends an STR after a handoff > to a new FA. That sort of thing. > > Bob K. From owner-aaa-wg@merit.edu Sat Feb 23 16:14:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24266 for ; Sat, 23 Feb 2002 16:14:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A44C9120A; Sat, 23 Feb 2002 16:13:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E0EA9120E; Sat, 23 Feb 2002 16:13:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 02DB29120A for ; Sat, 23 Feb 2002 16:13:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE9C45DE2A; Sat, 23 Feb 2002 16:13:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 77DC65DD99 for ; Sat, 23 Feb 2002 16:13:49 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1NLDnS25373; Sat, 23 Feb 2002 15:13:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1NLDmc13673; Sat, 23 Feb 2002 15:13:48 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA23625; Sat, 23 Feb 2002 15:13:48 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA07534; Sat, 23 Feb 2002 15:13:44 -0600 (CST) Message-ID: <3C78057A.107CCC12@ericsson.com> Date: Sat, 23 Feb 2002 13:11:23 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP References: Content-Type: multipart/alternative; boundary="------------4FD52FE76026D24389B0BC3B" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------4FD52FE76026D24389B0BC3B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pat, "Pat R. Calhoun" wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If memory serves, Glen Z can provide more info, but tying the > authorization lifetime to the key lifetime were considered > inappropriate. It is possible to have a key that spans many > authorization lifetimes (and the protocol does allow requesting > authorization without a key). But, in the AAA Registration Keys for Mobile IP, which we are dependent on, you can only tell the mobile one timer (the Lifetime). The Lifetime AAA Registration Keys for Mobile IP indicates the duration of time (in seconds) for which the MN-FA and MN-HA keys are valid. When the keys expires the MN must re-auth, so seen from the MN the authorization lifetime and the key lifetime is very much the same thing. Right? So, if we want the session keys to span many authorization lifetimes don't we need to make the MN more aware? I mean, as the AAA Registration Keys for Mobile IP draft are define right now the MN would expect to get new keys when the Lifetime timer expires, which may not at all be true if we say that the session keys may span over many authorization lifetimes. Regards, /Tony > > > However, if memory serves this issue spawned from the NASREQ > document. > > PatC > > - -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Friday, February 22, 2002 4:19 PM > To: Bob Kopacz > Cc: aaa-wg > Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP > > Hello Bob and All, > > To decouple the Authorization-Lifetime and the key lifetime was > introduced in issue 186. I've been trying to come up with an > explanation to issue 186 and what Bob states below, but the more I > think about this the more unsure I become to why we need this > decoupling. > > In the Base we have the Session-Timeout AVP , which contains the > maximum number of seconds of service to be provided to the user > before termination of the session, and the the Authorization-Lifetime > AVP, which contains the maximum number of seconds before a re-auth > needs to be done. Unless I've missed something here, I don't see why > we introduced a third timer in MIP appl. > > When the keys are distributed to the MN, FA and HA we also tell the > number of seconds they all are valid that, to me, also applies the > number of seconds before re-auth, which is exactly the definition of > the Authorization-Lifetime AVP. > > Comments please. > > /Tony > > Bob Kopacz wrote: > > > Hi Tony, > > > > > Yes I agree, could you please submit a new issue for this. So, we > > > don't forget it. > > > > The above is from an email you sent me on 1-Feb, Subj: "Re: > > [AAA-WG]: [issue] Returning AAAF-Generated FA-HA Key to FA", where > > I had asked a few questions about the MIP-Key-Lifetime. > > > > I just now rediscovered that I never did submit this issue. > > > > However, before I submit an issue about MIP-Key-Lifetime AVP, I > > want to get your take on a few further things regarding > > MIP-Key-Lifetime, so I can submit a more complete issue. My > > questions reflect my > > ignorance. > > > > > > The following is a numbered list. The "-->" indicates either a > > question, or what I believe is the answer. The "-->" things are > > what is to be addressed in the pending MIP-Key-Lifetime AVP issue. > > > > > > (1) There is a single MIP-Key-Lifetime AVP which contains the > > lifetime that applies to all the keys. > > > > --> The draft should add the following clarifications: > > > > "Since the AAAH is the owner of the MN, the AAAH specifies the > > key > > lifetime for the keys it generates as well for as the HA-FA > > key, if > > generated by the destination AAAF. Therefore, even if the AAAH > > isn't > > generating any keys and the only key being generated is the > > HA-FA key > > by the destination AAAF, the AAAH must remember to pass the > > MIP-Key-Lifetime AVP in the HAR." > > > > > > (2) Section 1.2 of the mobile-ip draft says: > > > > | "The expiration time of the > > | authorization (and session keys, if allocated by the AAA server) > > | is communicated through the Authorization-Lifetime AVP in the > > | AA-Mobile- Node-Answer from the AAAH." > > > > --> The sentence should be rephrased to remove the parenthesized > > phrase, or to remove the parenthesized phrase and add the sentence > > "The expiration time of the session keys is communicated through > > the MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the > > AAAH." > > > > > > (3) The base draft says a number of things about the Auth-Lifetime > > AVP, such as: > > > > 3a. The relationship of the Auth-Lifetime value and the > > Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout > > value) > > > > 3b. The state transitions and actions that take place, for both > > the server and the access device, when the Auth-Lifetime (+grace > > period) expires. > > > > 3c. How the client can send the Auth-Lifetime as a "hint" to the > > server. > > > > draft-mobileip-08 doesn't say nearly so much about the > > MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with > > "Auth-Lifetime" replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c > > above). > > > > What draft-mobileip-08 says is the following: > > > > | 6.13 MIP-Key-Lifetime AVP > > | > > | The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32 > > | and represents the period of time (in seconds) for which the > > | session key is valid. The session key MUST NOT be used if the > > | lifetime has expired; if the key lifetime expires while the > > | session to which it applies is still active, either the session > > | key MUST be changed or the or the session MUST be terminated. > > > > So ... > > > > (4) The draft-base-08 says the following things about the > > Authorization-Lifetime AVP, and the "-->" indicates that the same > > sorts of things should be addressed for the MIP-Key-Lifetime AVP: > > > > | base-08 Section 2.0 "Protocol Overview" says: > > | > > | Session state (associated with a Session-Id) MUST be freed upon > > | receipt of the Session-Termination-Request, Session-Termination- > > | Answer, expiration of authorized service time in the > > | Session-Timeout AVP, and according to rules established in a > > | particular Diameter application. > > | > > | > > | base-08 Section 8.1 "Authorization Session State Machine" says: > > | > > | Open Authorization-Lifetime (and Cleanup Discon > > | Auth-Grace-Period) expires > > | on home server. > > | > > | Open Session-Timeout expires on Cleanup Discon > > | home server > > | > > | Open Authorization-Lifetime + send STR Discon > > | Auth-Grace-Period expires on > > | access device > > | > > | Open Session-Timeout Expires on send STR Discon > > | Access Device > > > > --> draft-mobileip should specify the actions of both the server > > and the access device when the MIP-Key-Lifetime AVP expires. > > Presumably the access device should send an STR, while the server > > quietly cleans out the session. > > > > --> should draft-mobileip (and the other application > > drafts) add an "Authorization Session State Machine" and > > "Accounting Session State Machine" section, indicating > > application-specific > > extensions to the base state machine? e.g. mobileip-08 would add > > "Open Key-Lifetime Expires on Access Device send STR Discon" > > > > --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so, > > is a new MIP-Key-Lifetime-Grace-Period AVP needed? > > > > | base-08 Section 8.4 "Session Termination" says: > > | > > | A Diameter server also MUST clean up resources when the Session- > > | Timeout expires, or when the Authorization-Lifetime and the > > | Auth- Grace-Period AVPs expires without receipt of a > > | re-authorization request, regardless of whether an STR for that > > | session is received. The access device is not expected to > > | provide service beyond the expiration of these timers; thus, > > | expiration of either of these timers implies that the access > > | device may have unexpectedly shut down. > > | > > | base-08 Section 8.9 "Authorization-Lifetime AVP" says: > > | > > | If both this AVP and the Session-Timeout AVP are present in a > > | message, the value of the latter MUST NOT be smaller than the > > | Authorization-Lifetime AVP. > > | > > | This AVP MAY be provided by the client as a hint of the maximum > > | lifetime that it is willing to accept. However, the server MAY > > | return a value that is equal to, or smaller, than the one > > | provided by the client. > > > > --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ? > > > > --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as > > some sort of hint? > > > > | base-08 Section 8.12 "Re-Auth-Request-Type AVP" says: > > | > > | The Re-Auth-Request-Type AVP (AVP Code 285) is of type > > | Enumerated and is included in application-specific auth answers > > | to inform the client of the action expected upon expiration of > > | the > > | Authorization-Lifetime. The following values are defined: > > | > > | AUTHORIZE_ONLY 0 > > | An authorization only re-auth is expected upon expiration > > | of > > | the Authorization-Lifetime. This is the default value if > > | the > > | AVP is not present in answer messages that include the > > | Authorization-Lifetime. > > | > > | AUTHORIZE_AUTHENTICATE 1 > > | An authentication and authorization re-auth is expected > > | upon > > | expiration of the Authorization-Lifetime. > > > > --> Should the server convey something akin to the above, to tell > > the client what action to take upon MIP-Key-Lifetime expiration? > > Can the client request a "key refresh"? > > > > Bob K. > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPHb+cTN1fXKoxmisEQKHpACfZ3o3rm/fqEBL9DyJ7GmcTyT4ep0AoMwA > vkpp6LB9mVPym6M5ORY/ESQd > =0Eq7 > -----END PGP SIGNATURE----- --------------4FD52FE76026D24389B0BC3B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Pat,

"Pat R. Calhoun" wrote:

 
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

If memory serves, Glen Z can provide more info, but tying the
authorization lifetime to the key lifetime were considered
inappropriate. It is possible to have a key that spans many
authorization lifetimes (and the protocol does allow requesting
authorization without a key).

But, in the AAA Registration Keys for Mobile IP, which we are dependent on, you can only tell the mobile one timer (the Lifetime). The Lifetime AAA Registration Keys for Mobile IP indicates the duration of time (in seconds) for which the MN-FA and MN-HA keys are valid. When the keys expires the MN must re-auth, so seen from the MN the authorization lifetime and the key lifetime is very much the same thing. Right?

So, if we want the session keys to span many authorization lifetimes don't we need to make the MN more aware? I mean, as the AAA Registration Keys for Mobile IP draft are define right now the MN would expect to get new keys when the Lifetime timer expires, which may not at all be true if we say that the session keys may span over many authorization lifetimes.

Regards,

/Tony
 

 

However, if memory serves this issue spawned from the NASREQ
document.

PatC

- -----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Friday, February 22, 2002 4:19 PM
To: Bob Kopacz
Cc: aaa-wg
Subject: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP

Hello Bob and All,

To decouple the Authorization-Lifetime and the key lifetime was
introduced in issue 186.  I've been trying to come up with an
explanation to issue 186 and what Bob states below, but the more I
think about this the more unsure I become to why we need this
decoupling.

In the Base we have the Session-Timeout AVP , which contains the
maximum number of seconds of service to be provided to the user
before termination of the session, and the the Authorization-Lifetime
AVP, which contains the maximum number of seconds before a re-auth
needs to be done. Unless I've missed something here, I don't see why
we introduced a third timer in MIP appl.

When the keys are distributed to the MN, FA and HA we also tell the
number of seconds they all are valid that, to me, also applies the
number of seconds before re-auth, which is exactly the definition of
the Authorization-Lifetime AVP.

Comments please.

/Tony

Bob Kopacz wrote:

> Hi Tony,
>
> > Yes I agree, could you please submit a new issue for this. So, we
> >  don't forget it.
>
> The above is from an email you sent me on 1-Feb, Subj: "Re:
> [AAA-WG]:  [issue] Returning AAAF-Generated FA-HA Key to FA", where
> I had asked a  few questions about the MIP-Key-Lifetime.
>
> I just now rediscovered that I never did submit this issue.
>
> However, before I submit an issue about MIP-Key-Lifetime AVP, I
> want  to get your take on a few further things regarding
> MIP-Key-Lifetime,  so I can submit a more complete issue.  My
> questions reflect my
> ignorance.
>
>
> The following is a numbered list.  The "-->" indicates either a
> question, or what I believe is the answer.  The "-->" things are
> what  is to be addressed in the pending MIP-Key-Lifetime AVP issue.
>
>
> (1) There is a single MIP-Key-Lifetime AVP which contains the
> lifetime  that applies to all the keys.
>
> --> The draft should add the following clarifications:
>
>     "Since the AAAH is the owner of the MN, the AAAH specifies the
> key
>     lifetime for the keys it generates as well for as the HA-FA
> key, if
>     generated by the destination AAAF.  Therefore, even if the AAAH
> isn't
>     generating any keys and the only key being generated is the
> HA-FA key
>     by the destination AAAF, the AAAH must remember to pass the
>     MIP-Key-Lifetime AVP in the HAR."
>
>
> (2) Section 1.2 of the mobile-ip draft says:
>
> |  "The expiration time of the
> |  authorization (and session keys, if allocated by the AAA server)
> | is   communicated through the Authorization-Lifetime AVP in the
> | AA-Mobile-  Node-Answer from the AAAH."
>
> --> The sentence should be rephrased to remove the parenthesized
> phrase, or to remove the parenthesized phrase and add the sentence
> "The expiration time of the session keys is communicated through
> the  MIP-Key-Lifetime AVP in the AA-Mobile-Node-Answer from the
> AAAH."
>
>
> (3) The base draft says a number of things about the Auth-Lifetime
> AVP, such as:
>
> 3a.  The relationship of the Auth-Lifetime value and the
> Session-Timeout value (i.e. Auth-Lifetime value <= Session-Timeout
> value)
>
> 3b.  The state transitions and actions that take place, for both
> the  server and the access device, when the Auth-Lifetime (+grace
> period)  expires.
>
> 3c.  How the client can send the Auth-Lifetime as a "hint" to the
> server.
>
> draft-mobileip-08 doesn't say nearly so much about the
> MIP-Key-Lifetime regarding 3a, 3b, and 3c above (with
> "Auth-Lifetime"  replaced by "MIP-Key-Lifetime" in 3a, 3b, and 3c
> above).
>
> What draft-mobileip-08 says is the following:
>
> |  6.13 MIP-Key-Lifetime AVP
> |
> |  The MIP-Key-Lifetime AVP (AVP Code 367) is of type Unsigned32
> | and   represents the period of time (in seconds) for which the
> | session key   is valid.  The session key MUST NOT be used if the
> | lifetime has   expired; if the key lifetime expires while the
> | session to which it   applies is still active, either the session
> | key MUST be changed or   the or the session MUST be terminated.
>
> So ...
>
> (4) The draft-base-08 says the following things about the
> Authorization-Lifetime AVP, and the "-->" indicates that the same
> sorts of things should be addressed for the MIP-Key-Lifetime AVP:
>
> |  base-08 Section 2.0 "Protocol Overview" says:
> |
> |  Session state (associated with a Session-Id) MUST be freed upon
> |  receipt of the Session-Termination-Request, Session-Termination-
> |   Answer, expiration of authorized service time in the
> | Session-Timeout   AVP, and according to rules established in a
> | particular Diameter   application.
> |
> |
> |  base-08 Section 8.1 "Authorization Session State Machine" says:
> |
> |     Open      Authorization-Lifetime (and    Cleanup    Discon
> |               Auth-Grace-Period) expires
> |               on home server.
> |
> |     Open      Session-Timeout expires on     Cleanup    Discon
> |               home server
> |
> |     Open      Authorization-Lifetime +       send STR   Discon
> |               Auth-Grace-Period expires on
> |               access device
> |
> |     Open      Session-Timeout Expires on     send STR   Discon
> |               Access Device
>
> --> draft-mobileip should specify the actions of both the server
> and the access device when the MIP-Key-Lifetime AVP expires.
> Presumably  the access device should send an STR, while the server
> quietly cleans  out the session.
>
> --> should draft-mobileip (and the other application
> drafts) add an "Authorization Session State Machine" and
> "Accounting  Session State Machine" section, indicating
> application-specific
> extensions to the base state machine? e.g. mobileip-08 would add
> "Open  Key-Lifetime Expires on Access Device  send STR Discon"
>
> --> is there a "grace period" for the MIP-Key-Lifetime AVP? if so,
> is a new MIP-Key-Lifetime-Grace-Period AVP needed?
>
> |  base-08 Section 8.4 "Session Termination" says:
> |
> |  A Diameter server also MUST clean up resources when the Session-
> |   Timeout expires, or when the Authorization-Lifetime and the
> | Auth-   Grace-Period AVPs expires without receipt of a
> | re-authorization   request, regardless of whether an STR for that
> | session is received.   The access device is not expected to
> | provide service beyond the   expiration of these timers; thus,
> | expiration of either of these   timers implies that the access
> | device may have unexpectedly shut   down.
> |
> |  base-08 Section 8.9 "Authorization-Lifetime AVP" says:
> |
> |  If both this AVP and the Session-Timeout AVP are present in a
> | message, the value of the latter MUST NOT be smaller than the
> | Authorization-Lifetime AVP.
> |
> |  This AVP MAY be provided by the client as a hint of the maximum
> |  lifetime that it is willing to accept. However, the server MAY
> | return  a value that is equal to, or smaller, than the one
> | provided  by the  client.
>
> --> Must MIP-Key-Lifetime AVP be <= Session-Timeout ?
>
> --> Can the client send the MIP-Key-Lifetime AVP to the AAAH as
> some sort of hint?
>
> |  base-08 Section 8.12 "Re-Auth-Request-Type AVP" says:
> |
> |  The Re-Auth-Request-Type AVP (AVP Code 285) is of type
> | Enumerated  and  is included in application-specific auth answers
> | to inform the  client  of the action expected upon expiration of
> | the
> | Authorization-Lifetime.  The following values are defined:
> |
> |     AUTHORIZE_ONLY             0
> |        An authorization only re-auth is expected upon expiration
> | of
> |        the Authorization-Lifetime. This is the default value if
> | the
> |        AVP is not present in answer messages that include the
> |        Authorization-Lifetime.
> |
> |     AUTHORIZE_AUTHENTICATE     1
> |        An authentication and authorization re-auth is expected
> | upon
> |        expiration of the Authorization-Lifetime.
>
> --> Should the server convey something akin to the above, to tell
> the client what action to take upon MIP-Key-Lifetime expiration?
> Can the  client request a "key refresh"?
>
> Bob K.

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBPHb+cTN1fXKoxmisEQKHpACfZ3o3rm/fqEBL9DyJ7GmcTyT4ep0AoMwA
vkpp6LB9mVPym6M5ORY/ESQd
=0Eq7
-----END PGP SIGNATURE-----

--------------4FD52FE76026D24389B0BC3B-- From owner-aaa-wg@merit.edu Sat Feb 23 16:35:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24410 for ; Sat, 23 Feb 2002 16:35:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D44E49120E; Sat, 23 Feb 2002 16:35:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A20391214; Sat, 23 Feb 2002 16:35:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 694419120E for ; Sat, 23 Feb 2002 16:35:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 489B25DDC0; Sat, 23 Feb 2002 16:35:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 006D75DD99 for ; Sat, 23 Feb 2002 16:35:35 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SAXD>; Sat, 23 Feb 2002 13:35:33 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Tony Johansson'" Cc: Bob Kopacz , aaa-wg Subject: RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP Date: Sat, 23 Feb 2002 13:35:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BCB2.058D2020" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BCB2.058D2020 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > But, in the AAA Registration Keys for Mobile IP, which we are > dependent on, you can only > tell the mobile one timer (the > Lifetime). The Lifetime AAA Registration Keys for Mobile IP > indicates the duration of time (in seconds) for which the MN-FA and > MN-HA keys are valid. When the keys expires the MN must re-auth, > so seen from the MN the authorization lifetime and the key > lifetime is very much the same thing. Right? But there is a fundamental difference between the Lifetime field in the MIP header, and the lifetime fields in the individual aaa-key extensions. Right? PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHgLJDN1fXKoxmisEQLdmgCfZP6TpqAoXLcJA8ESjygpVUEqTNcAoN2T A7qR432QCIWw4s8xwnF0WeU5 =lK73 -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BCB2.058D2020 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime = AVP

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> But, in the AAA Registration Keys for Mobile IP, = which we are
> dependent on, you can only > tell the mobile = one timer (the
> Lifetime). The Lifetime AAA Registration Keys = for Mobile  IP
> indicates the duration of time (in seconds) for = which the MN-FA and
> MN-HA keys are  valid. When the keys = expires the MN must re-auth,
> so seen from the MN the authorization  = lifetime and the key
> lifetime is very much the same thing. = Right?  

But there is a fundamental difference between the = Lifetime field in
the MIP header, and the lifetime fields in the = individual aaa-key
extensions. Right?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHgLJDN1fXKoxmisEQLdmgCfZP6TpqAoXLcJA8ESjygpVUEqTNcAoN2= T
A7qR432QCIWw4s8xwnF0WeU5
=3DlK73
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BCB2.058D2020-- From owner-aaa-wg@merit.edu Sat Feb 23 16:48:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24478 for ; Sat, 23 Feb 2002 16:48:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A691891214; Sat, 23 Feb 2002 16:47:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 749F691223; Sat, 23 Feb 2002 16:47:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8407991214 for ; Sat, 23 Feb 2002 16:47:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D97F5DDA8; Sat, 23 Feb 2002 16:47:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id EFE2E5DD99 for ; Sat, 23 Feb 2002 16:47:31 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1NLlRh23077 for ; Sat, 23 Feb 2002 15:47:27 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1NLlRc18583 for ; Sat, 23 Feb 2002 15:47:27 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA26266 for ; Sat, 23 Feb 2002 15:47:27 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA07825 for ; Sat, 23 Feb 2002 15:47:25 -0600 (CST) Message-ID: <3C780D60.1F82F56E@ericsson.com> Date: Sat, 23 Feb 2002 13:45:04 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: FA sends STR (draft-mobileip-08) Content-Type: multipart/alternative; boundary="------------E0C3A6A7920BB545FBEDDE3C" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------E0C3A6A7920BB545FBEDDE3C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Submitter name: Tony Johansson (Bob Kopacz) Submitter email address: tony.johansson@ericsson.com Date first submitted: 23-Feb-02 Reference: Document: Mobileip-08 Comment type: Editorial Priority: 1 Section: 1.6 Rationale/Explanation of issue: mobileip-08, section 1.6 "Diameter Session Termination", says the FA's STR goes to his AAAF: " In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to their respective Diameter servers" This is incorrect, since the STR should alway be issue to the Diameter server that authorized the service. Requested change: Change the text in section 1.6 from: "1.6 Diameter Session Termination ....... In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to their respective Diameter servers ......." To: "1.6 Diameter Session Termination ....... In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to the Diameter server that authorized the service. ......." --------------E0C3A6A7920BB545FBEDDE3C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Submitter name: Tony Johansson (Bob Kopacz)
Submitter email address: tony.johansson@ericsson.com
Date first submitted: 23-Feb-02
Reference:
Document: Mobileip-08
Comment type: Editorial
Priority: 1
Section: 1.6
Rationale/Explanation of issue:

 mobileip-08, section 1.6 "Diameter Session Termination", says the FA's STR goes to his AAAF:

" In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to their respective Diameter servers"

This is incorrect, since the STR should alway be issue to the Diameter server that authorized the service.

Requested change:

Change the text in section 1.6 from:

"1.6  Diameter Session Termination

.......

In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to their respective Diameter servers

......."

To:

"1.6  Diameter Session Termination

.......

In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination-Request (STR) to the Diameter server that authorized the service.

......." --------------E0C3A6A7920BB545FBEDDE3C-- From owner-aaa-wg@merit.edu Sun Feb 24 22:19:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20262 for ; Sun, 24 Feb 2002 22:19:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 54B9491217; Sun, 24 Feb 2002 22:19:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EA6F91218; Sun, 24 Feb 2002 22:19:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2079991217 for ; Sun, 24 Feb 2002 22:19:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id F01355DD99; Sun, 24 Feb 2002 22:18:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DBC355DD8E for ; Sun, 24 Feb 2002 22:18:59 -0500 (EST) Received: from bkopacz98 (bgp01023602bgs.sanarb01.mi.comcast.net [68.40.81.246]) by aaa.interlinknetworks.com (Postfix) with SMTP id F096B7C; Sun, 24 Feb 2002 22:18:58 -0500 (EST) Message-ID: <000b01c1bdab$1aeecf00$f6512844@sanarb01.mi.comcast.net> From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: Accounting-Multi-Session-Id AVP (draft-mobileip-08) Date: Sun, 24 Feb 2002 22:18:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, Here's some feedback regarding draft-mobileip-08's treatment of the Accounting-Multi-Session-Id AVP. The following lines prefixed with "*" are extracted from draft-mobileip-08. The extracted lines includes ALL places where the Accounting-Multi-Session-Id AVP is mentioned. I numbered the lines to make them referencable. Here goes... *01 1.2 Inter-Realm Mobile IP *02 *03 [...] *04 *05 For new sessions, the AAAH MUST create an accounting session *06 identifier, which is added to the Accounting-Multi-Session-Id AVP in *07 the HAR message sent to the home agent. *08 *09 During the creation of the HAR, the AAAH MUST use a different session *10 identifier than the one used in the AMR/AMA (see figure 2). Of *11 course, an AAAH MUST use the same session identifier for all HARs *12 initiated on behalf of a given mobile node's session. [...] *13 (1) According to the Introduction, an AAAH may be session-stateless. I don't think a session-stateless AAAH can differentiate a new session from a handoff of an existing session. Therefore a session-stateless AAAH couldn't send the same session-id for handoffs, as stated in line *11. So lines *05-*12 should be replaced by: "During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA. "If the AAAH is session-stateful, it should send the same session identifier for all HARs initiated on behalf of a given mobile node's session. "If the AAAH is not session-stateful, it will manufacture a unique session-id for every HAR. (Note--This will not cause a problem for the HA, who must be able to recognize a handoff even if the AAAH thinks the session is new; an AAAH may incorrectly view a session as new when the handoff AMR goes to a different AAAH than the previous AMR). "Similarly, a session-stateful AAAH should send the same Accounting-Multi-Session-Id identifier for all HARs initiated on behalf of a given mobile node's session, while a session-stateless AAAH will manufacture a unique Accounting-Multi-Session-Id in every HAR." (In a later section, I will propose eliminating the last paragraph which begins "Similarly...") *14 [...] *15 *16 Upon receipt of the HAR, the Home Agent first processes the Diameter *17 message. [...] The Accounting-Multi-Session-Id AVP in *18 the HAR MUST be included in the HAA, which is then forwarded to the *19 AAAH. *20 (2) The last sentence is not quite right. While the HA does send an Accounting-Multi-Session-Id AVP in the HAA, it may be a different one than was received in the HAR. (see lines *44-*46). *21 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer *22 (AMA) message, includes the Accounting-Multi-Session-Id that was *23 present in the HAA, and the MIP-Home-Agent-Address, [...] *24 *25 1.3 Support for Mobile IP Handoffs *26 *27 [...] *28 *29 Since the new AAAH in the home network MAY not have access to the *30 session identifier that was used by the old AAAH, it is necessary for *31 the resulting HAR received by the HA to be identified as a *32 continuation of an existing session. If the HA receives an HAR for a *33 mobile node, with a new session identifier, and the HA can guarantee *34 that this request is to extend service for an existing service, then *35 the HA MUST be able to modify its internal session state information *36 to reflect the new AAAH and session identifier. The HA MUST also *37 issue an STR message with the old session identifier to the AAAH it *38 was communicating with when using the old session identifier. *39 *40 It is necessary for accounting records to have some commonality *41 across handoffs in order for correlation to occur. Therefore, in the *42 event that a home agent receives an HAR with a different Accounting- *43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the *44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP *45 that was received by the AAAH in the first HAR for the mobile's *46 session. This modified Accounting-Multi-Session-Id AVP will be *47 returned to the foreign agent by the AAAH in the AMA. Both the *48 foreign and home agents MUST include the Accounting-Multi-Session-Id *49 in the accounting messages. *50 (3) Since the AAAH must be prepared to have the AAAH-generated Accounting-Multi-Session-Id overridden by the HA, why don't we just have the HA always specify the Accounting-Multi-Session-Id? The thinking is that the HA is constant over the MN's session, while the AAAHs and AAAFs and FAs change. So the HA is in a position to specify a constant Accounting-Multi-Session-Id, eliminating the extra complications of a switcheroo. The proposal here is that the AAAH MUST NOT send a Accounting-Multi-Session-Id in the HAR. The HA MUST send a Accounting-Multi-Session-Id in the HAA. All of the messages for a MN's session will have the same value for the Accounting-Multi-Session-Id AVP. (4) Since the AAAH may be session-stateless, the HA would send the STR to the AAAH, as indicated in lines *36-*38, if and only if the AAAH has changed. (5) So then lines *29-*50 are replaced by: "Since the new AAAH in the home network MAY not have access to the session identifier that was used by the old AAAH, or since the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. "If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the (possibly) new AAAH and new session identifier. "If the AAAH is new, the HA MUST also issue an STR message with the old session identifier to the AAAH it was communicating with when using the old session identifier. "It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, the home agent MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Accounting-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. "This Accounting-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Accounting-Multi-Session-Id in the accounting messages." (6) And if you agree that the HA should generate the Accounting-Multi-Session-Id, then Section 1.5 "Co-located Mobile Node", should add the sentence: "The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to the AAAH, as the AAAH may find this a useful tidbit of session-state or log entry information." *51 2.2 AA-Mobile-Node-Answer *52 *53 [...] *54 *55 ::= < Diameter Header: 260, PXY > *56 [...] *57 [ Accounting-Multi-Session-Id ] *58 [...] *59 *60 *61 2.3 Home-Agent-MIP-Request *62 *63 [...] *64 *65 ::= < Diameter Header: 262, REQ, PXY > *66 [...] *67 { Accounting-Multi-Session-Id } *68 [...] *69 *70 2.4 Home-Agent-MIP-Answer *71 *72 [...] *73 *74 ::= < Diameter Header: 262, PXY > *75 [...] *76 [ Accounting-Multi-Session-Id ] *77 [...] *78 *79 8.1 Mobile IP Command AVP Table *80 *81 The table in this section is limited to the Command Codes defined in *82 this specification. (7) The AMR/AMA/HAR/HAA occurrence table doesn't include the Accounting-Multi-Session-Id AVP. It needs an entry like: Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 | *83 *84 8.2 Accounting AVP Table *85 (8) The Accounting occurrence table doesn't mention the Accounting-Multi-Session-Id AVP, but it should because the Base protocol defines the Accounting-Multi-Session-Id AVP, and makes the general statement that the Accounting-Multi-Session-Id AVP can occur in the ACR and ACA messages "0-1" times. But the applications have their own specific requirements. The Mobile IPv4 application requires the following: Attribute Name | ACR | ACA | ------------------------------|-----+-----+ Accounting-Multi-Session-Id | 1 | 0-1 | (9) The above Accounting occurrence table should indicate any other application-specific ACR/ACA requirements that are different from the Base protocol's more general Accounting occurrence table. Bob K. From owner-aaa-wg@merit.edu Mon Feb 25 04:56:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03687 for ; Mon, 25 Feb 2002 04:56:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A6B829121B; Mon, 25 Feb 2002 04:56:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 729F29121E; Mon, 25 Feb 2002 04:56:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 561359121B for ; Mon, 25 Feb 2002 04:56:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2BFD05DD9F; Mon, 25 Feb 2002 04:56:07 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 54F535DD97 for ; Mon, 25 Feb 2002 04:56:06 -0500 (EST) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA02517; Mon, 25 Feb 2002 10:51:36 +0100 From: "Fredrik Johansson" To: "Sivasundar Ramamurthy" , "Tony Johansson" Cc: "AAA Working Group" Subject: RE: [AAA-WG]: HA sending AMR Date: Mon, 25 Feb 2002 10:54:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, see comments below /Fredrik > >Hi Tony, > >> Sivasundar Ramamurthy wrote: >> >> > Hello, >> > >> > This is regarding AAA Mobile IP application. >> > >> > Consider the scenario when a MN returns home and sends a registration >> > request to the HA for deregistration. Also, the MN-HA key has expired >> > and the MN makes the deregistration request a AAA request. I am >> > assuming that no standards prevent the MN using a AAA request for >> > deregistration. >> >> In the scenario that you describe above the MN Keys has expired, which >> also means that the MN knows that if it doesn't issues a re-registration >> the MN will be de-registered, since the HA will issue an STR to the AAAH. >> So why would the MN issue a de-registration in this case? >> >> /Tony > >So the MN need not bother to de-register if the key to the HA is >expired, since the registration would have been terminated by the HA >anyway...that makes sense. > >Some MN(s) might have a policy to re-request keys much before the >keys expire, like re-registering before the previous registration >expires. It should, otherwise it will lose its connection and the next registration will be seen as a new registration. >For such MN, it is possible that it is deregistering when >its time to re-request keys - a AAA de-registration request! In this case, it will still have its MN-HA SA and can add both the MN-HA authentication extension and the mn-aaa authentication extension. This will enable the HA to make a policy decision, since it can authenticate the mn, the HA can send a STR to the AAA-H and a registration reply to the mn, thus the mn is deregistered. >Even in such cases the MN should probably not send the request >and simply let the registration terminate on its own... why not, the mn should always send a deregistration when it returns home. /Fredrik > >And as far as the HA is concerned, it need not bother to process a >de-registration AAA request in case some MN unnecessarily sends it >(even with a co-located COA). It will drop such requests and will >simply allow the registration to terminate "on its own" (registration >lifetime or key lifetime expiration). > >Thanks for the clarification! > > >Siva > > > > > > From owner-aaa-wg@merit.edu Mon Feb 25 06:27:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05416 for ; Mon, 25 Feb 2002 06:27:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AE4B91223; Mon, 25 Feb 2002 06:27:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62BD491228; Mon, 25 Feb 2002 06:27:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A3F991223 for ; Mon, 25 Feb 2002 06:27:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2547B5DDEE; Mon, 25 Feb 2002 06:27:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 617275DDA6 for ; Mon, 25 Feb 2002 06:27:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PBRGZ27527 for ; Mon, 25 Feb 2002 13:27:16 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 13:27:06 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 13:27:06 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 13:27:05 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BCE4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQCHCO+Q From: To: , X-OriginalArrivalTime: 25 Feb 2002 11:27:06.0209 (UTC) FILETIME=[5AD90510:01C1BDEF] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05416 Hi David, Thanks for the good points. The IESG has asked us to consider the usage of SRV records as in this document: http://www.ietf.org/internet-drafts/draft-ietf-sip-srv-05.txt This document has gone through IESG review and is considered the acceptable way to use SRV records. Using a mechanism like the above will create several changes: 1) AAA URI changes 2) Allow nodes to create NAPTR records, which detail the different transport layers they support. I think by using NAPTR records, your problem is overcome. If my understanding is correct, it would go something like this: As an example, consider a client that wishes to resolve aaa:user@example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAAS+D2T" "" _aaas._tcp.example.com. IN NAPTR 90 50 "s" "AAA+D2T" "" _aaa._tcp.example.com IN NAPTR 100 50 "s" "AAA+D2S" "" _aaa._sctp.example.com. This indicates that the server supports TLS over TCP, TCP, and SCTP, in that order. If the the client does not SCTP, TCP will be used, targeted to a host determined by an SRV lookup of _aaa._sctp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com Now, I have some thinking to do on this, but any questions, comments & criticisms would be appreciated. John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 22 February, 2002 20:55 > To: AAA Working Group > Subject: [AAA-WG]: [issue] AAA URI is Overloaded > > > Subject: [issue] AAA URI is Overloaded > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: 2/21/02 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 4.4 > Rationale/Explanation of issue: > > Some Background > --------------- > > The AAA URI provides two different kinds of information. > > 1. It identifies a Diameter node. A Diameter node is a Diameter > process running on some host or device. It is possible to have > more than one Diameter process running on a host. > > 2. It provides information about how to connect to the > Diameter node > -- what transport protocol to use, what transport level > security > to use, and even what AAA protocol to use (although we are only > concerned about one, namely Diameter). > > The AAA URI also serves two different purposes. > > 1. It is used in the peer-to-peer protocol to identify a peer and > indicate certain parameters concerning how to connect to that > peer. This use requires the full URI including the prefix, the > fqdn, the port number, and the options. A URI for this purpose > may be stored in a local configuration file or on a > remote server > to enable dynamic peer discovery (see sec. 5.2). > > 2. It is used in the Diameter routing and forwarding decisions to > identify the Diameter node to which a Diameter message is > addressed. This use requires those portions of the URI that > identify the Diameter node but does not require (and can be > confused by) the information about how to connect to > the node as a > peer. This is the use made of the URI as transmitted > in all AVPs > of type DiameterIdentity. > > > The Problem > ----------- > > The problem is that the URI format is currently defined in > only one > place (sec. 4.4 under the "DiameterIdentity" type) and makes no > distinction between its use for the two different purposes > described > above. > > > Operational Difficulties if the Problem Isn't Fixed > --------------------------------------------------- > > Section 4.4 states: > > Unless a Diameter node is sitting on the border of > two routing > domains (e.g. private and public), a Diameter node MUST > advertise the same identity on all connections, via the CER > and CEA's Origin-Host AVP. > > Suppose a Diameter node has two peers. It connects to the > first peer > using SCTP. It connects to the second peer using TCP. In > order to > obey this requirement, the node would have to include the string > "transport=sctp" in the Origin-Host AVP it puts in its CER or CEA > message to the second peer even though it is using TCP to > connect to > that peer. So the identity advertised is not the identity used. > This seems odd, but as we shall see, it is actually > necessary in order > to make the routing mechanism work. > > Section 4.4 goes on to state: > > The same identity advertised in a connection's CER > and CEA MUST > be used in any AVP of type DiameterIdentity sent on that > connection. > > Now suppose an implementor misses the oddity required by the first > sentence and does the obvious thing -- suppose the implementation > always includes in the CER the parameters actually in use > on the peer > connection. Then the implementation will have a very hard time > meeting this requirement too. It would have to know how it will > route the message at the time it generates the message, a horrible > violation of modularity. Supposing it does know how it will route > the message and sets the value of the Origin-Host AVP in > the message > to the same value used in the CER or CEA sent to the peer > to which it > will route it. Now suppose something goes wrong when sending the > message to this peer, and the message is subsequently > retransmitted > to a backup peer. Oops. Now the Origin-Host AVP is wrong > for that > connection and it can't be changed. > > So we'll just have to assume that all implementors pick up on the > oddity. But wait -- we're still not out of the woods. > Suppose, at > the time a session begins, the Diameter client supporting > the session > uses TCP on its peer link. So it includes the string > "transport=tcp" > in the auth request that begins the session. Suppose that several > hours later the session is still in progress, but the client has > reinitialized its peer link and is now using SCTP. Now > suppose the > home server sends an Abort-Session-Request message to the > client for > this session. The Abort-Session-Request will include a > Destination-Host AVP that contains the string > "transport=tcp". The > message eventually reaches the peer connected to the client. The > peer matches the URI in the Destination-Host AVP with the > ones in its > peer table. It finds no match because "transport=tcp" > does not match > "transport=sctp". So it discards the message. > > > Interaction With Issue 273 > -------------------------- > > Another issue urges that Diameter nodes not use different port > numbers for TLS versus non-TLS connections. I am guessing > that issue > 273 is the one that encompasses this change. The question of port > number use for TLS versus non-TLS was raised by Allison Mankin in: > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00025.html > > The outcome of issue 273 (if that is the issue that includes this > question) is critical to the resolution of this issue as > well. The > reason is that we use the combination of fqdn and port number to > identify a diameter node. If more than one Diameter node > (Diameter > daemon) runs on a host, they will use different port > numbers. But if > a Diameter node listens on more than one port number, then > it may use > two different URIs and there will be no way for a peer to > know that > the URI from the Destination-Host AVP of a message it is routing > matches the URI of one of its peers if the port number differs. > > John Loughney suggested use of aaa: vs. aaas: to indicate > whether TLS > is used in: > > http://www.merit.edu/mail.archives/aaa-wg/2002-02/msg00120.html > > If this suggestion is adopted, then the "s" in aaas: will > need to be > ignored when doing routing matches against entries in the > peer table. > > > Requested change: > > Define the format of the URI somewhere other than section 4.4. In > the definition of the DiameterIdentity type in section > 4.4, specify > that only the prefix, fqdn, and port number portions of > the URI are > included in AVP value fields of this type. The sentences > cited above > may now be left in section 4.4 because they no longer cause a > problem. > > If the resolution of issue 273 allows a Diameter node to listen on > different ports for TLS vs. non-TLS connections, then section 4.4 > needs to emphasize that a single port number MUST be used > in all AVPs > of type DiameterIdentity. If the resolution of 273 > requires use of > the same port for TLS and non-TLS connections, then it > would still be > a good idea to include text in section 4.4 following the first > sentence cited above that emphasizes that the same port > number MUST > be used in all AVPs of type DiameterIdentity even if a peer > connection request was received on a different port. > > If the URI prefix may either be aaa: or aaas: depending on > transport > security, then text should be added to section 6 stating that when > matching URIs for routing purposes, the "s" in aaas: should be > dropped before the compare is made. > From owner-aaa-wg@merit.edu Mon Feb 25 06:38:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05830 for ; Mon, 25 Feb 2002 06:38:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1B4091228; Mon, 25 Feb 2002 06:38:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D9BD9122E; Mon, 25 Feb 2002 06:38:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CF5991228 for ; Mon, 25 Feb 2002 06:38:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2CED85DDEE; Mon, 25 Feb 2002 06:38:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 3C3CE5DDA6 for ; Mon, 25 Feb 2002 06:38:19 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PBcoi20163 for ; Mon, 25 Feb 2002 13:38:50 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Feb 2002 13:38:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 13:38:18 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 13:38:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A09@esebe004.NOE.Nokia.com> Thread-Topic: Request for closure on issue 235 Thread-Index: AcG6a9cWlJHPKyYWEdaxoAAAhj/HZAAQTWLwANDVCoA= From: To: , X-OriginalArrivalTime: 25 Feb 2002 11:38:18.0001 (UTC) FILETIME=[EB445810:01C1BDF0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA05830 Hi all, Issue 235 requested the following change, as a performance enhancement w.r.t the process of checking for duplicate records. While other mechanisms such as post-processing and brute force (check every record against every other record) are possible, having the "D" bit would make the nodes that process these records only check for those records that are marked as potential duplicates. So the "D" bit can be treated as an optional mechanism for implementations that would prefer to do duplicate checking based on this flag. Several folks have checked this and believe that this would work. So, unless there are any remaining objections, I am going to accept this change & modify the base accordingly. br, John Requested change: ================= In section 3.0 Diameter Header ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ would be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E D r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. would get one new flag bit 'D': E(rror) - If set, the message contains a protocol error, and the message will not conform to the ABNF described for this command. Messages with the 'E' bit set is commonly referred to as an error message. This bit MUST NOT be set in request messages. See section 7.2. (possibly) D(uplicated) - This bit is defined only for Accounting Requests, sent by a Diameter node or proxy. If set, the message is possibly a duplicate, and must be later checked by a recipient node if it really is a duplicate. If sending a message for first time, this bit MUST be cleared. This bit MUST NOT be set if an answer message (about e.g. a protocol error) has been got for an earlier similar message. It can be used only in cases where no answer has been got from the primary agent for a message and the message is sent again (e.g. due to a failover, to an alternate agent or to a recovered primary peer node). r(eserved) - these flag bits are reserved for future use, and MUST be set to zero, otherwise an error MUST be sent to the sender. and in section 9.4 Fault Resilience ==================================== ... Diameter peers acting as clients MUST implement the use of failover to guard against server failures and certain network failures. Diameter peers acting as agents or related off-line processing systems MUST detect duplicate accounting records caused by the sending of same record to several servers and duplication of messages in transit. This detection MUST be based on the inspection of the Session-Id and Accounting-Record-Number AVP pairs. the above paragraph would get one sentence to its end: The inspection MUST be performed at least for such records that arrived at the Diameter peer specifically in accounting messages which have the 'D' bit set. From owner-aaa-wg@merit.edu Mon Feb 25 06:46:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06026 for ; Mon, 25 Feb 2002 06:46:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D72E791238; Mon, 25 Feb 2002 06:45:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A51609123C; Mon, 25 Feb 2002 06:45:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8486491238 for ; Mon, 25 Feb 2002 06:45:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64B105DE00; Mon, 25 Feb 2002 06:45:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 9F7F15DDF6 for ; Mon, 25 Feb 2002 06:45:39 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PBjmZ10796 for ; Mon, 25 Feb 2002 13:45:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 13:45:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 13:45:38 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: ISSUE: invalid reference X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 13:45:37 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: ISSUE: invalid reference Thread-Index: AcGzSHa+WBoZi7/zSZCLIVuHVK9ESwKqV51w From: To: , X-OriginalArrivalTime: 25 Feb 2002 11:45:38.0747 (UTC) FILETIME=[F1F8D8B0:01C1BDF1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06026 Hi Kevin, You are correct. Bernard, as you are editing the Transport Draft, let me know if this will cause problems, otherwise I will make the suggested changes. John > Submitter name: Kevin Purser > Submitter email address: kevin.purser@ericsson.com > Date first submitted: February 11th, 2002 > Reference: none > Document: base-08alpha02 > Comment type: Editorial > Priority: 1 > Section: 5.6 "Peer State Machine" > Rationale/Explanation of issue: > > There are a couple of references in this section to "the state machine > described in [52]". However, in the latest version of the > transport draft, > such a state machine is not present. > > > Requested change: > > Remove these references in the text. > > From owner-aaa-wg@merit.edu Mon Feb 25 06:49:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06104 for ; Mon, 25 Feb 2002 06:49:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA0839122E; Mon, 25 Feb 2002 06:48:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE0E39123C; Mon, 25 Feb 2002 06:48:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9BA4D9122E for ; Mon, 25 Feb 2002 06:48:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7D8B75DDF6; Mon, 25 Feb 2002 06:48:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 6AFF85DD97 for ; Mon, 25 Feb 2002 06:48:52 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PBnNi24521 for ; Mon, 25 Feb 2002 13:49:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 13:48:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 13:48:49 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue about which AVPs to encrypt and which not X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 13:48:49 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue about which AVPs to encrypt and which not Thread-Index: AcGyaZA3hemkhUHZTP+ThcD4mNVB+wLiK8TQ From: To: , , X-OriginalArrivalTime: 25 Feb 2002 11:48:49.0942 (UTC) FILETIME=[63EEE360:01C1BDF2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA06104 Jari, A side effect of your change will also increase the dependency of the base spec on CMS, which is something we are trying to eliminate. Unless someone speaks up, I am planning on marking this issue as a reject. John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 10 February, 2002 21:31 > To: Pat R. Calhoun; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue about which AVPs to encrypt and which not > > > RE: [AAA-WG]: Issue about which AVPs to encrypt and which > not>The WG decided to eliminate the Expected AVPs because of the > >possibility for conflicting information between the tables in the > >specifications, and what one sends in its Expected list of secured > >AVPs. > >I see no reason to go back to the more complex scheme. > > Agreed. I think the confusion arises from some parts of the old > scheme still being visible in the text. My proposed fix tries to > write everything in a manner where the data is fixed and not > sent in the Expected lists. > > Jari > > > > From owner-aaa-wg@merit.edu Mon Feb 25 07:04:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06474 for ; Mon, 25 Feb 2002 07:04:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 044549123C; Mon, 25 Feb 2002 07:03:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE3979123D; Mon, 25 Feb 2002 07:03:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9D9FD9123C for ; Mon, 25 Feb 2002 07:03:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 78AD75DDF6; Mon, 25 Feb 2002 07:03:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id CE77D5DD98 for ; Mon, 25 Feb 2002 07:03:50 -0500 (EST) Received: from ipunplugged.com (catsandlogs.local.ipunplugged.com [192.168.4.29]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id NAA05373; Mon, 25 Feb 2002 13:01:31 +0100 Message-ID: <3C7A3615.4070709@ipunplugged.com> Date: Mon, 25 Feb 2002 14:03:17 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: Basavaraj.Patil@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A09@esebe004.NOE.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 Just one question: why is it limited to accounting messages? As far as I can tell the bit means "resent" and I can't instantly think of why it wouldn't be just as good for non-accounting requests. j john.loughney@nokia.com wrote: >(possibly) D(uplicated) > - This bit is defined only for Accounting Requests, > sent by a Diameter node or proxy. > If set, the message is possibly a duplicate, > and must be later checked by a recipient node > if it really is a duplicate. If sending a > message for first time, this bit MUST be > cleared. > This bit MUST NOT be set if an answer message > (about e.g. a protocol error) has been got for > an earlier similar message. It can be used only > in cases where no answer has been got from the > primary agent for a message and the message is > sent again (e.g. due to a failover, to an > alternate agent or to a recovered primary peer > node). > From owner-aaa-wg@merit.edu Mon Feb 25 07:09:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06573 for ; Mon, 25 Feb 2002 07:09:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CA47B9123D; Mon, 25 Feb 2002 07:09:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A04DB9123E; Mon, 25 Feb 2002 07:09:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2AF789123D for ; Mon, 25 Feb 2002 07:09:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 084995DD98; Mon, 25 Feb 2002 07:09:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3A60B5DD97 for ; Mon, 25 Feb 2002 07:09:25 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PC9YZ28551 for ; Mon, 25 Feb 2002 14:09:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 14:09:19 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 14:09:19 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 14:09:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG99Hy4fWxNhAo2QROTTPPdgKJlmAAAMNwg From: To: Cc: , X-OriginalArrivalTime: 25 Feb 2002 12:09:19.0893 (UTC) FILETIME=[410A8450:01C1BDF5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06573 > -----Original Message----- > From: ext Johan Johansson [mailto:johanj@ipunplugged.com] > Sent: 25 February, 2002 15:03 > To: Loughney John (NRC/Helsinki) > Cc: Patil Basavaraj (NET/Dallas); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Request for closure on issue 235 > > > Just one question: why is it limited to accounting messages? > As far as I > can tell the bit means "resent" and I can't instantly think of why it > wouldn't be just as good for non-accounting requests. > > j > > john.loughney@nokia.com wrote: > > >(possibly) D(uplicated) > > - This bit is defined only for > Accounting Requests, > > sent by a Diameter node or proxy. > > If set, the message is possibly a duplicate, > > and must be later checked by a recipient node > > if it really is a duplicate. If sending a > > message for first time, this bit MUST be > > cleared. > > This bit MUST NOT be set if an answer message > > (about e.g. a protocol error) has been got for > > an earlier similar message. It can be > used only > > in cases where no answer has been got from the > > primary agent for a message and the message is > > sent again (e.g. due to a failover, to an > > alternate agent or to a recovered primary peer > > node). > > > > > From owner-aaa-wg@merit.edu Mon Feb 25 07:11:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06635 for ; Mon, 25 Feb 2002 07:11:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1F9C79123E; Mon, 25 Feb 2002 07:11:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1A839123F; Mon, 25 Feb 2002 07:11:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD2EC9123E for ; Mon, 25 Feb 2002 07:11:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id B26D45DD98; Mon, 25 Feb 2002 07:11:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E5DAC5DD97 for ; Mon, 25 Feb 2002 07:11:25 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PCBYZ00068 for ; Mon, 25 Feb 2002 14:11:35 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 14:11:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 14:11:24 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 14:11:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0F@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG99Hy4fWxNhAo2QROTTPPdgKJlmAAAMmEA From: To: Cc: , X-OriginalArrivalTime: 25 Feb 2002 12:11:24.0244 (UTC) FILETIME=[8B28F940:01C1BDF5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA06635 Hi Johan, - take 2, fingers a bit stiff on a Monday ... > Just one question: why is it limited to accounting messages? > As far as I can tell the bit means "resent" and I can't instantly think > of why it wouldn't be just as good for non-accounting requests. I will let Basavaraj provide the definitive answer, but I do agree that it could be used elsewhere, but in accounting it may be the critical place for this functionality. It is not impossible to delete the first sentence below. John > john.loughney@nokia.com wrote: > > >(possibly) D(uplicated) > > - This bit is defined only for Accounting Requests, > > sent by a Diameter node or proxy. > > If set, the message is possibly a duplicate, > > and must be later checked by a recipient node > > if it really is a duplicate. If sending a > > message for first time, this bit MUST be > > cleared. > > This bit MUST NOT be set if an answer message > > (about e.g. a protocol error) has been got for > > an earlier similar message. It can be used only > > in cases where no answer has been got from the > > primary agent for a message and the message is > > sent again (e.g. due to a failover, to an > > alternate agent or to a recovered primary peer > > node). > > > > > From owner-aaa-wg@merit.edu Mon Feb 25 08:04:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08388 for ; Mon, 25 Feb 2002 08:04:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 024189123F; Mon, 25 Feb 2002 08:04:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C03E891240; Mon, 25 Feb 2002 08:04:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1A7A9123F for ; Mon, 25 Feb 2002 08:04:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E77E5DDB8; Mon, 25 Feb 2002 08:04:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 873CB5DD95 for ; Mon, 25 Feb 2002 08:04:10 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PD4fi29051 for ; Mon, 25 Feb 2002 15:04:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Feb 2002 15:04:09 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 15:04:09 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: RE: [AAA-WG]: Issue 243 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 15:04:08 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A17@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Accounting-Multi-Session-Id AVP (draft-mobileip-08) Thread-Index: AcG9qzhRxW4GPsA3QZWcFFzyM+HgqgAUXnZw From: To: X-OriginalArrivalTime: 25 Feb 2002 13:04:09.0269 (UTC) FILETIME=[E9A97650:01C1BDFC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA08388 Hi all, Going through the open issues, it seems that this issue has been marked as a possible reject. I concur, unless there is support in the WG, I move that this issue is rejected. John Issue 243: Session State Machine for Diameter agents Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: November 13, 2001 Document: base Comment type: E Priority: 1 Section: 8.1, 8.2 Rationale/Explanation of issue: Authorization Session State Machine and Accounting Session State Machine seem to define FSM for Diameter clients and servers but not for Diameter agents (i.e., relay, proxy, redirect and translation agents). For example, in section 8.1, when a Service-specific authorization request is received from a peer in Idle state, there is no action to *forward* the received request to the next-hop peer of the session and move to Pending state, which would be a normal action for relay agents. Similarly, when a Service-specific authorization answer is received from the next-hop peer of the session in Pending state, there is no action to *return* the received answer to the previous-hop peer of the session and move to Open state (in the case of stateful relay agents) or Idle state (in the case of stateless relay agents), which would also be a normal action for relay agents. Requested change: Additional state transitions need to be included in section 8.1 and 8.2 to support relay, proxy, redirect and translation agents. From owner-aaa-wg@merit.edu Mon Feb 25 08:08:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08515 for ; Mon, 25 Feb 2002 08:08:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9ED091240; Mon, 25 Feb 2002 08:07:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8194B91241; Mon, 25 Feb 2002 08:07:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 736BA91240 for ; Mon, 25 Feb 2002 08:07:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5384F5DDB8; Mon, 25 Feb 2002 08:07:44 -0500 (EST) 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 8D49A5DD95 for ; Mon, 25 Feb 2002 08:07:43 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PD7A304566 for ; Mon, 25 Feb 2002 15:07:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 25 Feb 2002 15:07:42 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 15:07:42 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Subject: [AAA-WG]: Issue 244 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 15:07:41 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A18@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Accounting-Multi-Session-Id AVP (draft-mobileip-08) Thread-Index: AcG9qzhRxW4GPsA3QZWcFFzyM+HgqgAUXnZwAAAkspA= From: To: X-OriginalArrivalTime: 25 Feb 2002 13:07:42.0274 (UTC) FILETIME=[689F7220:01C1BDFD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA08515 Hi all, It seems that this issue is marked as possible reject, which I support. Unless there is consensus for making the change, I suggest we reject this issue. John Issue 244: ELECTION_LOST result code Submitter name: Michael Chen Submitter email address: cchen@erilab.com Date first submitted: 19-Nov-01 Reference: Document: base-08 Comment type: E Priority: 1 Section: Base: 5.4.3 Rationale/Explanation of issue: DPR is not sent to its peer when lost the election so ELECTION_LOST result code is not used. Requested change: Remove this result code. From owner-aaa-wg@merit.edu Mon Feb 25 08:21:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08953 for ; Mon, 25 Feb 2002 08:21:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 42F7691241; Mon, 25 Feb 2002 08:21:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08BC991242; Mon, 25 Feb 2002 08:21:22 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10C2F91241 for ; Mon, 25 Feb 2002 08:21:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id E58D55DDB8; Mon, 25 Feb 2002 08:21:21 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id 536AE5DD95 for ; Mon, 25 Feb 2002 08:21:21 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1PDLJB28244 for ; Mon, 25 Feb 2002 14:21:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 25 14:21:18 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 14:21:18 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F94737@efijont102> From: "Harri Hakala (LMF)" To: "'fmaring@airtel.es'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios Date: Mon, 25 Feb 2002 14:21:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Paco, I see your point and I agree with you that the explained scenarios are important to cover from a charging perspective. But I think that you can use the existing mechanism provided by credit control draft to solve your problem (check the balance). In your scenario when the network operator (credit control client) receives the SM from the third party, it can start accounting session and try to make credit-reservation. If granted-service-unit is returned by the credit control server, the network operator can acknowledge the SM delivery to the third party. If the end user is out of coverage (no acknowledgement), the network operator can stop the accounting session and indicate that the used-service-unit is zero. I assume that the network operator will get indication when the end user is attached again, so it can re-start accounting session and SM delivery to the end-user and there is no need to keep the accounting session open several days. The focus of the draft is to provide network operator/service provider with means to check that the end user has credit before rendering the service in order to prevent credit loss. It does not focus account update/promotion functions or account enquiry functions. Regards.............Harri -----Original Message----- From: fmaring@airtel.es [mailto:fmaring@airtel.es] Sent: 19. helmikuuta 2002 8:41 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenariosu Issue : Possible modification to the Diameter Cost Control Application protocol Submitter name: Paco Marin Submitter email address: fmaring@airtel.es Date first submitted: 02-18-2002 Reference: Document: draft-hakala-diameter-credit-control-01.txt Comment type: Technical Hi all, I've been taking look to the last version of the draft 'Diameter Credit Control Application' (draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part. Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios being covered with the described protocol, however I did'nt find the way to use this protocol to cover two possible scenarios. The referred scenarios are the following: 1.- Check of balance. Sometimes is necessary to check if there is enough balance to grant a service to a subscriber. Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there are three parts: the subscriber, the network operator and a third party which is the service provider. The third party will charge the sent melody (or logo) to the network operator just when the network operator receives it, so it could be interesting to acknowledge the Short Message delivery from the third party only when the subscriber has enough credit. This way the operator avoids to pay for a message that will never be delivered because the final user (the subscriber) has no credit enough. I've been thinking about the possibility of using 'session based credit control'. However is hardly ineficient, the SM must be acknowledged immediately and the short message could wait several days to be delivered to the final user (the user could be out of coverage), it implies to keep the session opened until the SM is finally delivered. 2.- Increment of Credit In some scenarios could be useful to add to the protocol the posibility to increase the balance instead of decrementing it. As an example, could be a way to motivate the user access to advertisement information in the internet or to receive adversiting Short Messages from a third party. In these scenarios could be interesting to be able to increment the credit directly from the client, as an example increase money on the user account or allow 1 free short message every 5 advertisement Short Message received. I think there is no way to make it with the current version of the draft (please, please, please correct me if I am wrong or confused). The solution to these two scenarios should not be fundamental for the overall working of the Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the legacy architectures of the current network operators. In my humble opinion a possible solution for both scenarios should be to include a new AVP. PROPOSAL OF SOLUTION A new AVP to indicate an operation on the balance is going to be accomplished could be added to the proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out is a decrement, check of balance or an increment. If this new AVP is not included in the request, the server should consider that the value of this one is '0', it will mean the behaviour of the protocol will be the one described up to now. The new AVP could be: 'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be: '0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted. This units will be decremented in that moment from the user account. '1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units allowed to be carried out. This units will NOT be decremented from the user account. '2': Increment, the request and answer work in a similar way as described for the value '0'. The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP contains the service units incremented. This units will be incremented in that moment in the user account. The accounted AVP table should be modified as follows: +----------+ | Command | | code | +----+-----+ Attribute Name |ACR | ACA | ------------------------------+----+-----+ Balance-Management-Indicator |0-1 | 0 | ------------------------------+----+-----+ Maybe I'm confused..... correct me in that case. Thanks a lot. Paco. From owner-aaa-wg@merit.edu Mon Feb 25 08:35:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09447 for ; Mon, 25 Feb 2002 08:35:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 25E2591242; Mon, 25 Feb 2002 08:35:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E5C0491243; Mon, 25 Feb 2002 08:35:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D58CD91242 for ; Mon, 25 Feb 2002 08:35:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69E815DE3C; Mon, 25 Feb 2002 08:35:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id AC07F5DDE1 for ; Mon, 25 Feb 2002 08:35:08 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g1PDZ6B09404 for ; Mon, 25 Feb 2002 14:35:06 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 25 14:35:05 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Feb 2002 14:35:05 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F94738@efijont102> From: "Harri Hakala (LMF)" To: "'fmaring@airtel.es'" , aaa-wg@merit.edu Cc: "Stefan Karlsson (EPK)" Subject: [AAA-WG]: RE: Diameter CCA: Number of sessions per user Date: Mon, 25 Feb 2002 14:35:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Paco, >the credit not consumed must be returned back to the user account, it >means the money to return back is the 'reserved' credit minus the credit corresponding to the >'Used-Service-Units'.... Is it OK? YES The credit control application contains all accounting AVPs specified in the base protocol, only the additional AVPs are listed in the draft, so the second option is covered. Regards............Harri -----Original Message----- From: fmaring@airtel.es [mailto:fmaring@airtel.es] Sent: 21. helmikuuta 2002 19:12 To: aaa-wg@merit.edu Cc: harri.hakala@lmf.ericsson.se; stefan.karlsson@epk.ericsson.se Subject: Diameter CCA: Number of sessions per user Hi All, In the point 3.2 of the document 'Diameter Credit Control Application', is described the Service Credit Control using several interrogations (session control). When a session is opened (START_RECORD), the client ask for the server an amount of credit (stated in money, service units and so on....) which is reserved until the next request (ACR) of the multi-interrogations dialogue is received (INTERIM_RECORD or STOP_RECORD). When this new ACR is recived, a new amount of credit asked by the client is reserved. As described in the document this amount of credit 'reserved' for the user is stored in the server, so when the client finishes the dialogue (STOP_RECORD), the ACR includes the 'Used-Service-Units' AVP indicating the real amount of credit consumed since the previous interrogation. Then, the credit not consumed must be returned back to the user account, it means the money to return back is the 'reserved' credit minus the credit corrsponding to the 'Used-Service-Units'.... Is it OK? The question is: What happens when the user has serveral sessions opened at time? There is nothing about that in the document but I suppose that we can not establish limits for the number of sessions a user can have at time. A user could be downloading a document at the same time he is looking for the neares restaurant or buying the tickets for the last Swertzeneger film. I suppose the server must be able to identify which ACR corresponds to which session, however.... How could the server identify this session? Maybe I'm confused but I did not find neither an AVP able to identify it, nor a field corresponding to the Diameter Base protocol able to be used to identify the session (I understand the server cannot use neither the 'Hop-by-Hop' nor the 'End-to-End' identifier to associate that a received request corresponds to a specific session opened. This way, when a user has several sessions opened and receives a request (INTERIM_RECORD as an example) must be able to know which session must delete the stored credit and reserve a new credit again. I have been thinking about two solutions: 1.- Not to store the reserved credit in the server. The client could ask for the credit and receive it in the 'Granted-Service-Units' AVP, when the session is finished the client could send a different AVP called 'Remaining-Service-Units' instead of the 'Used-Service-Units' AVP. This way the session have not to be controlled by the server. This solution could have a problem, the fraud produced due to the lack of the session by the server. The server must trust the client, because the client could set the 'Remaining-Service-Units' AVP to a random value.... It could be difficult if the home domain receives request from clients from visited domains, a formal agreement must exists in this scenario to avoid fraud. 2.- Introduce in the request and answer the AVP called 'Session-ID' (code 263) to identify the session. This way the session is always identified for session oriented service control (several queries). In my humble oppinion, the second one is the best option to be able to solve this problem. regards, Paco. From owner-aaa-wg@merit.edu Mon Feb 25 09:01:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10422 for ; Mon, 25 Feb 2002 09:01:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E74BD91243; Mon, 25 Feb 2002 09:00:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70FB291245; Mon, 25 Feb 2002 09:00:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12B4E91243 for ; Mon, 25 Feb 2002 09:00:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 674385DDAC; Mon, 25 Feb 2002 08:56:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id C942B5DD95 for ; Mon, 25 Feb 2002 08:56:38 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1PDuFB26567; Mon, 25 Feb 2002 14:56:16 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1PDuEC4026287; Mon, 25 Feb 2002 15:56:15 +0200 (EET) Message-ID: <3C7A427F.8BF24B9E@lmf.ericsson.se> Date: Mon, 25 Feb 2002 15:56:15 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue about which AVPs to encrypt and which not References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0B@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John writes: > A side effect of your change will also increase the dependency of the > base spec on CMS, which is something we are trying to eliminate. Unless > someone speaks up, I am planning on marking this issue as a reject. Well, we obviously have to do something as the current text has some remnants of the old scheme left. The WG did decide a long time ago that we don't need operators to specify individual AVP encryption policy, we can do it in the RFC. So I think we should stick with that, and fix the problems in the specs accordingly (which I tried to do, but I'm sure the proposals could be improved). Jari From owner-aaa-wg@merit.edu Mon Feb 25 09:03:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10477 for ; Mon, 25 Feb 2002 09:03:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 38E1791248; Mon, 25 Feb 2002 09:02:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 02BDB91244; Mon, 25 Feb 2002 09:02:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B74B9124A for ; Mon, 25 Feb 2002 09:02:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D8F55DDBA; Mon, 25 Feb 2002 09:02:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 67FC45DD95 for ; Mon, 25 Feb 2002 09:02:45 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PE2rZ24892 for ; Mon, 25 Feb 2002 16:02:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 16:02:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 25 Feb 2002 16:02:23 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 16:02:22 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A1F@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQCHCO+QAAWOVxA= From: To: , X-OriginalArrivalTime: 25 Feb 2002 14:02:23.0148 (UTC) FILETIME=[0C2D16C0:01C1BE05] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA10477 Hi all, I noticed that my example wasn't exactly correct, here is an update version: === updated example ==== As an example, consider a client that wishes to resolve aaa:example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 50 50 "s" "AAA+D2S" "" _aaa._sctp.example.com. IN NAPTR 90 50 "s" "AAAS+D2T" "" _aaas._tcp.example.com. IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com This indicates that the server supports SCTP, TLS over TCP, and TCP, in that order. Since the client supports SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of _aaa._sctp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 xxxx server1.example.com IN SRV 0 2 xxxx server2.example.com ;; where xxxx is replaced by the well-known port for Diameter John From owner-aaa-wg@merit.edu Mon Feb 25 09:24:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11252 for ; Mon, 25 Feb 2002 09:24:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC4E091244; Mon, 25 Feb 2002 09:24:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B61AD91245; Mon, 25 Feb 2002 09:24:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B810D91244 for ; Mon, 25 Feb 2002 09:24:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8ECBC5DDBA; Mon, 25 Feb 2002 09:24:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 164B55DDAC for ; Mon, 25 Feb 2002 09:24:06 -0500 (EST) Received: (qmail 22008 invoked by uid 500); 25 Feb 2002 14:23:59 -0000 Date: Mon, 25 Feb 2002 08:23:59 -0600 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: [Internet-Drafts@ietf.org: I-D ACTION:draft-frascone-aaa-xml-dictionary-00.txt] Message-ID: <20020225142359.GI12599@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk FYI - ----- Forwarded message from Internet-Drafts@ietf.org ----- From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org To: IETF-Announce: ; CC: aaa-wg@merit.edu Subject: I-D ACTION:draft-frascone-aaa-xml-dictionary-00.txt Date: Mon, 25 Feb 2002 06:22:15 -0500 X-Spam-Status: No, hits=-96.8 required=5.0 tests=NO_REAL_NAME,TO_MALFORMED,EXCUSE_6,A_FROM_IN_AUTO_WLIST version=2.01 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter XML Dictionary Author(s) : D. Frascone et al. Filename : draft-frascone-aaa-xml-dictionary-00.txt Pages : 20 Date : 22-Feb-02 This document describes a coding of Diameter dictionaries in XML. This coding is intended for use by Diameter implementations to represent Applications, Commands, Vendors, and AVPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-frascone-aaa-xml-dictionary-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-frascone-aaa-xml-dictionary-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-frascone-aaa-xml-dictionary-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ----- End forwarded message ----- From owner-aaa-wg@merit.edu Mon Feb 25 10:06:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12978 for ; Mon, 25 Feb 2002 10:05:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5374D91247; Mon, 25 Feb 2002 10:05:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D2A79124A; Mon, 25 Feb 2002 10:05:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F76F91247 for ; Mon, 25 Feb 2002 10:05:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 00C0A5DDB0; Mon, 25 Feb 2002 10:05:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DB2815DD97 for ; Mon, 25 Feb 2002 10:05:47 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 389B081; Mon, 25 Feb 2002 10:05:47 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" , Subject: RE: [AAA-WG]: ISSUE 266: ready for closure? Date: Mon, 25 Feb 2002 10:04:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C1BDE3.DFEBE850" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C757B25.7FA45951@ericsson.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C1BDE3.DFEBE850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Tony, (1) One thought: If the AAAH wants to hide an AAAH-generated key being sent to the FA (or foreign HA), the AAAH sets up a CMS security assocation with the FA (or foreign HA), not with the AAAF. If the destination AAAF wants to hide the FA-HA key, shouldn't it then just do the same, i.e. set up a CMS security assocation with the FA, rather than adding protocol and setting up a CMS security assocation with the originating AAAF? Otherwise, an AAAH wanting to hide an FA-HA key and an AAAF wanting to hide an FA-HA key invoke different solutions. When, in the course of the mailing list dialogue, the HAA-to-AMA-Data AVP was superseded by CMS, this thought hadn't occurred to me. (2) If this thought was adopted, then we wouldn't need the MIP-Originating-Foreign-AAA AVP, since the destination AAAF would be setting up his DSA with the FA. However, the destination AAAF would need to know the FA's DiameterIdentity and the FA's Realm, so the DSAR could be routed. In the HAR, the MIP-Foreign-Agent-Host AVP conveys the FA's DiameterIdentity but not the FA's Realm. So maybe the MIP-Foreign-Agent-Host AVP should be replaced by a MIP-Foreign-Agent grouped AVP, with two members representing the FA's DiameterIdentity and the FA's Realm. The rest of my comments are inline. > From: Tony Johansson [tony.johansson@ericsson.com] > Sent: Thursday, February 21, 2002 5:57 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: ISSUE 266: ready for closure? > > All, > > Here is the text proposal for issue 266 based on the outcome of the > previous thread discussion regarding issue 266: "Returning > AAAF-Generated FA-HA Key to FA". > > This proposal is based on CMS in case of encryption and the fact the > we are allowed to issue DSA messages between two servers, even in the > case where non of the servers belong to the users home domain (see > http://www.merit.edu/mail.archives/aaa-wg/thismonth/msg00042.html). > Stephen, Jari and other CMS knowledge people please let me know if you > have any comments / objection to the usage of CMS in the case of > encryption of the FA-HA Key below. > > Comments / objections > > > /Tony > > .............. > > 1.4 Allocation of Home Agent in Foreign Network > > The Diameter Mobile IP application allows a Home Agent to be > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > When a foreign agent detects that the mobile node has a home agent > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > Request message, it MUST add a MIP-Feature-Vector AVP with the Home- > Agent- Requested flag set to one. If the home agent address is equal > to 255.255.255.255, then the foreign agent also MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > > When the AAAF receives an AMR message with the Home-Agent-Requested > flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm > flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available > flag in the MIP-Feature-Vector AVP to inform the AAAH that it is > willing and able to assign a Home Agent for the Mobile Node. When > doing so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP > and the MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home- > Agent-Host AVP contains the identity of the home agent that would be > assigned to the mobile node and the MIP-Originating-Foreign-AAA AVP > contains the identity of the AAAF. > > In the event that the mobile node requests a home agent in the > foreign network, and the AAAF authorizes its use, the AAAF MUST set > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > This could happen when the AAA request is sent to "extend" a mobile > node's current session. (3) I don't quite understand how the mobile node "requests" a home agent in the foreign network. Maybe the word "request" is what confuses me. That is, the MN can request that a HA be assigned by sending an HA IP address of all zeroes or all ones. 255.255.255.255 means the HA must be allocated in the home network, while 0.0.0.0 means the HA can be allocated in either the local foreign network or the home network. But neither case indicates a preference for a foreign HA over a home network HA. Maybe "requests" means the MN specifies the real IP address of a real HA. In that case the MN is just specifying the HA's IP address, but not indicating whether the HA is in the home realm or a foreign realm. (4) I don't understand how the originating AAAF intelligently sets the Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a "real" HA IP address (not all zeroes or all ones). The AAAF only sees an IP address. The AAAF doesn't know just from the HA's IP address whether that represents an HA in the home network, or an HA in another foreign network. And maybe doesn't even know if the IP address is in his own network. So how does the AAAF set the Home-Agent-In-Foreign-Network flag? It seems that the AAAF would send the MIP-Originating-Foreign-AAA AVP if there is the possibility that the originating AAAF might be part of a DSA. That can happen if either: (a) the AAAF is offering to provide the HA and is sending the MIP-Candidate-Home-Agent-Host AVP, or (b) the MN has specifed a "real" HA IP address (not 0.0.0.0 or 255.255.255.255). If the MIP-Originating-Foreign-AAA goes away, then this is moot. The rule would be that the AAAH always manufactures and sends the new grouped MIP-Foreign-Agent in the HAR. > When the AAAH receives an AMR message, it first checks the > authentication data supplied by the mobile node, according to the > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > to authorize the mobile node. If the AMR indicates that the AAAF has > offered to allocate a home agent for the mobile node, then the AAAH > must decide whether its local policy would allow the user to have a > Home Agent in the foreign network. If so, and after checking > authorization from the data in the AMR message, the AAAH sends the > HAR message to the AAAF that does not contain the MIP-Home-Agent- ^^^^ Technically, the HAR is sent the HA, since the HAR's Destination-Host is the HA. > Address, but includes the Destination-Host AVP set to the value of > the AMR's MIP-Candidate-Home-Agent-Host AVP. > > If the HA hasn't yet been allocated by the foreign domain, the HAR > sent by the AAAH back to the foreign realm will not necessarily be > received by the same AAAF which sent the AMR. Therefore the AAAH MUST > always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message > to the HAR message. In cases when another AAAF, which may not reside > in the same domain, receives the HAR, thus the new AAAF will use the > MIP-Originating-Foreign-AAA-AVP for policy decisions, such as > determining if the FA-HA Key should be encrypted or not. > > .............. > > > 4.11 MIP-Originating-Foreign-AAA AVP > > The MIP-Originating-Foreign-AAA AVP (AVP Code TBD) if of type > Grouped, and contains the identity of the AAAF which issues the AMR > to the AAAH. The MIP- Originating-Foreign-AAA AVP MUST only be used > in cases when the home agent is or may be allocated in a foreign > domain. If present in the AMR, the AAAH MUST copy the MIP- > Originating-Foreign-AAA AVP into the HAR. > > MIP-Originating-Foreign-AAA ::= < AVP Header: ZZZ > > { Origin-Realm } > { Origin-Host } > * [ AVP ] > If the destination AAAF sets up the DSA with the FA, then the above AVP definition goes away. > .............. > > 5.4 Distributing the Foreign-Home Session Key > > If the home agent is in the home realm, then the AAAH has to generate > the Foreign-Home session key. Otherwise, it is generated by AAAF. > (5) Add a section header here, preceding the paragraph that follows: 5.4.1 Home Agent in the home network > In the cases when the AAAH generates the Foreign-Home session key, > the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and > includes the AVP as part of the HAR message sent to the home agent. > The corresponding session key that is to be sent to the foreign agent > is cached in the AAAH until the HAA is received. (6) Replace the last sentence by: "The corresponding session key and algorithm that is to be sent to the foreign agent is cached in the AAAH until the HAA is received." > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > session key, allocates an SPI to be used with the key. The allocated > SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, > using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the > AMA. (7) Add a section header here: 5.4.2 Home Agent in the foreign domain > In the cases when the AAAF generates the Foreign-Home session key > (home agent in foreign domain), the AAAF will, upon receipt of the > HAR message, generate the Foreign-Home session key and include the > session key in the MIP-HA-to-FA-Key AVP as part of the HAR message > forwarded to the home agent. The corresponding session key that is to > be sent to the foreign agent is cached in the AAAF until the HAA is > received. (8) Replace the last sentence by: "The corresponding session key and algorithm that is to be sent to the foreign agent is cached in the AAAF until the HAA is received." > > Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, > using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the > Foreign-Home session key destined for the foreign agent needs to be > encrypted. > > If the session key needs to be encrypted, the AAAF will check if a > security association can be established using DSA messages defined in > the CMS application [CMS] with the originating host found in the MIP- > Originating-Foreign-AAA AVP. If the DSA establishment is successful, > the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted- > Data AVP with the AAAF as originator and the recipient copied from > the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is > included by the AAAF in the HAA destined for the AAAH. Otherwise, if > the DSA establishment fails, the AAAF MUST return a Result-Code AVP > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. (9) Since CMS is a new protocol being rolled out, couldn't the destination AAAF attempt to set up this DSA (because the AAAF "prefers" to hide the FA-HA key), and if the DSA fails, then have the fallback option to send the FA-HA key in the clear. Rather than what the final sentence requires ("if the DSA establishment fails, the AAAF MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.") > If the session key does not need to be encrypted, the AAAF will add > MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the > HAA to the AAAH . > (10) Add the following sentence: "In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the HAA returned to the AAAH." > Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA > Key AVP if present or the CMS-Ecrypted-data AVP if present and not > destined for the AAAH into the AMA. > > If a Foreign-Home session key was present in the AMA, the foreign > agent MUST include the Mobile-Foreign authentication extension in the > Registration Reply, using the newly distributed key. > > ......... > Bob K. ------=_NextPart_000_0000_01C1BDE3.DFEBE850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tony,
 
(1) One thought: If the AAAH = wants to hide=20 an AAAH-generated key being
sent to the FA (or foreign HA), the AAAH = sets up=20 a CMS security
assocation with the FA (or foreign HA), not with the=20 AAAF.  If the
destination AAAF wants to hide the FA-HA key, = shouldn't it=20 then just
do the same, i.e. set up a CMS security assocation with the = FA,=20 rather
than adding protocol and setting up a CMS security assocation = with=20 the
originating AAAF?  Otherwise, an AAAH wanting to hide an = FA-HA key=20 and
an AAAF wanting to hide an FA-HA key invoke different = solutions.
When,=20 in the course of the mailing list dialogue, the HAA-to-AMA-Data
AVP = was=20 superseded by CMS, this thought hadn't occurred to me.
 
(2) If this thought was = adopted, then we=20 wouldn't need the
MIP-Originating-Foreign-AAA AVP, since the = destination AAAF=20 would be
setting up his DSA with the FA.  However, the = destination AAAF=20 would
need to know the FA's DiameterIdentity and the FA's Realm, so = the=20 DSAR
could be routed.  In the HAR, the MIP-Foreign-Agent-Host = AVP=20 conveys
the FA's DiameterIdentity but not the FA's Realm.  So = maybe=20 the
MIP-Foreign-Agent-Host AVP should be replaced by a=20 MIP-Foreign-Agent
grouped AVP, with two members representing the FA's = DiameterIdentity
and the FA's Realm.
 
The rest of my comments are=20 inline.
 

> From: Tony Johansson = [tony.johansson@ericsson.com]
>=20 Sent: Thursday, February 21, 2002 5:57 PM
> To: aaa-wg@merit.edu
> Subject: = [AAA-WG]:=20 ISSUE 266: ready for closure?
>   
> All,=20
>   
> Here is the text proposal for issue = 266=20 based on the outcome of the
> previous thread discussion regarding = issue=20 266: "Returning
> AAAF-Generated FA-HA Key to FA".=20
>   
> This proposal is based on CMS in = case of=20 encryption and the fact the
> we are allowed to issue DSA messages = between=20 two servers, even in the
> case where non of the servers belong to = the=20 users home domain (see
> http://www.merit.edu/mail.archives/aaa-wg/thismonth/msg00042.html).=
>=20 Stephen, Jari and other CMS knowledge people please let me know if = you
>=20 have any comments / objection to the usage of CMS in the case of
> = encryption of the FA-HA Key below.
>   
> = Comments=20 / objections
>  
>   
> = /Tony=20
>   
>    .............. =
>=20
> 1.4  Allocation of Home Agent in Foreign Network
> =
>=20 The Diameter Mobile IP application allows a Home Agent to be
> = allocated=20 in a foreign network, as required in [MIPREQ, CDMA2000].
> When a = foreign=20 agent detects that the mobile node has a home agent
> address = equal to=20 0.0.0.0 or 255.255.255.255 in the Registration
> Request message, = it MUST=20 add a MIP-Feature-Vector AVP with the Home-
> Agent- Requested = flag set=20 to one. If the home agent address is equal
> to 255.255.255.255, = then the=20 foreign agent also MUST set the Home-
>=20 Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home =
>=20 agent address is set to 0.0.0.0, the foreign agent MUST set the Home- =
>=20 Address-Allocatable-Only-in-Home-Realm flag equal to zero.
> =
>=20 When the AAAF receives an AMR message with the Home-Agent-Requested =
>=20 flag set to one, and the Home-Address-Allocatable-Only-in-Home-Realm =
>=20 flag equal to zero, the AAAF MAY set the Foreign-Home-Agent-Available =
>=20 flag in the MIP-Feature-Vector AVP to inform the AAAH that it is =
>=20 willing and able to assign a Home Agent for the Mobile Node. When =
> doing=20 so, the AAAF MUST include the MIP-Candidate-Home-Agent-Host AVP
> = and the=20 MIP-Originating-Foreign-AAA-AVP. The MIP-Candidate-Home-
> = Agent-Host AVP=20 contains the identity of the home agent that would be
> assigned = to the=20 mobile node and the MIP-Originating-Foreign-AAA AVP
> contains = the=20 identity of the AAAF.
>
> In the event that the mobile = node=20 requests a home agent in the
> foreign network, and the AAAF = authorizes=20 its use, the AAAF MUST set
> the Home-Agent-In-Foreign-Network = bit in the=20 MIP-Feature-Vector AVP.
> This could happen when the AAA request = is sent=20 to "extend" a mobile
> node's current session.
 
(3) I don't quite understand = how the mobile=20 node "requests" a home
agent in the foreign network.  Maybe the = word=20 "request" is what
confuses me.
 
That is, the MN can request = that a HA be=20 assigned by sending an HA IP
address of all zeroes or all ones.=20 255.255.255.255 means the HA must
be allocated in the home network, = while=20 0.0.0.0 means the HA can be
allocated in either the local foreign = network or=20 the home network. But
neither case indicates a preference for a = foreign HA=20 over a home
network HA.
 
Maybe "requests" means the MN = specifies the=20 real IP address of a real
HA.  In that case the MN is just = specifying=20 the HA's IP address, but
not indicating whether the HA is in the home = realm=20 or a foreign realm.
 
(4) I don't understand how the = originating=20 AAAF intelligently sets the
Home-Agent-In-Foreign-Network flag. =
 
That is, suppose the MN sends a = "real" HA=20 IP address (not all zeroes
or all ones).  The AAAF only sees an = IP=20 address.  The AAAF doesn't
know just from the HA's IP address = whether=20 that represents an HA in
the home network, or an HA in another = foreign=20 network.  And maybe
doesn't even know if the IP address is in = his own=20 network.  So how
does the AAAF set the = Home-Agent-In-Foreign-Network=20 flag?
 
It seems that the AAAF would = send the=20 MIP-Originating-Foreign-AAA AVP
if there is the possibility that the=20 originating AAAF might be part of
a DSA.  That can happen if = either: (a)=20 the AAAF is offering to provide
the HA and is sending the=20 MIP-Candidate-Home-Agent-Host AVP, or (b)
the MN has specifed a = "real" HA IP=20 address (not 0.0.0.0 or
255.255.255.255).  If the=20 MIP-Originating-Foreign-AAA goes away, then
this is moot.  The = rule=20 would be that the AAAH always manufactures and
sends the new grouped=20 MIP-Foreign-Agent in the HAR.
 
> When the AAAH receives an = AMR message,=20 it first checks the
> authentication data supplied by the mobile = node,=20 according to the
> MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, = and=20 determines whether
> to authorize the mobile node.  If the = AMR=20 indicates that the AAAF has
> offered to allocate a home agent = for the=20 mobile node, then the AAAH
> must decide whether its local policy = would=20 allow the user to have a
> Home Agent in the foreign network. If = so, and=20 after checking
> authorization from the data in the AMR message, = the AAAH=20 sends the
> HAR message to the AAAF that does not contain the=20 MIP-Home-Agent-=20
           &nb= sp;        =20 ^^^^
Technically, the HAR is sent the HA, since the HAR's=20 Destination-Host
is the HA.
 
> Address, but includes the=20 Destination-Host AVP set to the value of
> the AMR's=20 MIP-Candidate-Home-Agent-Host AVP.
>
> If the HA hasn't = yet been=20 allocated by the foreign domain, the HAR
> sent by the AAAH back = to the=20 foreign realm will not necessarily be
> received by the same AAAF = which=20 sent the AMR. Therefore the AAAH MUST
> always copy the=20 MIP-Originating-Foreign-AAA-AVP from the AMR message
> to the HAR = message. In cases when another AAAF, which may not reside
> in = the same=20 domain, receives the HAR, thus the new AAAF will use the
>=20 MIP-Originating-Foreign-AAA-AVP for policy decisions, such as
>=20 determining if the FA-HA Key should be encrypted or not.
>=20
>    ..............
>
>
> = 4.11=20 MIP-Originating-Foreign-AAA AVP
>
> The=20 MIP-Originating-Foreign-AAA AVP (AVP Code TBD) if of type
> = Grouped, and=20 contains the identity of the AAAF which issues the AMR
> to the = AAAH. The=20 MIP- Originating-Foreign-AAA AVP MUST only be used
> in cases = when the=20 home agent is or may be allocated in a foreign
> domain. If = present in=20 the AMR, the AAAH MUST copy the MIP-
> Originating-Foreign-AAA = AVP into=20 the HAR.
>
>    MIP-Originating-Foreign-AAA = ::=3D=20 < AVP Header: ZZZ >=20
>           = ;            =          =20 { Origin-Realm }=20
>           = ;            =          =20 { Origin-Host }=20
>           = ;            =        =20 * [ AVP ]
>
 
If the destination AAAF sets up = the DSA=20 with the FA, then the above
AVP definition goes away.
 
>     = ..............=20
>
> 5.4  Distributing the Foreign-Home Session Key =
>=20
> If the home agent is in the home realm, then the AAAH has to = generate=20
> the Foreign-Home session key. Otherwise, it is generated by = AAAF.=20
>
 
(5) Add a section header here, = preceding=20 the paragraph that follows:
 
5.4.1 Home Agent in the home=20 network
 
> In the cases when the AAAH = generates=20 the Foreign-Home session key,
> the AAAH includes the session key = in the=20 MIP-HA-to-FA-Key AVP, and
> includes the AVP as part of the HAR = message=20 sent to the home agent.
> The corresponding session key that is = to be=20 sent to the foreign agent
> is cached in the AAAH until the HAA = is=20 received.
 
(6) Replace the last sentence=20 by:
 
"The corresponding session key = and=20 algorithm that is to be sent to the
foreign agent is cached in the = AAAH until=20 the HAA is received."
 
>
> Upon receipt of = the HAR, the=20 home agent recovers the Foreign-Home
> session key, allocates an = SPI to=20 be used with the key. The allocated
> SPI is included in the = HAA's=20 MIP-FA-to-HA SPI AVP.
>
> Upon receipt of the HAA, the = AAAH adds=20 the MIP-FA-to-HA Key AVP,
> using the SPI in the = MIP-FA-to-HA-SPI, and=20 includes the AVP in the
> AMA.
 
(7) Add a section header = here:
 
5.4.2 Home Agent in the foreign = domain
 
> In the cases when the AAAF = generates=20 the Foreign-Home session key
> (home agent in foreign domain), = the AAAF=20 will, upon receipt of the
> HAR message, generate the = Foreign-Home=20 session key and include the
> session key in the MIP-HA-to-FA-Key = AVP as=20 part of the HAR message
> forwarded to the home agent. The = corresponding=20 session key that is to
> be sent to the foreign agent is cached = in the=20 AAAF until the HAA is
> received.
 
(8) Replace the last sentence=20 by:
 
"The corresponding session key = and=20 algorithm that is to be sent to the
foreign agent is cached in the = AAAF until=20 the HAA is received."
>
> Upon receipt of the HAA, the AAAF = creates=20 the MIP-FA-to-HA Key AVP,
> using the SPI in the = MIP-FA-to-HA-SPI. The=20 AAAF then checks if the
> Foreign-Home session key destined for = the=20 foreign agent needs to be
> encrypted.
>
> If the = session=20 key needs to be encrypted, the AAAF will check if a
> security=20 association can be established using DSA messages defined in
> = the CMS=20 application [CMS] with the originating host found in the MIP-
>=20 Originating-Foreign-AAA AVP. If the DSA establishment is successful, =
>=20 the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted- =
> Data=20 AVP with the AAAF as originator and the recipient copied from
> = the=20 MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is
> = included by the AAAF in the HAA destined for the AAAH. Otherwise, if =
>=20 the DSA establishment fails, the AAAF MUST return a Result-Code AVP =
>=20 with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.
 
(9) Since CMS is a new protocol = being=20 rolled out, couldn't the
destination AAAF attempt to set up this DSA = (because=20 the AAAF
"prefers" to hide the FA-HA key), and if the DSA fails, then = have=20 the
fallback option to send the FA-HA key in the clear.  Rather = than=20 what
the final sentence requires ("if the DSA establishment fails, = the=20 AAAF
MUST return a Result-Code AVP with=20 DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.")
 
> If the session key does = not need to be=20 encrypted, the AAAF will add
> MIP-FA-to-HA Key to the HAA, upon=20 reception from HA and forward the
> HAA to the AAAH .
>=20
 
(10) Add the following=20 sentence:
 
"In either case, the AAAF = removes the=20 MIP-FA-to-HA-SPI AVP from the
HAA returned to the AAAH."
 
> Upon reception of the HAA, = the AAAH=20 MUST copy either the MIP-FA-to-HA
> Key AVP if present or the=20 CMS-Ecrypted-data AVP if present and not
> destined for the AAAH = into the=20 AMA.
>
> If a Foreign-Home session key was present in the = AMA, the=20 foreign
> agent MUST include the Mobile-Foreign authentication = extension=20 in the
> Registration Reply, using the newly distributed key. =
>=20
> .........
>
 
Bob = K.
------=_NextPart_000_0000_01C1BDE3.DFEBE850-- From owner-aaa-wg@merit.edu Mon Feb 25 10:16:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13293 for ; Mon, 25 Feb 2002 10:16:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9F5039124A; Mon, 25 Feb 2002 10:16:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6F2659124B; Mon, 25 Feb 2002 10:16:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4CA909124A for ; Mon, 25 Feb 2002 10:16:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 26A1C5DDAC; Mon, 25 Feb 2002 10:16:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A1A0E5DD97 for ; Mon, 25 Feb 2002 10:16:30 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1PEaT007481; Mon, 25 Feb 2002 06:36:29 -0800 Date: Mon, 25 Feb 2002 06:36:28 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com Cc: kevin.purser@ericsson.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: ISSUE: invalid reference In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A0A@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Should not cause problems. The peer state machine is present in the base draft, whereas the *failover* state machine is in the transport draft. On Mon, 25 Feb 2002 john.loughney@nokia.com wrote: > Hi Kevin, > > You are correct. > > Bernard, as you are editing the Transport Draft, let me know if this will cause > problems, otherwise I will make the suggested changes. > > John > > > Submitter name: Kevin Purser > > Submitter email address: kevin.purser@ericsson.com > > Date first submitted: February 11th, 2002 > > Reference: none > > Document: base-08alpha02 > > Comment type: Editorial > > Priority: 1 > > Section: 5.6 "Peer State Machine" > > Rationale/Explanation of issue: > > > > There are a couple of references in this section to "the state machine > > described in [52]". However, in the latest version of the > > transport draft, > > such a state machine is not present. > > > > > > Requested change: > > > > Remove these references in the text. > > > > > From owner-aaa-wg@merit.edu Mon Feb 25 11:32:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16764 for ; Mon, 25 Feb 2002 11:32:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E7EAC91210; Mon, 25 Feb 2002 11:30:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5E909124E; Mon, 25 Feb 2002 11:30:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD96E91210 for ; Mon, 25 Feb 2002 11:30:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 885EE5DDA4; Mon, 25 Feb 2002 11:30:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id DC2F85DD93 for ; Mon, 25 Feb 2002 11:30:47 -0500 (EST) Received: from fredrikj (bravo-54.local.ipunplugged.com [192.168.2.54]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA12088 for ; Mon, 25 Feb 2002 17:28:30 +0100 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Issue: Collection of Accounting data Date: Mon, 25 Feb 2002 17:31:20 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Submitter email address: Fredrik@ipunplugged.com Date first submitted: 25 Feb, 2002 Reference: Document: base Comment type: T Priority: 1 Section: base 9.2, Rationale/Explanation of issue: "9.2 Protocol Messages A Diameter node that receives a successful authentication and/or authorization messages from the Home AAA Server, MUST collect accounting information for the session. The Accounting-Request message is used to transmit the accounting information to the Home AAA server, which MUST reply with the Accounting-Answer message to confirm reception..." Why must a accounting message be sent to the Home AAA Server? In the case of Mobile IP, it's quite likely that the operator owning the FA would like to receive the Fa generated accounting records in order to be able to send an invoice to the owner of the mobile node. Suggested solution: alt 1. Not put any restrictions on where to send accounting data, leave it up to the operator to configure the realm routing table correct. I.e. on can send accounting data to a accounting server in the home domain or to a accounting server in the access network. alt 2. By letting each server tell the client in the authentication answer that it would like to receive accounting data. The Aaa-h server can say to which server it would like the data to be sent to. And the Aaa-f can add a AVP saying where it would like the data to be sent. This way both the owner of the home network and the owner of the access network will receive accounting data. To any server with their domains. /Fredrik From owner-aaa-wg@merit.edu Mon Feb 25 11:57:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18427 for ; Mon, 25 Feb 2002 11:57:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A54C19124C; Mon, 25 Feb 2002 11:57:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B3009124D; Mon, 25 Feb 2002 11:57:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5ECA59124C for ; Mon, 25 Feb 2002 11:57:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 671F15DDB3; Mon, 25 Feb 2002 11:56:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 5349A5DDA7 for ; Mon, 25 Feb 2002 11:56:39 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 5869F7E; Mon, 25 Feb 2002 11:56:21 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] More Minor corrections/clarifications to draft-mobileip-08 Date: Mon, 25 Feb 2002 11:55:27 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : More Minor corrections/clarifications to draft-mobileip-08 Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-25-2002 Reference: Document: mobile-ip 08 Comment type: Editorial Priority: 1 Section: Rationale/Explanation of issue: Minor corrections/clarifications. Requested change: In Section 1 "INTRODUCTION" > An AAA Home server (AAAH) and AAA foreign server (AAAF) which > supports the Mobile-IP authentication application MAY maintain > session-state or MAY be session-stateless. AAA redirect agents and > AAA relay agents MUST not maintain session-state. AAAH, AAAF, proxies > and relays agents MUST maintain transaction state. Change the beginning of the last sentence from "AAAH..." to "The AAAH...". - - - - - In Section 1.4 "Allocation of Home Agent in Foreign Network" Since the AAAF has to send an HAA whether the HA's Result-Code is success or not: Replace > Upon receipt of a HAA from the Home Agent in the visited realm, with > the Result-Code AVP indicating success, the AAAF forwards the HAA to > the AAAH in the home realm. The AMA is then constructed, and issued > to the AAAF, and finally to the FA. The HAA and AMA MUST include the > MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. With: Upon receipt of a HAA from the Home Agent in the visited realm, the AAAF forwards the HAA to the AAAH in the home realm. The AMA is then constructed, and issued to the AAAF, and finally to the FA. If the Result-Code indicates success, the HAA and AMA MUST include the MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. Similarly, replace: > When the AAAF receives a successful HAA, the AAAF will forward the > HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address > and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an > AMA to the AAAF in foreign network 2. With: When the AAAF receives a HAA, the AAAF will forward the HAA back to the AAAH. If successful, the HAA MUST include the MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an AMA to the AAAF in foreign network 2. In the final paragraph of this section: > If the old Foreign Network does not permit the use of its Home Agent > when the Mobile Node moves to a new foreign network, the AAAH or AAAF > MUST return an AMA with the Result-Code AVP set to > DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the > Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile > Node with an appropriate error. The Mobile Node MAY attempt to > request that a new Home Agent and Address be allocated. When the AAAH > transmits such an error, it MUST issue a Diameter Abort-Session- > Request message to the AAAF overseeing the Home Agent to enable it to ^^^^^^^^^^^^^^^ Remove "AAAF overseeing". I think the ASR goes to the Home Agent. I'm not sure the AAAH even has the AAAF's DiameterIdentity to target the ASR there. > release any resources. - - - - - In section 5.1 "Key Material vs. Session Key" > The AAAH then generates the session key which is destined for the > mobility agent, in this case the foreign agent, by following the > above procedures. It is important that the hashing algorithm used by > the mobile node is the same as the one used by the AAAH in the > session key generation procedure. Therefore, the AAAH MUST know a > priori the transform used, which is typically contained in the mobile > node's configuration profile. Remove the last two sentences, which begin "It is important..." and "Therefore...". I think this is outdated baggage. The AAAH indicates the algorithm used and the SPI in the Key AVPs which contain key material, so the a priori stuff goes away. Or if you don't want to remove them, then replace them with "It is important that the hashing algorithm used by the mobile node to construct the session key is the same as the one used by the AAAH in the session key generation procedure. The AAAH therefore indicates the transform used along with the key material." > The session keys destined for mobility > agents are encoded using the security association available between Change "are encoded" to "may be encoded". The other places in the draft indicate that hiding the keys is a SHOULD or MAY. > the AAA server and the agents (e.g. IPSec, TLS, CMS). > The Foreign-Home session key is shared between two mobility agents: > the FA and HA. Since this key is not destined for the mobile node, > there is no need to follow the session key generation procedures > detailed above. Instead, the AAAH generates a random [18] value of at > least 64 bits for use as the Foreign-Home session key. - - - - - In section 5.2 "Distributing the Mobile-Home Session Key" Since the HAR still contains the HA's identity as the Destination-Host, Replace: > If, on the other hand, the home agent is to be allocated in the > visited realm, the AAAH does not transmit the HAR to the home agent, > but instead transmits the HAR to the AAAF. With: "If, on the other hand, the home agent is to be allocated in the visited realm, the AAAH transmits the HAR to the foreign home agent, where, prior to delivery to the home agent, it is perused by the AAAF hosting the home agent." - - - - - In section 6.11 "MIP-FA-to-HA-SPI AVP" > The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and > contains the Security Parameter Index the Foreign Agent is to use to > refer to the session key it shares with the Home Agent. The SPI > created MUST NOT be a value between zero (0) and 255, which is the > reserved namespace defined in [4]. This AVP MAY be added in the HAA > message by the Home Agent for the AAAH's use in MIP-FA-to-HA-SPI AVP > of the MIP-FA-to-HA-Key AVP. Replace the last sentence by: "If FA-HA keys are being generated, this AVP MUST be added in the HAA message by the Home Agent for the AAAH's (or AAAF's) use in providing the value of the MIP-FA-to-HA-SPI member of the grouped MIP-FA-to-HA-Key AVP." - - - - - From owner-aaa-wg@merit.edu Mon Feb 25 12:34:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20461 for ; Mon, 25 Feb 2002 12:34:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9EB8F91211; Mon, 25 Feb 2002 12:34:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70A2C9121C; Mon, 25 Feb 2002 12:34:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F90991211 for ; Mon, 25 Feb 2002 12:34:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 164B35DDC1; Mon, 25 Feb 2002 12:34:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id 9878D5DD94 for ; Mon, 25 Feb 2002 12:34:12 -0500 (EST) Subject: [AAA-WG]: RE: Diameter CCA: Number of sessions per user To: "Harri Hakala (LMF)" , aaa-wg@merit.edu, "Stefan Karlsson (EPK)" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Mon, 25 Feb 2002 18:34:00 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/25/2002 06:34:13 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Harri, ....(I hop you had enjoyed your hollidays).... Ok, Harri..... Certainly, I had to be suppossed the AVP included in the ACR/ACA messages are included as well. Excuse my unknowledge. Regards, Paco. "Harri Hakala (LMF)" con fecha 25/02/2002 14:35:00 Asunto: RE: Diameter CCA: Number of sessions per user Hi Paco, >the credit not consumed must be returned back to the user account, it >means the money to return back is the 'reserved' credit minus the credit corresponding to the >'Used-Service-Units'.... Is it OK? YES The credit control application contains all accounting AVPs specified in the base protocol, only the additional AVPs are listed in the draft, so the second option is covered. Regards............Harri -----Original Message----- From: fmaring@airtel.es [mailto:fmaring@airtel.es] Sent: 21. helmikuuta 2002 19:12 To: aaa-wg@merit.edu Cc: harri.hakala@lmf.ericsson.se; stefan.karlsson@epk.ericsson.se Subject: Diameter CCA: Number of sessions per user Hi All, In the point 3.2 of the document 'Diameter Credit Control Application', is described the Service Credit Control using several interrogations (session control). When a session is opened (START_RECORD), the client ask for the server an amount of credit (stated in money, service units and so on....) which is reserved until the next request (ACR) of the multi-interrogations dialogue is received (INTERIM_RECORD or STOP_RECORD). When this new ACR is recived, a new amount of credit asked by the client is reserved. As described in the document this amount of credit 'reserved' for the user is stored in the server, so when the client finishes the dialogue (STOP_RECORD), the ACR includes the 'Used-Service-Units' AVP indicating the real amount of credit consumed since the previous interrogation. Then, the credit not consumed must be returned back to the user account, it means the money to return back is the 'reserved' credit minus the credit corrsponding to the 'Used-Service-Units'.... Is it OK? The question is: What happens when the user has serveral sessions opened at time? There is nothing about that in the document but I suppose that we can not establish limits for the number of sessions a user can have at time. A user could be downloading a document at the same time he is looking for the neares restaurant or buying the tickets for the last Swertzeneger film. I suppose the server must be able to identify which ACR corresponds to which session, however.... How could the server identify this session? Maybe I'm confused but I did not find neither an AVP able to identify it, nor a field corresponding to the Diameter Base protocol able to be used to identify the session (I understand the server cannot use neither the 'Hop-by-Hop' nor the 'End-to-End' identifier to associate that a received request corresponds to a specific session opened. This way, when a user has several sessions opened and receives a request (INTERIM_RECORD as an example) must be able to know which session must delete the stored credit and reserve a new credit again. I have been thinking about two solutions: 1.- Not to store the reserved credit in the server. The client could ask for the credit and receive it in the 'Granted-Service-Units' AVP, when the session is finished the client could send a different AVP called 'Remaining-Service-Units' instead of the 'Used-Service-Units' AVP. This way the session have not to be controlled by the server. This solution could have a problem, the fraud produced due to the lack of the session by the server. The server must trust the client, because the client could set the 'Remaining-Service-Units' AVP to a random value.... It could be difficult if the home domain receives request from clients from visited domains, a formal agreement must exists in this scenario to avoid fraud. 2.- Introduce in the request and answer the AVP called 'Session-ID' (code 263) to identify the session. This way the session is always identified for session oriented service control (several queries). In my humble oppinion, the second one is the best option to be able to solve this problem. regards, Paco. From owner-aaa-wg@merit.edu Mon Feb 25 12:42:08 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21387 for ; Mon, 25 Feb 2002 12:42:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 621BF9121F; Mon, 25 Feb 2002 12:40:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2973291254; Mon, 25 Feb 2002 12:40:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2642E9121F for ; Mon, 25 Feb 2002 12:40:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F17D5DDB6; Mon, 25 Feb 2002 12:40:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id EF7475DD94 for ; Mon, 25 Feb 2002 12:40:01 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9C9337E for ; Mon, 25 Feb 2002 12:40:01 -0500 (EST) Message-ID: <3C7A76F6.9B419F75@Interlinknetworks.com> Date: Mon, 25 Feb 2002 12:40:06 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] 'M' Bit at fault rules still not right Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] 'M' Bit at fault rules still not right Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: February 25, 2002 Reference: Document: Base Comment type: T Priority: S Section: 4.1 Rationale/Explanation of issue: The AVP Flag rules tables in the various Diameter drafts specify in which AVPs the 'M' bit MUST be set, in which AVPs it MUST NOT be set, etc. However section 4.1 of the base draft states: A Diameter node that sets the 'M' bit in an AVP that is not defined in a given message's ABNF is at fault if the message is rejected. In the next paragraph it states: A Diameter node that rejects a message due to an unrecognized AVP with the 'M' bit set, and the AVP in question is defined in the message's ABNF, is at fault. These sentences make the criterion for setting the 'M' bit be whether or not the AVP is listed in the formal syntax for the message in which it appears. This is in direct contradiction to the criterion that the 'M' bit should be set according to the specification in the AVP Flag rules table of the draft defining the AVP. Life gets complicated, however, when an AVP defined in one Diameter Application or a vendor-specific AVP gets included in a message defined in another Diameter Application. This is allowed for most Diameter messages because the "* [ AVP ]" construct appears in most message specifications. So what happens if the sender of the message considers such an AVP to be critical to its intent, but the recipient of the message does not understand the AVP? The answer is that an interoperability failure happens. Some have argued (I have at times) that Diameter's open-ended extensibility is actually one of its weaknesses. At the AAA WG interim meeting in Santa Clara in May 2001, the extensibility-is-good faction reached a compromise with the interoperability-failures-are-bad faction that resulted in the at fault rules that appear in section 4.1 of the base draft. The issue here is that it is important to get the rules right. Considering that a Diameter node may include non-standard AVPs, and considering that it may be critical to the security or business requirements of the parties involved to know whether or not such AVPs are accepted and processed, and considering that interoperability failures are not in the best interests of any of the parties involved, I propose the following principles to govern setting of the 'M' bit: 1) AVP specifiers should be encouraged to require setting the 'M' bit of any AVP for which the interest of any of the parties would be hurt were the AVP to be ignored. 2) Implementors should be required to provide alternatives to sending non-standard AVPs with the 'M' bit set. These may include: a) If a message is rejected because it contains a non-standard AVP with the 'M' bit set, the implementation may resend the message without the AVP, possibly inserting additional standard AVPs instead. b) A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular non-standard, Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problems. 3) An implementation that does not comply with the above requirements is not compliant with the Diameter standard. Examples -------- Example 1: If I were to define a vendor-specific Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify that the 'M' bit MUST be set (I certainly don't want the filters to be ignored). An implementation sending this AVP would be compliant if, upon receiving a rejection for a message containing the AVP, it re-sent the message with the NAS-Filter-Rule AVP in place of the Interlink-Wowee-Zowee-Filter-Rule AVP. Alternatively, an implementation could achieve compliance by offering a per-realm configuration option to control what realms to send the Interlink-Wowee-Zowee-Filter-Rule AVP to. Example 2: NASCO NASes always include the NAS-Filter-Rule AVP in Accounting-Request messages on the theory that inclusion of this AVP in accounting records may be critical to some providers' auditing requirements. NASCO is permitted to do this because the construct "* [ AVP ]" appears in the formal syntax of the Accounting-Request message. The 'M' bit is set because the table in section 2.1 of the NASREQ standard requires it. ACME Accounting Servers do not understand the NAS-Filter-Rule AVP. If they receive an Accounting Request message for a NASREQ session that includes the NAS-Filter-Rule AVP with the 'M' bit set, they reject the message. Thus no accounting can ever happen between a NASCO NAS and an ACME Accounting Server. Who is at fault? ACME argues that according to Diameter-08, NASCO is at fault because neither of the tables in section 10.2 of NASREQ list the NAS-Filter-Rule AVP. Requested change: Replace the at fault rules in section 4.1 with the following text. (Note: the editor may decide to move this discussion to another, more appropriate section of the draft.) The 'M' bit MUST be set according to the rules defined for the AVP containing it. In order to preserve interoperability, a Diameter implementation MUST be able to exclude from a Diameter message any Mandatory AVP which is neither defined in the base Diameter standard nor in any of the Diameter Application specifications governing the message in which it appears. It MAY do this in one of the following ways: 1) If a message is rejected because it contains a Mandatory AVP which is neither defined in the base Diameter standard nor in any of the Diameter Application specifications governing the message in which it appears, the implementation may resend the message without the AVP, possibly inserting additional standard AVPs instead. 2) A configuration option may be provided on a system wide, per peer, or per realm basis that would allow/prevent particular Mandatory AVPs to be sent. Thus an administrator could change the configuration to avoid interoperability problems. Diameter implementations are required to support all Mandatory AVPs which are allowed by the message's formal syntax and defined either in the base Diameter standard or in one of the Diameter Application specifications governing the message. From owner-aaa-wg@merit.edu Mon Feb 25 13:14:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22662 for ; Mon, 25 Feb 2002 13:14:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CF6C39124D; Mon, 25 Feb 2002 13:12:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9506591250; Mon, 25 Feb 2002 13:12:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 655D09124D for ; Mon, 25 Feb 2002 13:11:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C0075DDA4; Mon, 25 Feb 2002 13:11:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 2D57A5DD94 for ; Mon, 25 Feb 2002 13:11:57 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id DAFA37E; Mon, 25 Feb 2002 13:11:56 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: (draft-mobileip-08) Session-Binding & Re-Auth-Request-Type clarifications Date: Mon, 25 Feb 2002 13:11:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A couple clarifications. My real concern is interoperability: that the mobility agents know what to expect from the AAA servers. Session-Binding AVP -------------------- Section 1.2. of draft-mobileip-08 says: > 1.2 Inter-Realm Mobile IP > > [...] > > In the event that the AMR generated by the FA is for a session that > has was previously authorized by the AAAH, it MUST include the > Destination-Host AVP, with the identity of the AAAH. (1) Question: Does this mean the AAAH, when sending back an AMA, should include a Session-Binding AVP with the RE-AUTH flag OFF? Recall that the Base drafts says that "The Session-Binding AVP MAY be present in application-specific authorization answer messages. If present, this AVP MAY inform the Diameter client that all future application-specific re-auth messages for this session MUST be sent to the same authorization server." So the Session-Binding AVP can be used to specify the exact behavior that draft-mobileip-08 wants from the FA. Or, putting the question another way, since this is the required behavior of the FA, is it necessary for the AAAH to send the Session-Binding AVP? (2) The Session-Binding AVP is not mentioned at all in draft-mobileip-08; not in the AMR/AMA/HAR/HAA occurrence rule table, not in the message ABNF, not in the text. So maybe add an occurrence rule entry like: Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Session-Binding | 0 | 0-1 | 0 | 0 | .............................................................. Re-Auth-Request-Type AVP ------------------------ (3) Question: Should the AAAH, when sending back an AMA which includes a positive Authorization-Lifetime, also send a Re-Auth-Request-Type AVP with the value AUTHORIZE_AUTHENTICATE (to let the FA know the re-auth requirements)? This seems so, since the occurrence rules indicate the Re-Auth-Request-Type can be present 0-1 times in an AMA. From owner-aaa-wg@merit.edu Mon Feb 25 16:01:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29883 for ; Mon, 25 Feb 2002 16:01:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AEB6B91254; Mon, 25 Feb 2002 16:00:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E8B191256; Mon, 25 Feb 2002 16:00:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96DF291254 for ; Mon, 25 Feb 2002 16:00:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7BD885DD9A; Mon, 25 Feb 2002 16:00:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 68B545DD8C for ; Mon, 25 Feb 2002 16:00:49 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 260EB7B for ; Mon, 25 Feb 2002 16:00:49 -0500 (EST) Message-ID: <3C7AA605.B9745549@Interlinknetworks.com> Date: Mon, 25 Feb 2002 16:00:53 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Fix conflicting AVP codes in NASREQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Fix conflicting AVP codes in NASREQ Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: February 25, 2002 Reference: Document: NASREQ Comment type: T Priority: S Section: various Rationale/Explanation of issue: In NASREQ-08, AVP Code 409 is assigned to two different AVPs: CHAP-Auth NAS-Key-Lifetime AVP Code 410 is also assigned to two different AVPs: CHAP-Ident NAS-IV Requested change: I have assigned a new AVP Code to NAS-Key-Lifetime: 413 I have assigned a new AVP Code to NAS-IV: 414 From owner-aaa-wg@merit.edu Mon Feb 25 16:18:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00248 for ; Mon, 25 Feb 2002 16:18:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64B3E91255; Mon, 25 Feb 2002 16:18:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 309DB91256; Mon, 25 Feb 2002 16:18:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 40AD191255 for ; Mon, 25 Feb 2002 16:18:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 260E95DDA7; Mon, 25 Feb 2002 16:18:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 128F65DD8C for ; Mon, 25 Feb 2002 16:18:06 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id C32507B; Mon, 25 Feb 2002 16:18:05 -0500 (EST) Message-ID: <3C7AAA12.B5E09797@Interlinknetworks.com> Date: Mon, 25 Feb 2002 16:18:10 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 246: Accounting-*-Extended-Octets numbers are inconsistent References: <200111211435.JAA29699@knox6039.cisco.com> Content-Type: multipart/mixed; boundary="------------816A40877F73A12A645B3305" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------816A40877F73A12A645B3305 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Eklund wrote: > > Submitter name: Mark Eklund > Submitter email address: meklund@cisco.com > Date first submitted: 21-Nov-01 > Reference: Version 8 > Document: nasreq > Comment type: E > Priority: 1 > Section: 2.2, 8.* > Rationale/Explanation of issue: > > The AVP numbers are inconsistent. > > Section 2.2 8.0 > Accounting-Input-Extended-Octets 42/Unsigned64 363/Unsigned64 > Accounting-Input-Extended-Packets 57/Unsigned64 365/Unsigned64 > Accounting-Output-Extended-Octets 43/Unsigned64 364/Unsigned64 > Accounting-Output-Extended-Packets 48/Unsigned64 366/Unsigned64 > > Also, AVPs with values greater than 255 shouldn't be listed in section > 2.2, "Legacy RADIUS Attributes". > > Requested change: > > Fix the numbers in section 2.2. Per Issue 285, I have removed the definitions of thise four AVPs from NASREQ. They are to be moved to the base. Therefore, the lines containing the erroneous AVP Codes have been deleted. > > Move AVPs with values greater than 255 to section 2.1. Done. --------------816A40877F73A12A645B3305 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------816A40877F73A12A645B3305-- From owner-aaa-wg@merit.edu Mon Feb 25 17:51:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02846 for ; Mon, 25 Feb 2002 17:51:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80AE69125E; Mon, 25 Feb 2002 17:51:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 548259125F; Mon, 25 Feb 2002 17:51:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 62C069125E for ; Mon, 25 Feb 2002 17:51:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 49EFC5DDA3; Mon, 25 Feb 2002 17:51:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id E2BD95DD97 for ; Mon, 25 Feb 2002 17:51:28 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1PMphG12350 for ; Mon, 25 Feb 2002 16:51:43 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 25 Feb 2002 16:51:27 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 25 Feb 2002 16:50:13 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Mon, 25 Feb 2002 16:50:12 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12805@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG99H/xJqOP4tNKTTehWxEixcuMmQAWioGg From: To: , Cc: X-OriginalArrivalTime: 25 Feb 2002 22:50:13.0256 (UTC) FILETIME=[C9081080:01C1BE4E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA02846 Hello Johan, Comments inline: Johan Johansson [johanj@ipunplugged.com] wrote: >Just one question: why is it limited to accounting messages? As far as I >can tell the bit means "resent" and I can't instantly think of why it >wouldn't be just as good for non-accounting requests. > The 'D' bit *can* be applied to any diameter message but there is already a mechanism that uses the e2e identifier in the Diameter header which helps in duplicate detection of Diameter messages. Accounting records have uniqueness constraints extending beyond the control of the diameter server. The 'D' bit is intended to help implementations maintaining such uniqueness constraints. >j -Basavaraj >> >>john.loughney@nokia.com wrote: > >>(possibly) D(uplicated) >> - This bit is defined only for Accounting Requests, >> sent by a Diameter node or proxy. >> If set, the message is possibly a duplicate, >> and must be later checked by a recipient node >> if it really is a duplicate. If sending a >> message for first time, this bit MUST be >> cleared. >> This bit MUST NOT be set if an answer message >> (about e.g. a protocol error) has been got for >> an earlier similar message. It can be used only >> in cases where no answer has been got from the >> primary agent for a message and the message is >> sent again (e.g. due to a failover, to an >> alternate agent or to a recovered primary peer >> node). >> From owner-aaa-wg@merit.edu Mon Feb 25 18:00:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03248 for ; Mon, 25 Feb 2002 18:00:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 80C2D9125F; Mon, 25 Feb 2002 18:00:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10DF091260; Mon, 25 Feb 2002 18:00:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 44C1B9125F for ; Mon, 25 Feb 2002 18:00:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 185295DDA3; Mon, 25 Feb 2002 18:00:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 0365F5DD97 for ; Mon, 25 Feb 2002 18:00:00 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 514C27B; Mon, 25 Feb 2002 18:00:00 -0500 (EST) Message-ID: <3C7AC1F4.D8749A7C@Interlinknetworks.com> Date: Mon, 25 Feb 2002 18:00:04 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, tony.johansson@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Accouting AVP issue... References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649EF@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------0B99C68AC51936A87559E3A4" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------0B99C68AC51936A87559E3A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Well, this is a jolly good time to be having philosophic discussions. But here goes... O.K. We decided to define the acounting AVPs in the applications. But we also decided that if an application could reuse an existing AVP, it should. As sec 2.3.1 of Base-08 says: New applications should attempt to reuse AVPs defined in existing application when possible, as opposed to creating a new AVP. So perhaps one of the applications should define the five overlapping AVPs and the other should reference them. Defining them in multiple places creates inconsistencies. How could that possibly happen, you ask, in this age of cut and paste? Well, believe it or not, it already has happened. Compare the definition of Accounting-Input-Extended-Octets in MIP with that in NASREQ: MIP: 7.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received from the user. NASREQ: 8.1 Accounting-Input-Extended-Octets AVP The Accounting-Input-Extended-Octets AVP (AVP Code 363) is of type Unsigned64, and contains the number of octets in IP packets received by the user. "from the user" or "by the user"? MIP is right, in this case; NASREQ is wrong. The definition of Accounting-Input-Extended-Packets has the same problem. Now one may argue that different applications may have to define how they use an AVP. This really would be a good argument for saying something about the AVP in two places. But the definition, at least should be word-for-word the same. Well it just happens that these particular AVPs are good examples of where each application might indicate how it does use them. For instance when a NAS counts input octets, where and how does it count them? The answer is not at all obvious to me from reading the above definition. Does a NAS, for instance, count on the user port side or on the network side. On the user side, we do PPP, so do we count the PPP header octets? Well at least, you say, counting the octets in the layer 3 packet is easy. Oh, yeah? Well what if the PPP link uses Van Jacobson compression? Then the number of IP and TCP header octets counted on the user side is different than on the network side. And what about fragmentation? And what about framing characters used on asynchronous lines? And on, and on, and on. So I ask myself, "Could RADIUS really have been as sloppy as that?" The answer is no, it wasn't. RADIUS is much less vague. RADIUS defines its Acct-Input-Octets attribute as follows: This attribute indicates how many octets have been received from the port over the course of this service being provided, and can only be present in Accounting-Request records where the Acct- Status-Type is set to Stop. RADIUS says to count the octets as they're received over the port. Thus the count would include the PPP header but not the octets saved due to Van Jacobson compression. But somehow we lost that in the Diameter NASREQ draft. So, after all this rambling, I suggest the following: 1) Both MIP and NASREQ should define the AVPs. 2) Both drafts should contain the verbatim text that is now in MIP (not the erroneous text that is now in NASREQ). 3) The NASREQ draft should contain additional NASREQ usage instructions copied verbatim from RADIUS except for the part about only being present in stop records, which is no longer true.] 4) The MIP editor may want to consider adding usage instructions as well. 5) The word Extended should be removed from from the attribute names. The difference between the Acct- prefix and the Accounting- prefix can distinguish the RADIUS attributes from the Diameter attributes. Also the AVP codes are different -- 363-366 for the Diameter AVPs. 6) The Accounting-Session-Time AVP should be renamed to Acct-Session-Time for compatibility with RADIUS because it shares the RADIUS AVP Code of 46. john.loughney@nokia.com wrote: > > Hi all, > > > A few revisions ago, the base included the accounting AVPs. An issue > > vwas created by Glen Zorn, and with WG concensus the AVPs were moved > > to the application specs. > > If we want to now go back in time, we should go back and understand > > the original reasoning for moving the AVPs to the application specs. > > I'm going to side with Pat on this. I think we can forever go back > and forth, and get nowhere. Let's keep the current text/solution. > > John --------------0B99C68AC51936A87559E3A4 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------0B99C68AC51936A87559E3A4-- From owner-aaa-wg@merit.edu Mon Feb 25 18:21:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03763 for ; Mon, 25 Feb 2002 18:21:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CFD8E91260; Mon, 25 Feb 2002 18:21:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9FA5791261; Mon, 25 Feb 2002 18:21:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6CE5591260 for ; Mon, 25 Feb 2002 18:21:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 310AB5DDA3; Mon, 25 Feb 2002 18:21:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id C75DF5DDCA for ; Mon, 25 Feb 2002 18:21:43 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1PNLgS21522; Mon, 25 Feb 2002 17:21:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1PNLgK02327; Mon, 25 Feb 2002 17:21:42 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA12316; Mon, 25 Feb 2002 17:21:42 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA08987; Mon, 25 Feb 2002 17:21:39 -0600 (CST) Message-ID: <3C7AC672.644E268@ericsson.com> Date: Mon, 25 Feb 2002 15:19:15 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE 266: ready for closure? References: Content-Type: multipart/alternative; boundary="------------5E36FB7E81448988ED03E4D0" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------5E36FB7E81448988ED03E4D0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bob, Well, we must still make it possible encrypt the FA-HA Key between the two AAAFs involved, since there is only a SHOULD for Diameter clients to support DSA. Furthermore, how often do we really see the scenario where the home AAAF and the FA don't trust each other so that it is not enough to encrypt between the two AAAF servers?! /Tony Bob Kopacz wrote: > Hi Tony,(1) One thought: If the AAAH wants to hide an AAAH-generated > key being > sent to the FA (or foreign HA), the AAAH sets up a CMS security > assocation with the FA (or foreign HA), not with the AAAF. If the > destination AAAF wants to hide the FA-HA key, shouldn't it then just > do the same, i.e. set up a CMS security assocation with the FA, rather > > than adding protocol and setting up a CMS security assocation with the > > originating AAAF? Otherwise, an AAAH wanting to hide an FA-HA key and > > an AAAF wanting to hide an FA-HA key invoke different solutions. > When, in the course of the mailing list dialogue, the HAA-to-AMA-Data > AVP was superseded by CMS, this thought hadn't occurred to me. (2) If > this thought was adopted, then we wouldn't need the > MIP-Originating-Foreign-AAA AVP, since the destination AAAF would be > setting up his DSA with the FA. However, the destination AAAF would > need to know the FA's DiameterIdentity and the FA's Realm, so the DSAR > > could be routed. In the HAR, the MIP-Foreign-Agent-Host AVP conveys > the FA's DiameterIdentity but not the FA's Realm. So maybe the > MIP-Foreign-Agent-Host AVP should be replaced by a MIP-Foreign-Agent > grouped AVP, with two members representing the FA's DiameterIdentity > and the FA's Realm. --------------5E36FB7E81448988ED03E4D0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bob,

Well, we must still make it possible encrypt the FA-HA Key between the two AAAFs involved, since there is only a SHOULD for Diameter clients to support DSA. Furthermore, how often do we really see the scenario where the home AAAF and the FA don't trust each other so that it is not enough to encrypt between the two AAAF servers?!

/Tony
 
 

Bob Kopacz wrote:

 Hi Tony,(1) One thought: If the AAAH wants to hide an AAAH-generated key being
sent to the FA (or foreign HA), the AAAH sets up a CMS security
assocation with the FA (or foreign HA), not with the AAAF.  If the
destination AAAF wants to hide the FA-HA key, shouldn't it then just
do the same, i.e. set up a CMS security assocation with the FA, rather
than adding protocol and setting up a CMS security assocation with the
originating AAAF?  Otherwise, an AAAH wanting to hide an FA-HA key and
an AAAF wanting to hide an FA-HA key invoke different solutions.
When, in the course of the mailing list dialogue, the HAA-to-AMA-Data
AVP was superseded by CMS, this thought hadn't occurred to me. (2) If this thought was adopted, then we wouldn't need the
MIP-Originating-Foreign-AAA AVP, since the destination AAAF would be
setting up his DSA with the FA.  However, the destination AAAF would
need to know the FA's DiameterIdentity and the FA's Realm, so the DSAR
could be routed.  In the HAR, the MIP-Foreign-Agent-Host AVP conveys
the FA's DiameterIdentity but not the FA's Realm.  So maybe the
MIP-Foreign-Agent-Host AVP should be replaced by a MIP-Foreign-Agent
grouped AVP, with two members representing the FA's DiameterIdentity
and the FA's Realm.
--------------5E36FB7E81448988ED03E4D0-- From owner-aaa-wg@merit.edu Mon Feb 25 19:46:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05146 for ; Mon, 25 Feb 2002 19:46:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A5C8791224; Mon, 25 Feb 2002 19:45:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77C6691261; Mon, 25 Feb 2002 19:45:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85D8491224 for ; Mon, 25 Feb 2002 19:45:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64EE05DDA8; Mon, 25 Feb 2002 19:45:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 51E995DD9A for ; Mon, 25 Feb 2002 19:45:45 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5885A7B; Mon, 25 Feb 2002 19:45:42 -0500 (EST) Message-ID: <3C7ADAB7.20E19D97@Interlinknetworks.com> Date: Mon, 25 Feb 2002 19:45:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Eklund , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 246: Accounting-*-Extended-Octets numbers are inconsistent References: <200111211435.JAA29699@knox6039.cisco.com> <3C7AAA12.B5E09797@Interlinknetworks.com> Content-Type: multipart/mixed; boundary="------------BDC5910307A20DCA2036A526" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------BDC5910307A20DCA2036A526 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Oops! After taking the accounting AVPs out of NASREQ per issue 285, it looks as if I may have to put them back in. If so, I will put them in section 2.1 with the codes 363-366. David Spence wrote: > > Mark Eklund wrote: > > > > Submitter name: Mark Eklund > > Submitter email address: meklund@cisco.com > > Date first submitted: 21-Nov-01 > > Reference: Version 8 > > Document: nasreq > > Comment type: E > > Priority: 1 > > Section: 2.2, 8.* > > Rationale/Explanation of issue: > > > > The AVP numbers are inconsistent. > > > > Section 2.2 8.0 > > Accounting-Input-Extended-Octets 42/Unsigned64 363/Unsigned64 > > Accounting-Input-Extended-Packets 57/Unsigned64 365/Unsigned64 > > Accounting-Output-Extended-Octets 43/Unsigned64 364/Unsigned64 > > Accounting-Output-Extended-Packets 48/Unsigned64 366/Unsigned64 > > > > Also, AVPs with values greater than 255 shouldn't be listed in section > > 2.2, "Legacy RADIUS Attributes". > > > > Requested change: > > > > Fix the numbers in section 2.2. > > Per Issue 285, I have removed the definitions of thise four AVPs from > NASREQ. They are to be moved to the base. Therefore, the lines containing > the erroneous AVP Codes have been deleted. > > > > > Move AVPs with values greater than 255 to section 2.1. > > Done. --------------BDC5910307A20DCA2036A526 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------BDC5910307A20DCA2036A526-- From owner-aaa-wg@merit.edu Mon Feb 25 20:23:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05482 for ; Mon, 25 Feb 2002 20:23:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 74FC491261; Mon, 25 Feb 2002 20:23:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CAA591262; Mon, 25 Feb 2002 20:23:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 120BE91261 for ; Mon, 25 Feb 2002 20:23:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id E51EE5DDA3; Mon, 25 Feb 2002 20:23:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id B35655DD9A for ; Mon, 25 Feb 2002 20:23:43 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1Q1NgS24368; Mon, 25 Feb 2002 19:23:43 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1Q1NgE01598; Mon, 25 Feb 2002 19:23:42 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA23433; Mon, 25 Feb 2002 19:23:42 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA10795; Mon, 25 Feb 2002 19:23:41 -0600 (CST) Message-ID: <3C7AE30D.E150E8F6@ericsson.com> Date: Mon, 25 Feb 2002 17:21:17 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Pat R. Calhoun" Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP References: Content-Type: multipart/alternative; boundary="------------1D4BBD5D840643A8EB7AABB0" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------1D4BBD5D840643A8EB7AABB0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Pat R. Calhoun" wrote: > > > But, in the AAA Registration Keys for Mobile IP, which we are > > dependent on, you can only > tell the mobile one timer (the > > Lifetime). The Lifetime AAA Registration Keys for Mobile IP > > indicates the duration of time (in seconds) for which the MN-FA and > > MN-HA keys are valid. When the keys expires the MN must re-auth, > > so seen from the MN the authorization lifetime and the key > > lifetime is very much the same thing. Right? > > But there is a fundamental difference between the Lifetime field in > the MIP header, and the lifetime fields in the individual aaa-key > extensions. Right? > Ahh, the Authorization lifetime is used for the tunnel update and the MIP-Key lifetime is used for the keys.... So, what about to following additional text to the draft to explain / clarify the usage of the MIP-Key-Lifetime AVP and Authorization Lifetime AVP, see below. All, comments / objections. Regards, /Tony "1.6 Diameter Session Termination A Foreign and Home Agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination- Request (STR) to the Diameter server that authorized the service. The Session-Termination-Request (STR) MUST be issued by the mobility agents if the Authorization Lifetime has expired and no subsequent MIP registration request have been received. ........ " New section: "5.1 Authorization Lifetime vs. MIP Key Lifetime The Diameter Mobile IP application makes use of two timers the Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The Authorization-Lifetime contains the number of seconds before the Mobile Node must issue a subsequent MIP registration request. The content of Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP]. The MIP-Key-Lifetime AVP contains the number of seconds before session keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). The value of the MIP-Key-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP. If the value is greater, it SHOULD be a multiple of the value in the Authorization Lifetime AVP." --------------1D4BBD5D840643A8EB7AABB0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
"Pat R. Calhoun" wrote:
 
> But, in the AAA Registration Keys for Mobile IP, which we are
> dependent on, you can only > tell the mobile one timer (the
> Lifetime). The Lifetime AAA Registration Keys for Mobile  IP
> indicates the duration of time (in seconds) for which the MN-FA and
> MN-HA keys are  valid. When the keys expires the MN must re-auth,
> so seen from the MN the authorization  lifetime and the key
> lifetime is very much the same thing. Right?

But there is a fundamental difference between the Lifetime field in
the MIP header, and the lifetime fields in the individual aaa-key
extensions. Right?
 

Ahh, the Authorization lifetime is used for the tunnel update and the MIP-Key lifetime is used for the keys....

So, what about to following additional text to the draft to explain / clarify the usage of the MIP-Key-Lifetime AVP and Authorization Lifetime AVP, see below.

All, comments / objections.

Regards,

/Tony

"1.6  Diameter Session Termination

   A Foreign and Home Agent following this specification MAY expect
   their respective Diameter servers to maintain session state
   information for each mobile node in their networks. In order for the
   Diameter Server to release any resources allocated to a specific
   mobile node, the mobility agents MUST send a Session-Termination-
   Request (STR) to the Diameter server that authorized the service. The
   Session-Termination-Request (STR) MUST be issued by the mobility
   agents if the Authorization Lifetime has expired and no subsequent
   MIP registration request have been received.

   ........ "

New section:

"5.1 Authorization Lifetime vs. MIP Key Lifetime

   The Diameter Mobile IP application makes use of two timers the
   Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP.

   The Authorization-Lifetime contains the number of seconds before the
   Mobile Node must issue a subsequent MIP registration request. The
   content of Authorization-Lifetime AVP corresponds to the Lifetime
   field in the MIP header [MOBILEIP].

   The MIP-Key-Lifetime AVP contains the number of seconds before
   session keys destined for the Home Agent and/or Foreign Agent expire.
   A value of zero indicates infinity (no timeout). The value of the
   MIP-Key-Lifetime AVP MUST be at least equal to the value in the
   Authorization Lifetime AVP. If the value is greater, it SHOULD be a
   multiple of the value in the Authorization Lifetime AVP." --------------1D4BBD5D840643A8EB7AABB0-- From owner-aaa-wg@merit.edu Mon Feb 25 22:28:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07904 for ; Mon, 25 Feb 2002 22:28:11 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7F53F91266; Mon, 25 Feb 2002 22:28:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5121891267; Mon, 25 Feb 2002 22:28:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2894791266 for ; Mon, 25 Feb 2002 22:28:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id EDCDD5DDA3; Mon, 25 Feb 2002 22:27:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id A085B5DD9A for ; Mon, 25 Feb 2002 22:27:59 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1Q3RxS18180; Mon, 25 Feb 2002 21:27:59 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1Q3Rxw12032; Mon, 25 Feb 2002 21:27:59 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA03794; Mon, 25 Feb 2002 21:27:58 -0600 (CST) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA12522; Mon, 25 Feb 2002 21:27:57 -0600 (CST) Message-ID: <3C7B0025.BF650BC0@ericsson.com> Date: Mon, 25 Feb 2002 19:25:33 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE 266: ready for closure? References: Content-Type: multipart/alternative; boundary="------------C0D81083E89083432F31AEDA" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------C0D81083E89083432F31AEDA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bob, Please find comments embedded.. /Tony Bob Kopacz wrote: > > > > > > > In the event that the mobile node requests a home agent in the > > foreign network, and the AAAF authorizes its use, the AAAF MUST set > > the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. > > > This could happen when the AAA request is sent to "extend" a mobile > > node's current session. (3) I don't quite understand how the mobile > node "requests" a home > agent in the foreign network. Maybe the word "request" is what > confuses me. That is, the MN can request that a HA be assigned by > sending an HA IP > address of all zeroes or all ones. 255.255.255.255 means the HA must > be allocated in the home network, while 0.0.0.0 means the HA can be > allocated in either the local foreign network or the home network. But > > neither case indicates a preference for a foreign HA over a home > network HA. Maybe "requests" means the MN specifies the real IP > address of a real > HA. In that case the MN is just specifying the HA's IP address, but > not indicating whether the HA is in the home realm or a foreign > realm. > > [Tony] Correct. This is in the case that the MN specifies the real IP > a real HA. > > (4) I don't understand how the originating AAAF intelligently sets > the > Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a > "real" HA IP address (not all zeroes > or all ones). The AAAF only sees an IP address. The AAAF doesn't > know just from the HA's IP address whether that represents an HA in > the home network, or an HA in another foreign network. And maybe > doesn't even know if the IP address is in his own network. So how > does the AAAF set the Home-Agent-In-Foreign-Network flag? > > [Tony] E.g. the AAAF could use a DNS look up to find out the HAs realm > and host name. > > It seems that the AAAF would send the MIP-Originating-Foreign-AAA > AVP > if there is the possibility that the originating AAAF might be part of > > a DSA. That can happen if either: (a) the AAAF is offering to provide > > the HA and is sending the MIP-Candidate-Home-Agent-Host AVP, or (b) > the MN has specifed a "real" HA IP address (not 0.0.0.0 or > 255.255.255.255). If the MIP-Originating-Foreign-AAA goes away, then > this is moot. The rule would be that the AAAH always manufactures and > > sends the new grouped MIP-Foreign-Agent in the HAR. > > [Tony] That will not work, since the FA may not support DSA. See Base > section 2.0. So, if we need an AVP that can carry iether the > originating AAAF or the FA depending on the support of DSA or not... > > > When the AAAH receives an AMR message, it first checks the > > authentication data supplied by the mobile node, according to the > > MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether > > to authorize the mobile node. If the AMR indicates that the AAAF > has > > offered to allocate a home agent for the mobile node, then the AAAH > > must decide whether its local policy would allow the user to have a > > Home Agent in the foreign network. If so, and after checking > > authorization from the data in the AMR message, the AAAH sends the > > HAR message to the AAAF that does not contain the MIP-Home-Agent- > ^^^^ > Technically, the HAR is sent the HA, since the HAR's Destination-Host > is the HA. > > [Tony] Okay I will clarify that. > > > Address, but includes the Destination-Host AVP set to the value of > > > the AMR's MIP-Candidate-Home-Agent-Host AVP. > > > > If the HA hasn't yet been allocated by the foreign domain, the HAR > > sent by the AAAH back to the foreign realm will not necessarily be > > received by the same AAAF which sent the AMR. Therefore the AAAH > MUST > > always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message > > > to the HAR message. In cases when another AAAF, which may not reside > > > in the same domain, receives the HAR, thus the new AAAF will use the > > > MIP-Originating-Foreign-AAA-AVP for policy decisions, such as > > determining if the FA-HA Key should be encrypted or not. > > > > .............. > > > ..............> > > 5.4 Distributing the Foreign-Home Session Key > > > > If the home agent is in the home realm, then the AAAH has to > generate > > the Foreign-Home session key. Otherwise, it is generated by AAAF. > > (5) Add a section header here, preceding the paragraph that > follows: 5.4.1 Home Agent in the home network > In the cases when the > AAAH generates the Foreign-Home session key, > > the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and > > includes the AVP as part of the HAR message sent to the home agent. > > The corresponding session key that is to be sent to the foreign > agent > > is cached in the AAAH until the HAA is received. (6) Replace the > last sentence by: "The corresponding session key and algorithm that is > to be sent to the > foreign agent is cached in the AAAH until the HAA is received." > > [Tony] Check. > > > > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > > session key, allocates an SPI to be used with the key. The allocated > > > SPI is included in the HAA's MIP-FA-to-HA SPI AVP. > > > > Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP, > > using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the > > AMA. (7) Add a section header here: 5.4.2 Home Agent in the foreign > domain > In the cases when the AAAF generates the Foreign-Home session > key > > (home agent in foreign domain), the AAAF will, upon receipt of the > > HAR message, generate the Foreign-Home session key and include the > > session key in the MIP-HA-to-FA-Key AVP as part of the HAR message > > forwarded to the home agent. The corresponding session key that is > to > > be sent to the foreign agent is cached in the AAAF until the HAA is > > received. (8) Replace the last sentence by: "The corresponding > session key and algorithm that is to be sent to the > foreign agent is cached in the AAAF until the HAA is received." > > [Tony] Check > > > > > > Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP, > > using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the > > Foreign-Home session key destined for the foreign agent needs to be > > encrypted. > > > > If the session key needs to be encrypted, the AAAF will check if a > > security association can be established using DSA messages defined > in > > the CMS application [CMS] with the originating host found in the > MIP- > > Originating-Foreign-AAA AVP. If the DSA establishment is successful, > > > the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted- > > Data AVP with the AAAF as originator and the recipient copied from > > the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is > > included by the AAAF in the HAA destined for the AAAH. Otherwise, if > > > the DSA establishment fails, the AAAF MUST return a Result-Code AVP > > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. (9) Since CMS is a new > protocol being rolled out, couldn't the > destination AAAF attempt to set up this DSA (because the AAAF > "prefers" to hide the FA-HA key), and if the DSA fails, then have the > fallback option to send the FA-HA key in the clear. Rather than what > the final sentence requires ("if the DSA establishment fails, the AAAF > > MUST return a Result-Code AVP with > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.") > If the session key does not > need to be encrypted, the AAAF will add > > MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the > > HAA to the AAAH . > > (10) Add the following sentence: "In either case, the AAAF removes > the MIP-FA-to-HA-SPI AVP from the > HAA returned to the AAAH." > > [Tony] Check. > > > Upon reception of the HAA, the AAAH MUST copy either the > MIP-FA-to-HA > > Key AVP if present or the CMS-Ecrypted-data AVP if present and not > > destined for the AAAH into the AMA. > > > > If a Foreign-Home session key was present in the AMA, the foreign > > agent MUST include the Mobile-Foreign authentication extension in > the > > Registration Reply, using the newly distributed key. > > > > ......... > > Bob K. --------------C0D81083E89083432F31AEDA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Bob,

Please find comments embedded..

/Tony

Bob Kopacz wrote:

 
 

>
> In the event that the mobile node requests a home agent in the
> foreign network, and the AAAF authorizes its use, the AAAF MUST set
> the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP.
> This could happen when the AAA request is sent to "extend" a mobile
> node's current session. (3) I don't quite understand how the mobile node "requests" a home
agent in the foreign network.  Maybe the word "request" is what
confuses me. That is, the MN can request that a HA be assigned by sending an HA IP
address of all zeroes or all ones. 255.255.255.255 means the HA must
be allocated in the home network, while 0.0.0.0 means the HA can be
allocated in either the local foreign network or the home network. But
neither case indicates a preference for a foreign HA over a home
network HA. Maybe "requests" means the MN specifies the real IP address of a real
HA.  In that case the MN is just specifying the HA's IP address, but
not indicating whether the HA is in the home realm or a foreign realm. 

[Tony] Correct. This is in the case that the MN specifies the real IP a real HA.
 
 (4) I don't understand how the originating AAAF intelligently sets the
Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a "real" HA IP address (not all zeroes
or all ones).  The AAAF only sees an IP address.  The AAAF doesn't
know just from the HA's IP address whether that represents an HA in
the home network, or an HA in another foreign network.  And maybe
doesn't even know if the IP address is in his own network.  So how
does the AAAF set the Home-Agent-In-Foreign-Network flag?

[Tony] E.g. the AAAF could use a DNS look up to find out the HAs realm and host name.
 
  It seems that the AAAF would send the MIP-Originating-Foreign-AAA AVP
if there is the possibility that the originating AAAF might be part of
a DSA.  That can happen if either: (a) the AAAF is offering to provide
the HA and is sending the MIP-Candidate-Home-Agent-Host AVP, or (b)
the MN has specifed a "real" HA IP address (not 0.0.0.0 or
255.255.255.255).  If the MIP-Originating-Foreign-AAA goes away, then
this is moot.  The rule would be that the AAAH always manufactures and
sends the new grouped MIP-Foreign-Agent in the HAR.

[Tony] That will not work, since the FA may not support DSA. See Base section 2.0. So, if we need an AVP that can carry iether the originating AAAF or the FA depending on the support of DSA or not...
 
  > When the AAAH receives an AMR message, it first checks the
> authentication data supplied by the mobile node, according to the
> MIP-Reg-Request AVP and MIP-MN-AAA-Auth AVP, and determines whether
> to authorize the mobile node.  If the AMR indicates that the AAAF has
> offered to allocate a home agent for the mobile node, then the AAAH
> must decide whether its local policy would allow the user to have a
> Home Agent in the foreign network. If so, and after checking
> authorization from the data in the AMR message, the AAAH sends the
> HAR message to the AAAF that does not contain the MIP-Home-Agent-
                     ^^^^
Technically, the HAR is sent the HA, since the HAR's Destination-Host
is the HA.

[Tony] Okay I will clarify that.
 
  > Address, but includes the Destination-Host AVP set to the value of
> the AMR's MIP-Candidate-Home-Agent-Host AVP.
>
> If the HA hasn't yet been allocated by the foreign domain, the HAR
> sent by the AAAH back to the foreign realm will not necessarily be
> received by the same AAAF which sent the AMR. Therefore the AAAH MUST
> always copy the MIP-Originating-Foreign-AAA-AVP from the AMR message
> to the HAR message. In cases when another AAAF, which may not reside
> in the same domain, receives the HAR, thus the new AAAF will use the
> MIP-Originating-Foreign-AAA-AVP for policy decisions, such as
> determining if the FA-HA Key should be encrypted or not.
>
>    ..............
> >     ..............>
> 5.4  Distributing the Foreign-Home Session Key
>
> If the home agent is in the home realm, then the AAAH has to generate
> the Foreign-Home session key. Otherwise, it is generated by AAAF.
> (5) Add a section header here, preceding the paragraph that follows: 5.4.1 Home Agent in the home network > In the cases when the AAAH generates the Foreign-Home session key,
> the AAAH includes the session key in the MIP-HA-to-FA-Key AVP, and
> includes the AVP as part of the HAR message sent to the home agent.
> The corresponding session key that is to be sent to the foreign agent
> is cached in the AAAH until the HAA is received. (6) Replace the last sentence by: "The corresponding session key and algorithm that is to be sent to the
foreign agent is cached in the AAAH until the HAA is received."

[Tony] Check.
 
  >
> Upon receipt of the HAR, the home agent recovers the Foreign-Home
> session key, allocates an SPI to be used with the key. The allocated
> SPI is included in the HAA's MIP-FA-to-HA SPI AVP.
>
> Upon receipt of the HAA, the AAAH adds the MIP-FA-to-HA Key AVP,
> using the SPI in the MIP-FA-to-HA-SPI, and includes the AVP in the
> AMA. (7) Add a section header here: 5.4.2 Home Agent in the foreign domain > In the cases when the AAAF generates the Foreign-Home session key
> (home agent in foreign domain), the AAAF will, upon receipt of the
> HAR message, generate the Foreign-Home session key and include the
> session key in the MIP-HA-to-FA-Key AVP as part of the HAR message
> forwarded to the home agent. The corresponding session key that is to
> be sent to the foreign agent is cached in the AAAF until the HAA is
> received. (8) Replace the last sentence by: "The corresponding session key and algorithm that is to be sent to the
foreign agent is cached in the AAAF until the HAA is received."

[Tony] Check
 

>
> Upon receipt of the HAA, the AAAF creates the MIP-FA-to-HA Key AVP,
> using the SPI in the MIP-FA-to-HA-SPI. The AAAF then checks if the
> Foreign-Home session key destined for the foreign agent needs to be
> encrypted.
>
> If the session key needs to be encrypted, the AAAF will check if a
> security association can be established using DSA messages defined in
> the CMS application [CMS] with the originating host found in the MIP-
> Originating-Foreign-AAA AVP. If the DSA establishment is successful,
> the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-
> Data AVP with the AAAF as originator and the recipient copied from
> the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is
> included by the AAAF in the HAA destined for the AAAH. Otherwise, if
> the DSA establishment fails, the AAAF MUST return a Result-Code AVP
> with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. (9) Since CMS is a new protocol being rolled out, couldn't the
destination AAAF attempt to set up this DSA (because the AAAF
"prefers" to hide the FA-HA key), and if the DSA fails, then have the
fallback option to send the FA-HA key in the clear.  Rather than what
the final sentence requires ("if the DSA establishment fails, the AAAF
MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.") > If the session key does not need to be encrypted, the AAAF will add
> MIP-FA-to-HA Key to the HAA, upon reception from HA and forward the
> HAA to the AAAH .
> (10) Add the following sentence: "In either case, the AAAF removes the MIP-FA-to-HA-SPI AVP from the
HAA returned to the AAAH."

[Tony] Check.
 
  > Upon reception of the HAA, the AAAH MUST copy either the MIP-FA-to-HA
> Key AVP if present or the CMS-Ecrypted-data AVP if present and not
> destined for the AAAH into the AMA.
>
> If a Foreign-Home session key was present in the AMA, the foreign
> agent MUST include the Mobile-Foreign authentication extension in the
> Registration Reply, using the newly distributed key.
>
> .........
> Bob K.

--------------C0D81083E89083432F31AEDA-- From owner-aaa-wg@merit.edu Tue Feb 26 01:37:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11437 for ; Tue, 26 Feb 2002 01:37:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D576D91267; Tue, 26 Feb 2002 01:37:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D1C991268; Tue, 26 Feb 2002 01:37:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13A9891267 for ; Tue, 26 Feb 2002 01:37:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC4F65DDA1; Tue, 26 Feb 2002 01:37:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 7BBBE5DD94 for ; Tue, 26 Feb 2002 01:37:10 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1Q6b9h20984; Tue, 26 Feb 2002 00:37:10 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1Q6b9w13183; Tue, 26 Feb 2002 00:37:09 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id AAA20307; Tue, 26 Feb 2002 00:37:08 -0600 (CST) Received: from ericsson.com (racomin-102.exu.ericsson.se [138.85.130.102]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id AAA14962; Tue, 26 Feb 2002 00:37:07 -0600 (CST) Message-ID: <3C7B2C7F.F72162DE@ericsson.com> Date: Mon, 25 Feb 2002 22:34:39 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE 266: ready for closure? References: Content-Type: multipart/alternative; boundary="------------753BE2EC9A1FC1C4913849DC" Sender: owner-aaa-wg@merit.edu Precedence: bulk --------------753BE2EC9A1FC1C4913849DC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > > > > > If the session key needs to be encrypted, the AAAF will check if a > > security association can be established using DSA messages defined > in > > the CMS application [CMS] with the originating host found in the > MIP- > > Originating-Foreign-AAA AVP. If the DSA establishment is successful, > > > the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted- > > Data AVP with the AAAF as originator and the recipient copied from > > the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is > > included by the AAAF in the HAA destined for the AAAH. Otherwise, if > > > the DSA establishment fails, the AAAF MUST return a Result-Code AVP > > with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. > > (9) Since CMS is a new protocol being rolled out, couldn't the > destination AAAF attempt to set up this DSA (because the AAAF > "prefers" to hide the FA-HA key), and if the DSA fails, then have the > fallback option to send the FA-HA key in the clear. Rather than what > the final sentence requires ("if the DSA establishment fails, the AAAF > > MUST return a Result-Code AVP with > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.") That sounds very dangerous to me. I would rather return the Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE, which would instead force the nodes to be reconfigured to send the FA-HA key in clear text. /Tony --------------753BE2EC9A1FC1C4913849DC Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Bob Kopacz wrote:

 
>
> If the session key needs to be encrypted, the AAAF will check if a
> security association can be established using DSA messages defined in
> the CMS application [CMS] with the originating host found in the MIP-
> Originating-Foreign-AAA AVP. If the DSA establishment is successful,
> the AAAF will encrypt the MIP-FA-to-HA Key AVP in a CMS-Encrypted-
> Data AVP with the AAAF as originator and the recipient copied from
> the MIP-Originating-Foreign-AAA AVP. This CMS-Encrypted-Data AVP is
> included by the AAAF in the HAA destined for the AAAH. Otherwise, if
> the DSA establishment fails, the AAAF MUST return a Result-Code AVP
> with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. 

(9) Since CMS is a new protocol being rolled out, couldn't the
destination AAAF attempt to set up this DSA (because the AAAF
"prefers" to hide the FA-HA key), and if the DSA fails, then have the
fallback option to send the FA-HA key in the clear.  Rather than what
the final sentence requires ("if the DSA establishment fails, the AAAF
MUST return a Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE.")
That sounds very dangerous to me. I would rather return the Result-Code AVP with DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE, which would instead force the nodes to be reconfigured to send the FA-HA key in clear text.

/Tony --------------753BE2EC9A1FC1C4913849DC-- From owner-aaa-wg@merit.edu Tue Feb 26 02:59:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20213 for ; Tue, 26 Feb 2002 02:59:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE51A91269; Tue, 26 Feb 2002 02:59:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E1EE9126A; Tue, 26 Feb 2002 02:59:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FB7E91269 for ; Tue, 26 Feb 2002 02:59:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 397AD5DDC6; Tue, 26 Feb 2002 02:59:05 -0500 (EST) 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 4AAC35DDAB for ; Tue, 26 Feb 2002 02:59:04 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1Q7wW316303 for ; Tue, 26 Feb 2002 09:58:32 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 09:59:03 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 09:59:03 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Accouting AVP issue... X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Feb 2002 09:59:02 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A2E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Accouting AVP issue... Thread-Index: AcG+UCiZjdLZtngfTserdzWlggUvnQASy1lw From: To: Cc: , , X-OriginalArrivalTime: 26 Feb 2002 07:59:03.0243 (UTC) FILETIME=[74D551B0:01C1BE9B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA20213 Hi David, > So, after all this rambling, I suggest the following: > > 1) Both MIP and NASREQ should define the AVPs. > > 2) Both drafts should contain the verbatim text that is now in MIP > (not the erroneous text that is now in NASREQ). > > 3) The NASREQ draft should contain additional NASREQ usage instructions > copied verbatim from RADIUS except for the part about only being present > in stop records, which is no longer true.] > > 4) The MIP editor may want to consider adding usage instructions as well. > > 5) The word Extended should be removed from from the attribute names. The > difference between the Acct- prefix and the Accounting- prefix can > distinguish the RADIUS attributes from the Diameter attributes. Also > the AVP codes are different -- 363-366 for the Diameter AVPs. > > 6) The Accounting-Session-Time AVP should be renamed to Acct-Session-Time > for compatibility with RADIUS because it shares the RADIUS AVP Code of > 46. This works for me (since it seems to imply no changes to the base, which I like ;) John From owner-aaa-wg@merit.edu Tue Feb 26 03:34:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20610 for ; Tue, 26 Feb 2002 03:34:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2FA7A9126A; Tue, 26 Feb 2002 03:34:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED81C9126B; Tue, 26 Feb 2002 03:34:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D326A9126A for ; Tue, 26 Feb 2002 03:34:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 791285DDC8; Tue, 26 Feb 2002 03:34:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id D20225DDC6 for ; Tue, 26 Feb 2002 03:34:01 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1Q8XrZc019997; Tue, 26 Feb 2002 09:33:53 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1Q8XqmK017760; Tue, 26 Feb 2002 10:33:52 +0200 (EET) Message-ID: <3C7B4870.D2DBBF3F@lmf.ericsson.se> Date: Tue, 26 Feb 2002 10:33:52 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson Cc: AAA Listan Subject: Re: [AAA-WG]: Issue: Collection of Accounting data References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson wrote: > Why must a accounting message be sent to the Home AAA Server? In the case of > Mobile IP, it's quite likely that the operator owning the FA would like to > receive the Fa generated accounting records in order to be able to send an > invoice to the owner of the mobile node. There's actually two issues. One, what is the first hop of the message. Two, what is the final server that receives the message. The current text is somewhat vague or incorrect on these two aspects. But let me argue a few points first: * The Fa *can't* send an invoice to the owner of the mobile node. There is no contract. Typically, both home and the foreign operator get a copy of an accounting record, and the home bills the user. The home and foreign settle their bills monthly. (Even if this wasn't the case always, I believe the home would like to get a copy of the accounting record in any case.) * We have talked about separate AAA servers for authentication and accounting, even accounting-only application of Diameter. These should be accommodated somehow. In conclusion I think the text you pointed out is (a) correct in the sense that the accounting data has to get to the home (b) misleading in the sense that it doesn't talk about the servers on the path receiving/logging the records too, and (c) incorrect in the sense that exactly the same Home AAA Server is needed as for all As. My proposal is to modify the text as follows: 9.2 Protocol Messages A Diameter node that receives a successful authentication and/or authorization messages from a Home AAA Server, MUST collect accounting information for the session. Diameter nodes MAY also collect accounting information for services that do not involve authentication and/or authorization. The Accounting-Request message is used to transmit the accounting information. The message's final destination is a Home AAA Server (not necessarily the same one as above). On the path towards this server, local and broker Diameter Agents MAY record the same accounting information, e.g. for the purposes of inter-operator settlements. The Home AAA server MUST reply with the Accounting-Answer message to confirm reception of the Accounting-Request message. From owner-aaa-wg@merit.edu Tue Feb 26 05:33:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22558 for ; Tue, 26 Feb 2002 05:33:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AE4B99126B; Tue, 26 Feb 2002 05:33:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 822899126C; Tue, 26 Feb 2002 05:33:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 884B99126B for ; Tue, 26 Feb 2002 05:33:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 671F55DD96; Tue, 26 Feb 2002 05:33:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id B8D685DD94 for ; Tue, 26 Feb 2002 05:33:18 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1Q7ueZc025851; Tue, 26 Feb 2002 08:56:40 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1Q7udmK015187; Tue, 26 Feb 2002 09:56:39 +0200 (EET) Message-ID: <3C7B3FB7.206E95A8@lmf.ericsson.se> Date: Tue, 26 Feb 2002 09:56:39 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: john.loughney@nokia.com, pcalhoun@bstormnetworks.com, tony.johansson@ericsson.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Accouting AVP issue... References: <0C1353ABB1DEB74DB067ADFF749C4EEFC649EF@esebe004.NOE.Nokia.com> <3C7AC1F4.D8749A7C@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Spence wrote: > So, after all this rambling, I suggest the following: > ... > (proposal) Ok. Jari From owner-aaa-wg@merit.edu Tue Feb 26 05:39:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22694 for ; Tue, 26 Feb 2002 05:39:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EA959126C; Tue, 26 Feb 2002 05:39:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C45CC9126E; Tue, 26 Feb 2002 05:39:12 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D29ED9126C for ; Tue, 26 Feb 2002 05:39:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id B028A5DD96; Tue, 26 Feb 2002 05:39:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 10D815DD94 for ; Tue, 26 Feb 2002 05:39:11 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1QAd9Zc017466; Tue, 26 Feb 2002 11:39:09 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1QAd9mK026900; Tue, 26 Feb 2002 12:39:09 +0200 (EET) Message-ID: <3C7B65CD.CB5E7B3E@lmf.ericsson.se> Date: Tue, 26 Feb 2002 12:39:09 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: IETF AAA List , john.loughney@nokia.com Subject: RE: [AAA-WG]: Request for closure on issue 235 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Several folks have checked this and believe that this would work. > So, unless there are any remaining objections, I am going to accept > this change & modify the base accordingly. I'm one of those folks. According to my analysis, it does appear to work. Inclusion in Diameter might not be clear yet, however and I would appreciate other people's view on this. Bernard? 1. CORRECTNESS But let's start with the part about this working. Basically, the scheme introduces a new bit for accounting records, to signify when the sender of a record thinks he may have sent duplicates. The receiver uses this information to do a faster duplicate lookup. Given that the records may arrive in any order, this lookup isn't as trivial as one might expect, however. Let's study the possible orderings between the Non-D record (the original) and the D record (the duplicate), including loss of packets: a. 1) Non-D, 2) D: Here the arrival of the D record triggers search against all records. Duplicate is found. b. 1) D, 2) Non-D: First the D record arrives, an all record search is performed. The D record goes to a special pool, and the Non-D record, when it arrives, is checked against this pool and duplicate is found. c. 1) D: A search against all records is performed, but no result hence the record is accepted. d. 1) Non-D: A search against the pool is performed, but no result hence the record is accepted. In conclusion, the method requires the following: 1. Checking all D-marked records against *all* other records. 2. Checking all regular records against those stored in the D-pool. 3. The D-pool contents must have some expiration time after which the records are moved out of the pool. 3. ALTERNATIVE SCHEMES The alternative ways to perform duplicate record matching include the following: - Matching all records against each other (current base mechanism) - Matching all records against recent other records (in the same time window as the D pool would expire). This is an implementation enhancement of the current base mechanism. However, as with the pool scheme, the period may be unexpectedly long given that network partitions can occur and permanent storage can be employed by NASes during this period. - Correlating all records by User-Name first before trying to find duplicates. This would reduce the search space substantially more than the previous suggestion. - Relaxing on accounting-level duplication detection requirements and performing this latest at the billing state. (Diameter end-to-end identifier duplication checking would still be necessary.) 4. NEED FOR D BIT Basically, the D bit reduces the need to check records against all other records. These all-record searches need to be done only when D bit records arrive, but not for all arriving records. However, it still is necessary to perform all-record searches in cases a-c described in section 2. Given this, it also appears that the D bit method should use the same optimisations as the regular scheme, e.g. doing the checks only against recent records or just the user's records, not the history of all possible records. More interestingly, it does not appear to be possible to do the all record searches without employing either (1) data base indexing methods or perhaps (2) User-Name correlation. In conclusion the D bit method allows us to avoid most all-record searches. However, some are still needed and as a consequence the Diameter accounting nodes must employ some sort of database indexing techniques to perform such searches in reasonable time anyway. Also, N x N searches were never possible anyway on the current spec and similar data base searches would have been necessary there as well. So, the true advantage of the D bit method can be described as follows. Let's assume a 1% duplicate rate and a minute where 2000 records arrive (20 duplicates). Using the current scheme, 2000 data base indexing operations would have to be performed. With the D bit scheme, 20 data base indexing operations would be needed to the full data base, and 2000 operations to search things from the smaller pool. In practise this would probably be a database operation as well, though perhaps it could be kept completely in CPU memory so it would be faster. Assuming similar speed, there'd be no performance benefit to the D bit method, a 1% CPU time increase instead. Assuming 1/10 speed, the D bit saves 89% of CPU time. YMMV. From owner-aaa-wg@merit.edu Tue Feb 26 06:25:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23197 for ; Tue, 26 Feb 2002 06:25:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CC5279126F; Tue, 26 Feb 2002 06:25:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9E1F891270; Tue, 26 Feb 2002 06:25:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE69C9126F for ; Tue, 26 Feb 2002 06:25:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EEA55DDB7; Tue, 26 Feb 2002 06:25:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 7DA3D5DD94 for ; Tue, 26 Feb 2002 06:25:38 -0500 (EST) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Feb 2002 20:26:33 +0900 Message-ID: <8470181DABD5D511B3E700D0B7A8AC4A69E2BE@cms3.etri.re.kr> From: anny5@etri.re.kr To: jari.arkko@kolumbus.fi, anny5@etri.re.kr, aaa-wg@merit.edu Subject: [AAA-WG]: =?euc-kr?B?W8D8w7zIuL3FXSBSZTogW0FBQS1XR106IENNUyBRdWVzdGlvbg==?= Date: Tue, 26 Feb 2002 20:26:33 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BEB8.7179C470" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BEB8.7179C470 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable I think DSA/DSAA message contain several AAA-Node-Cert AVP . = AAA-Node-Cert AVP contains certificates of AAA hosts in same realm.=20 if the size of one certificate is 700k and there is 5 hosts in same = realm, does DSAR/DSAA( contain=20 3500k certificate - 5 AAA-Node-Cert AVPs ) message have to transport? also, if one realm and antoher realm(one host and one host) has a DSA, don't other hosts at these=20 realm need to establish DSA? Without DSA establish step, the = communocation is possible? is there anyone answer me? thanks advance. i am wait your answer. regards =BF=F8=BA=BB =B3=BB=BF=EB: =BA=B8=B3=BD=BB=E7=B6=F7: Jari Arkko[jari.arkko@kolumbus.fi] =B9=DE=B4=C2=BB=E7=B6=F7: anny5@etri.re.kr; aaa-wg@merit.edu =C1=A6=B8=F1: Re: [AAA-WG]: CMS Question =B9=DE=C0=BA=B3=AF=C2=A5: 2002/02/09 =C5=E4 04:05 [AAA-WG]: CMS Question>in section 4.1 Diameter-Security-Association- Request,=20 >DSAR message can have zero or more AAA-Node-Cert AVP=20 >but, in section 8.0, AAA-Node-Cert 0-1.=20 >it is a contradiction. i wonder how many AAA-Node-Cert AVPs are in = DSAR message .=20 This seems to be an error in 8.0. Should be 0+ for both DSAR and DSAA.=20 Also, I have the concern that section 3.1 lists only a subset of all = AVPs=20 that are allowed in 4.1 for DSAR and DSAA. This list should be = completed.=20 Preferably, the list items should also point to the AVP names for = easier=20 reference. There are many cert AVPs, for instance, it is not very easy=20 to distinguish them from each other. >there is another question. if a host send DSAR message, does it=20 >include other host's certificates in same realm?(within many = AAA-Node-Cert AVPs ) I suppose so. Needs clarification in the I-D. Jari ------_=_NextPart_001_01C1BEB8.7179C470 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable [=C0=FC=C3=BC=C8=B8=BD=C5] Re: [AAA-WG]: CMS Question

I think DSA/DSAA message contain several = AAA-Node-Cert AVP . AAA-Node-Cert AVP  contains certificates = of

AAA hosts in same realm.

if the size of one certificate is 700k and there is 5 = hosts in same realm, does DSAR/DSAA( contain

3500k certificate - 5 AAA-Node-Cert AVPs ) message = have to transport?

also, if one realm and antoher realm(one host and one = host) has a DSA,  don't other hosts at these

realm need to establish DSA? Without DSA establish = step, the communocation is possible?

is there anyone answer me?

thanks advance.

i am  wait your answer.

regards





=BF=F8=BA=BB =B3=BB=BF=EB:

=BA=B8=B3=BD=BB=E7=B6=F7: Jari = Arkko[jari.arkko@kolumbus.fi]
=B9=DE=B4=C2=BB=E7=B6=F7: anny5@etri.re.kr; = aaa-wg@merit.edu
=C1=A6=B8=F1: Re: [AAA-WG]: CMS Question
=B9=DE=C0=BA=B3=AF=C2=A5: 2002/02/09 =C5=E4 = 04:05


[AAA-WG]: CMS Question>in section 4.1  = Diameter-Security-Association-Request,
>DSAR message can have zero or more  = AAA-Node-Cert AVP
>but, in section 8.0, AAA-Node-Cert 0-1.
>it is a contradiction. i wonder how many = AAA-Node-Cert AVPs are in DSAR message .
This seems to be an error in 8.0. Should be 0+ for = both DSAR and DSAA.
Also, I have the concern that section 3.1 lists only = a subset of all AVPs
that are allowed in 4.1 for DSAR and DSAA. This list = should be completed.
Preferably, the list items should also point to the = AVP names for easier
reference. There are many cert AVPs, for instance, = it is not very easy
to distinguish them from each other.
>there is another question. if a host send DSAR = message, does  it
>include other host's certificates in same = realm?(within many AAA-Node-Cert AVPs )
I suppose so. Needs clarification in the I-D.
Jari

------_=_NextPart_001_01C1BEB8.7179C470-- From owner-aaa-wg@merit.edu Tue Feb 26 06:35:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23368 for ; Tue, 26 Feb 2002 06:35:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9AE6D91270; Tue, 26 Feb 2002 06:35:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AC2291271; Tue, 26 Feb 2002 06:35:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5873891270 for ; Tue, 26 Feb 2002 06:35:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3183D5DDC8; Tue, 26 Feb 2002 06:35:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id 9761F5DDC6 for ; Tue, 26 Feb 2002 06:35:28 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020226113527.ECZP25354.fep02-svc.swip.net@ipunplugged.com> for ; Tue, 26 Feb 2002 12:35:27 +0100 Message-ID: <3C7B7328.3060906@ipunplugged.com> Date: Tue, 26 Feb 2002 12:36:08 +0100 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020202 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: [Issue] Routing of session messages defined in base 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 STR and ASR messages do not belong to any specific application but rather to all of them. This means that they will take *any* route to a realm even if it is a dead end. They should contain Auth-Application-Id avps. Submitter name: Johan Johansson Submitter email address: johanj@ipunplugged.com Date first submitted: 2002-02-26 Reference: Document: base Comment type: T Priority: 1 Section: 10.1, 6.8 Rationale/Explanation of issue: Let the realm R be a realm with (separate) home servers N and M for NASREQ and MIP and assume that from a given realm the normal route passes through a node S that has one NASREQ route to R that will make messages enter R via N and one MIP route that will make messages enter R via M, e.g. S----------------X------------X------------N | +------------X------------M Since M and N have no common application they will not be peers. Assume that there is an active MIP session at M that the access device determines to terminate by sending an STR. There is nothing that prevents S from routing the STR down the N path. Requested changes: 6.8: I haven't thought of a good change to this section yet. But it should state that messages regarding a session for a particular application should contain the id of that application. 10.1: Change +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | to +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 | I guess the RAR messages should probably also have the Auth-Application-Id for similar purposes but I'll leave that for those who actually use it to comment on. j From owner-aaa-wg@merit.edu Tue Feb 26 07:03:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24216 for ; Tue, 26 Feb 2002 07:03:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3321991271; Tue, 26 Feb 2002 07:03:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2F7E91272; Tue, 26 Feb 2002 07:03:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA2CD91271 for ; Tue, 26 Feb 2002 07:03:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F6E95DDA1; Tue, 26 Feb 2002 07:03:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 654395DD94 for ; Tue, 26 Feb 2002 07:02:57 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QC36Z18502 for ; Tue, 26 Feb 2002 14:03:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 14:02:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 14:02:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue: Collection of Accounting data Date: Tue, 26 Feb 2002 14:02:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A3A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Collection of Accounting data Thread-Index: AcG+oGmyS/4w53hmSiuw58HReGKzRgAHQgpg From: To: , Cc: X-OriginalArrivalTime: 26 Feb 2002 12:02:56.0348 (UTC) FILETIME=[86D7F1C0:01C1BEBD] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA24216 Hi Jari, I agree with the text you have proposed. As long as everyone else agrees, I will add the text. John > 9.2 Protocol Messages > > A Diameter node that receives a successful authentication and/or > authorization messages from a Home AAA Server, MUST collect > accounting information for the session. Diameter nodes MAY also > collect accounting information for services that do not involve > authentication and/or authorization. > > The Accounting-Request message is used to transmit the accounting > information. The message's final destination is a Home AAA Server > (not necessarily the same one as above). On the path towards this > server, local and broker Diameter Agents MAY record the same > accounting information, e.g. for the purposes of inter-operator > settlements. The Home AAA server MUST reply with the > Accounting-Answer message to confirm reception of the > Accounting-Request message. > From owner-aaa-wg@merit.edu Tue Feb 26 07:29:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25383 for ; Tue, 26 Feb 2002 07:29:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 43EC091272; Tue, 26 Feb 2002 07:29:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 15C0991273; Tue, 26 Feb 2002 07:29:08 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E35A891272 for ; Tue, 26 Feb 2002 07:29:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id BE1305DDBF; Tue, 26 Feb 2002 07:29:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id D46245DDA1 for ; Tue, 26 Feb 2002 07:29:05 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QCTEZ09192 for ; Tue, 26 Feb 2002 14:29:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 14:29:04 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 14:29:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] 'M' Bit at fault rules still not right Date: Tue, 26 Feb 2002 14:29:04 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A3B@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] 'M' Bit at fault rules still not right Thread-Index: AcG+I7UbkA7Ch7gXQPulHuosrthD0QAnWVDQ From: To: , X-OriginalArrivalTime: 26 Feb 2002 12:29:04.0459 (UTC) FILETIME=[2D82B1B0:01C1BEC1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA25383 Hi David, Thanks for tackling this issue, its a bit tricky. I agree with your suggested changes - any objections adding this text to the base? John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 25 February, 2002 19:40 > To: AAA Working Group > Subject: [AAA-WG]: [issue] 'M' Bit at fault rules still not right > > > Subject: [issue] 'M' Bit at fault rules still not right > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: February 25, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 4.1 > Rationale/Explanation of issue: > > The AVP Flag rules tables in the various Diameter drafts > specify in > which AVPs the 'M' bit MUST be set, in which AVPs it MUST > NOT be set, > etc. > > However section 4.1 of the base draft states: > > A Diameter node that sets the 'M' bit in an AVP that is not > defined in a given message's ABNF is at fault if the message is > rejected. > > In the next paragraph it states: > > A Diameter node that rejects a message due to an > unrecognized AVP > with the 'M' bit set, and the AVP in question is defined in the > message's ABNF, is at fault. > > These sentences make the criterion for setting the 'M' bit > be whether > or not the AVP is listed in the formal syntax for the message in > which it appears. This is in direct contradiction to the > criterion > that the 'M' bit should be set according to the > specification in the > AVP Flag rules table of the draft defining the AVP. > > Life gets complicated, however, when an AVP defined in one > Diameter > Application or a vendor-specific AVP gets included in a message > defined in another Diameter Application. This is allowed for most > Diameter messages because the "* [ AVP ]" construct > appears in most > message specifications. > > So what happens if the sender of the message considers > such an AVP to > be critical to its intent, but the recipient of the > message does not > understand the AVP? The answer is that an > interoperability failure > happens. Some have argued (I have at times) that Diameter's > open-ended extensibility is actually one of its weaknesses. > > At the AAA WG interim meeting in Santa Clara in May 2001, the > extensibility-is-good faction reached a compromise with the > interoperability-failures-are-bad faction that resulted in the at > fault rules that appear in section 4.1 of the base draft. > The issue > here is that it is important to get the rules right. > > Considering that a Diameter node may include non-standard > AVPs, and > considering that it may be critical to the security or business > requirements of the parties involved to know whether or > not such AVPs > are accepted and processed, and considering that interoperability > failures are not in the best interests of any of the parties > involved, I propose the following principles to govern > setting of the > 'M' bit: > > 1) AVP specifiers should be encouraged to require > setting the 'M' > bit of any AVP for which the interest of any of the parties > would be hurt were the AVP to be ignored. > > 2) Implementors should be required to provide alternatives to > sending non-standard AVPs with the 'M' bit set. These may > include: > > a) If a message is rejected because it contains a > non-standard > AVP with the 'M' bit set, the implementation may > resend the > message without the AVP, possibly inserting additional > standard AVPs instead. > > b) A configuration option may be provided on a > system wide, per > peer, or per realm basis that would allow/prevent > particular > non-standard, Mandatory AVPs to be sent. Thus an > administrator could change the configuration to avoid > interoperability problems. > > 3) An implementation that does not comply with the above > requirements is not compliant with the Diameter standard. > > Examples > -------- > > Example 1: If I were to define a vendor-specific > Interlink-Wowee-Zowee-Filter-Rule AVP, I would specify > that the 'M' > bit MUST be set (I certainly don't want the filters to be > ignored). > An implementation sending this AVP would be compliant if, upon > receiving a rejection for a message containing the AVP, it re-sent > the message with the NAS-Filter-Rule AVP in place of the > Interlink-Wowee-Zowee-Filter-Rule AVP. Alternatively, an > implementation could achieve compliance by offering a per-realm > configuration option to control what realms to send the > Interlink-Wowee-Zowee-Filter-Rule AVP to. > > Example 2: NASCO NASes always include the NAS-Filter-Rule AVP in > Accounting-Request messages on the theory that inclusion > of this AVP > in accounting records may be critical to some providers' auditing > requirements. NASCO is permitted to do this because the construct > "* [ AVP ]" appears in the formal syntax of the Accounting-Request > message. The 'M' bit is set because the table in section > 2.1 of the > NASREQ standard requires it. ACME Accounting Servers do not > understand the NAS-Filter-Rule AVP. If they receive an Accounting > Request message for a NASREQ session that includes the > NAS-Filter-Rule AVP with the 'M' bit set, they reject the > message. > Thus no accounting can ever happen between a NASCO NAS and an ACME > Accounting Server. Who is at fault? ACME argues that > according to > Diameter-08, NASCO is at fault because neither of the tables in > section 10.2 of NASREQ list the NAS-Filter-Rule AVP. > > Requested change: > > Replace the at fault rules in section 4.1 with the > following text. > (Note: the editor may decide to move this discussion to > another, more > appropriate section of the draft.) > > The 'M' bit MUST be set according to the rules defined > for the AVP > containing it. In order to preserve interoperability, > a Diameter > implementation MUST be able to exclude from a Diameter > message any > Mandatory AVP which is neither defined in the base Diameter > standard nor in any of the Diameter Application specifications > governing the message in which it appears. It MAY do > this in one > of the following ways: > > 1) If a message is rejected because it contains a Mandatory AVP > which is neither defined in the base Diameter > standard nor in > any of the Diameter Application specifications governing the > message in which it appears, the implementation may > resend the > message without the AVP, possibly inserting > additional standard > AVPs instead. > > 2) A configuration option may be provided on a system wide, per > peer, or per realm basis that would allow/prevent particular > Mandatory AVPs to be sent. Thus an administrator > could change > the configuration to avoid interoperability problems. > > Diameter implementations are required to support all Mandatory > AVPs which are allowed by the message's formal syntax > and defined > either in the base Diameter standard or in one of the Diameter > Application specifications governing the message. > From owner-aaa-wg@merit.edu Tue Feb 26 08:13:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27490 for ; Tue, 26 Feb 2002 08:13:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E015F91216; Tue, 26 Feb 2002 08:13:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7EE591273; Tue, 26 Feb 2002 08:13:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADDB191216 for ; Tue, 26 Feb 2002 08:13:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86E7B5DDBF; Tue, 26 Feb 2002 08:13:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id D9CDC5DDA1 for ; Tue, 26 Feb 2002 08:13:09 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g1QDD5Zc024052; Tue, 26 Feb 2002 14:13:06 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1QDD5mK009607; Tue, 26 Feb 2002 15:13:05 +0200 (EET) Message-ID: <3C7B89E1.1C8D17AC@lmf.ericsson.se> Date: Tue, 26 Feb 2002 15:13:05 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: anny5@etri.re.kr Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: CMS Question References: <8470181DABD5D511B3E700D0B7A8AC4A69E2BE@cms3.etri.re.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit anny5@etri.re.kr wrote: > also, if one realm and antoher realm(one host and one host) has a DSA, don't other hosts at these > > realm need to establish DSA? Without DSA establish step, the communocation is possible? Hmm... this seems to be correct, you can't communicate with the other hosts if you don't have a DSA. Perhaps this implies that the AAA-Node-Cert should really appear at most once, like section 8 states but in contradiction with section 4.1. Jari From owner-aaa-wg@merit.edu Tue Feb 26 08:20:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27757 for ; Tue, 26 Feb 2002 08:20:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3F5EF91273; Tue, 26 Feb 2002 08:20:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1546891274; Tue, 26 Feb 2002 08:20:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6ED491273 for ; Tue, 26 Feb 2002 08:20:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id C97265DDC8; Tue, 26 Feb 2002 08:20:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 797375DDA1 for ; Tue, 26 Feb 2002 08:20:02 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id GAA02003 for ; Tue, 26 Feb 2002 06:20:01 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id GAA12526 for ; Tue, 26 Feb 2002 06:20:01 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Tue, 26 Feb 2002 07:20:01 -0600 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Tony Johansson'" , "Pat R. Calhoun" Cc: Bob Kopacz , aaa-wg Subject: RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP Date: Tue, 26 Feb 2002 07:20:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Tony, "The value of the MIP-Key-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP. If the value is greater, it SHOULD be a multiple of the value in the Authorization Lifetime AVP." Recommending the MIP-Key-Lifetime to be a multiple of the MIP (Authorization) lifetime doesn't mean much when you don't want to go through AAA upon every handoff - the two timers will soon get out of sync. -Panos -----Original Message----- From: Tony Johansson [mailto:tony.johansson@ericsson.com] Sent: Monday, February 25, 2002 7:21 PM To: Pat R. Calhoun Cc: Bob Kopacz; aaa-wg Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP "Pat R. Calhoun" wrote: > But, in the AAA Registration Keys for Mobile IP, which we are > dependent on, you can only > tell the mobile one timer (the > Lifetime). The Lifetime AAA Registration Keys for Mobile IP > indicates the duration of time (in seconds) for which the MN-FA and > MN-HA keys are valid. When the keys expires the MN must re-auth, > so seen from the MN the authorization lifetime and the key > lifetime is very much the same thing. Right? But there is a fundamental difference between the Lifetime field in the MIP header, and the lifetime fields in the individual aaa-key extensions. Right? Ahh, the Authorization lifetime is used for the tunnel update and the MIP-Key lifetime is used for the keys.... So, what about to following additional text to the draft to explain / clarify the usage of the MIP-Key-Lifetime AVP and Authorization Lifetime AVP, see below. All, comments / objections. Regards, /Tony "1.6 Diameter Session Termination A Foreign and Home Agent following this specification MAY expect their respective Diameter servers to maintain session state information for each mobile node in their networks. In order for the Diameter Server to release any resources allocated to a specific mobile node, the mobility agents MUST send a Session-Termination- Request (STR) to the Diameter server that authorized the service. The Session-Termination-Request (STR) MUST be issued by the mobility agents if the Authorization Lifetime has expired and no subsequent MIP registration request have been received. ........ " New section: "5.1 Authorization Lifetime vs. MIP Key Lifetime The Diameter Mobile IP application makes use of two timers the Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. The Authorization-Lifetime contains the number of seconds before the Mobile Node must issue a subsequent MIP registration request. The content of Authorization-Lifetime AVP corresponds to the Lifetime field in the MIP header [MOBILEIP]. The MIP-Key-Lifetime AVP contains the number of seconds before session keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). The value of the MIP-Key-Lifetime AVP MUST be at least equal to the value in the Authorization Lifetime AVP. If the value is greater, it SHOULD be a multiple of the value in the Authorization Lifetime AVP." From owner-aaa-wg@merit.edu Tue Feb 26 10:10:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02593 for ; Tue, 26 Feb 2002 10:10:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4154991277; Tue, 26 Feb 2002 10:10:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1528891279; Tue, 26 Feb 2002 10:10:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F98991277 for ; Tue, 26 Feb 2002 10:10:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 109DB5DDC1; Tue, 26 Feb 2002 10:10:08 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F0A765DD96 for ; Tue, 26 Feb 2002 10:10:07 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id C3C957E for ; Tue, 26 Feb 2002 10:10:07 -0500 (EST) Message-ID: <3C7BA556.A3D087E3@Interlinknetworks.com> Date: Tue, 26 Feb 2002 10:10:14 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A1F@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Wow! This is a big change and I don't understand where this might lead well enough to know how it impacts my issue. So as you deal with your changes regarding how server discovery works, keep in mind the AVPs of type DiameterIndentity which are used for message routing and make sure their requirements are met, to wit: 1) A value of type DiameterIdentity must uniquely identify a "Diameter node", which is an instance of a Diameter process running on an IP host. 2) There may be more than one "Diameter node" running on the same host and sharing the same IP address. 3) It must be possible to express a value of type DiameterIdentity in a canonical form so that each "Diameter node" will only have a single identifier in a domain. Thus the type must not contain any parameters that are specific to a particular peer-to-peer connection. john.loughney@nokia.com wrote: > > Hi all, > > I noticed that my example wasn't exactly correct, here is an update version: > > === updated example ==== > > As an example, consider a client that wishes to resolve > aaa:example.com. The client performs a NAPTR query for that > domain, and the following NAPTR records are returned: > > ;; order pref flags service regexp replacement > IN NAPTR 50 50 "s" "AAA+D2S" "" _aaa._sctp.example.com. > IN NAPTR 90 50 "s" "AAAS+D2T" "" _aaas._tcp.example.com. > IN NAPTR 100 50 "s" "AAA+D2T" "" _aaa._tcp.example.com > > This indicates that the server supports SCTP, TLS over TCP, and TCP, > in that order. Since the client supports SCTP, SCTP will be > used, targeted to a host determined by an SRV lookup of > _aaa._sctp.example.com. That lookup would return: > > ;; Priority Weight Port Target > IN SRV 0 1 xxxx server1.example.com > IN SRV 0 2 xxxx server2.example.com > ;; where xxxx is replaced by the well-known port for Diameter > > John From owner-aaa-wg@merit.edu Tue Feb 26 10:20:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02937 for ; Tue, 26 Feb 2002 10:20:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C897C91279; Tue, 26 Feb 2002 10:19:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A64E9127A; Tue, 26 Feb 2002 10:19:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8C3CB91279 for ; Tue, 26 Feb 2002 10:19:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 60B805DDC8; Tue, 26 Feb 2002 10:19:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 16F865DDC1 for ; Tue, 26 Feb 2002 10:19:47 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SCAM>; Tue, 26 Feb 2002 07:19:44 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Jari Arkko'" , IETF AAA List , john.loughney@nokia.com Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Tue, 26 Feb 2002 07:19:38 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BED9.012D9630" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BED9.012D9630 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 a. 1) Non-D, 2) D: Here the arrival of the D record triggers search against all records. Duplicate is found. b. 1) D, 2) Non-D: First the D record arrives, an all record search is performed. The D record goes to a special pool, and the Non-D record, when it arrives, is checked against this pool and duplicate is found. c. 1) D: A search against all records is performed, but no result hence the record is accepted. d. 1) Non-D: A search against the pool is performed, but no result hence the record is accepted. In conclusion, the method requires the following: 1. Checking all D-marked records against *all* other records. 2. Checking all regular records against those stored in the D-pool. 3. The D-pool contents must have some expiration time after which the records are moved out of the pool. The conclusion that I came up with is that a search is required regardless of whether the D bit was set or not, because you cannot guarantee the order in which the packets are received. So what is the gain here? PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHuniTN1fXKoxmisEQJykACfcZ2Ucr3Ff+CwDazfpWGfFoMbzaoAoLAZ XKaefRmI+alo9MT5eTWoFhi3 =WiMu -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BED9.012D9630 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

   a. 1) Non-D, 2) D: Here the = arrival
      of the D record = triggers search
      against all records. = Duplicate is found.

   b. 1) D, 2) Non-D: First the D = record
      arrives, an all = record search is
      performed. The D = record goes to a special
      pool, and the Non-D = record, when it arrives,
      is checked against = this pool and duplicate
      is found.

   c. 1) D: A search against all records = is
      performed, but no = result hence the record
      is accepted.

   d. 1) Non-D: A search against the pool = is
      performed, but no = result hence the record
      is accepted.

In conclusion, the method requires the = following:
  1. Checking all D-marked records against = *all*
     other records.
  2. Checking all regular records against = those
     stored in the = D-pool.
  3. The D-pool contents must have some = expiration
     time after which the = records are moved out of
     the pool.

<PRC> The conclusion that I came up with is = that a search is required
regardless of whether the D bit was set or not, = because you cannot
guarantee the order in which the packets are = received.

So what is the gain here?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHuniTN1fXKoxmisEQJykACfcZ2Ucr3Ff+CwDazfpWGfFoMbzaoAoLA= Z
XKaefRmI+alo9MT5eTWoFhi3
=3DWiMu
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BED9.012D9630-- From owner-aaa-wg@merit.edu Tue Feb 26 10:29:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03402 for ; Tue, 26 Feb 2002 10:29:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A7379127A; Tue, 26 Feb 2002 10:29:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 641ED9127B; Tue, 26 Feb 2002 10:29:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 746D69127A for ; Tue, 26 Feb 2002 10:29:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 50C3A5DDCA; Tue, 26 Feb 2002 10:29:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3CB975DDC1 for ; Tue, 26 Feb 2002 10:29:13 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 119FD7B; Tue, 26 Feb 2002 10:29:13 -0500 (EST) From: "Bob Kopacz" To: "Johan Johansson" Cc: "aaa-wg" Subject: RE: [AAA-WG]: [Issue] Routing of session messages defined in base Date: Tue, 26 Feb 2002 10:28:19 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C7B7328.3060906@ipunplugged.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Johan, I think your issue is very similar to an existing one: > -----Original Message----- From: Bob Kopacz [BKopacz@InterlinkNetworks.com] Sent: Friday, January 25, 2002 2:49 PM To: aaa-wg Subject: [AAA-WG]: [issue] Proxiable messages MUST contain Axxx-Application-Id AVP Issue : Proxiable messages MUST contain Axxx-Application-Id AVP Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 01-25-2002 Reference: Document: Base Comment type: Technical Priority: 1 Section: [I know last-call is over, but pending issues haven't been resolved yet, and I think this is a bug]. Rationale/Explanation of issue: Accounting messages and application-specific messages have an Axxx-Application-Id AVP which identifies the application (e.g. Mobile IP). The Auth-Application-Id AVP is currently prohibited from being present in the Session-Terminate-Request, Abort-Session-Request, and Re-Auth-Request messages. This creates a routing problem for intermediate proxy or relay servers when receiving an STR/ASR/RAR. The intermediate server's routing table may indicate that, say, Mobile-IP messages route to a different next hop than NASREQ messages. An STR message, however, contains no application-id AVP indicating NASREQ-v-MobileIp, so the intermediate server doesn't know how to route it. Requested change: 1. Require an Auth-Application-Id AVP in Session-Terminate-Request, Abort-Session-Request, and Re-Auth-Request messages. 2. Update occurrence rule tables for the "Auth-Application-Id AVP" row, from "0" to "1", for STR and ASR and RAR. > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Johan Johansson > Sent: Tuesday, February 26, 2002 6:36 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: [Issue] Routing of session messages defined in base > > > STR and ASR messages do not belong to any specific application but > rather to all of them. This means that they will take *any* route to > a realm even if it is a dead end. They should contain > Auth-Application-Id avps. > > Submitter name: Johan Johansson > Submitter email address: johanj@ipunplugged.com > Date first submitted: 2002-02-26 > Reference: > Document: base > Comment type: T > Priority: 1 > Section: 10.1, 6.8 > > Rationale/Explanation of issue: > > Let the realm R be a realm with (separate) home servers N and M for > NASREQ and MIP and assume that from a given realm the normal route > passes through a node S that has one NASREQ route to R that will > make messages enter R via N and one MIP route that will make > messages enter R via M, e.g. > > S----------------X------------X------------N > | > +------------X------------M > > Since M and N have no common application they will not be peers. > > Assume that there is an active MIP session at M that the access > device determines to terminate by sending an STR. There is nothing > that prevents S from routing the STR down the N path. > > Requested changes: > > 6.8: I haven't thought of a good change to this section yet. But it > should state that messages regarding a session for a particular > application should contain the id of that application. > > 10.1: Change > > +-----------------------------------------------+ > | Command-Code | > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | > Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | > > to > > +-----------------------------------------------+ > | Command-Code | > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | > Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |1 |0 |1 |0 | > > > I guess the RAR messages should probably also have the > Auth-Application-Id for similar purposes but I'll leave that for > those who actually use it to comment on. > > j > > > From owner-aaa-wg@merit.edu Tue Feb 26 10:37:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03867 for ; Tue, 26 Feb 2002 10:37:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA4589127B; Tue, 26 Feb 2002 10:37:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AA1389127C; Tue, 26 Feb 2002 10:37:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A81109127B for ; Tue, 26 Feb 2002 10:37:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 896EC5DDCB; Tue, 26 Feb 2002 10:37:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by segue.merit.edu (Postfix) with ESMTP id EEE005DDC1 for ; Tue, 26 Feb 2002 10:36:59 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep02-svc.swip.net with ESMTP id <20020226153658.FBMW25354.fep02-svc.swip.net@ipunplugged.com>; Tue, 26 Feb 2002 16:36:58 +0100 Message-ID: <3C7BB9D2.3000104@ipunplugged.com> Date: Tue, 26 Feb 2002 16:37:38 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: Re: [AAA-WG]: [Issue] Routing of session messages defined in base References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yes, the issue has been cloned. Sorry about that. I even looked at the issues list first but I guess I wasn't paying attention closely enough. Nice to see that we are suggesting the same resolution at least. j Bob Kopacz wrote: >Hi Johan, > >I think your issue is very similar to an existing one: > >>-----Original Message----- >> >From: Bob Kopacz [BKopacz@InterlinkNetworks.com] >Sent: Friday, January 25, 2002 2:49 PM >To: aaa-wg >Subject: [AAA-WG]: [issue] Proxiable messages MUST contain Axxx-Application-Id >AVP > >Issue : Proxiable messages MUST contain Axxx-Application-Id AVP >Submitter name: Bob Kopacz >Submitter email address: BKopacz@InterlinkNetworks.com >Date first submitted: 01-25-2002 >Reference: >Document: Base >Comment type: Technical >Priority: 1 >Section: > > [I know last-call is over, but pending issues haven't been resolved > yet, and I think this is a bug]. > >Rationale/Explanation of issue: > > Accounting messages and application-specific messages have an > Axxx-Application-Id AVP which identifies the application (e.g. > Mobile IP). > > The Auth-Application-Id AVP is currently prohibited from being present > in the Session-Terminate-Request, Abort-Session-Request, and > Re-Auth-Request messages. > > This creates a routing problem for intermediate proxy or relay servers > when receiving an STR/ASR/RAR. The intermediate server's routing > table may indicate that, say, Mobile-IP messages route to a different > next hop than NASREQ messages. An STR message, however, contains no > application-id AVP indicating NASREQ-v-MobileIp, so the intermediate > server doesn't know how to route it. > > >Requested change: > > 1. Require an Auth-Application-Id AVP in Session-Terminate-Request, > Abort-Session-Request, and Re-Auth-Request messages. > > 2. Update occurrence rule tables for the "Auth-Application-Id AVP" > row, from "0" to "1", for STR and ASR and RAR. > From owner-aaa-wg@merit.edu Tue Feb 26 10:59:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04814 for ; Tue, 26 Feb 2002 10:59:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5B1DE9121D; Tue, 26 Feb 2002 10:58:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F1BF9127C; Tue, 26 Feb 2002 10:58:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3717A9121D for ; Tue, 26 Feb 2002 10:58:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15AAD5DDC1; Tue, 26 Feb 2002 10:58:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id ABB9E5DDBB for ; Tue, 26 Feb 2002 10:58:52 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1QFJ0324992 for ; Tue, 26 Feb 2002 07:19:00 -0800 Date: Tue, 26 Feb 2002 07:18:59 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Agenda items for IETF 53 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk If you have an agenda item for IETF 53, send mail to myself or Dave Mitton ASAP. From owner-aaa-wg@merit.edu Tue Feb 26 11:13:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05496 for ; Tue, 26 Feb 2002 11:13:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CD3B49127C; Tue, 26 Feb 2002 11:12:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94E249127D; Tue, 26 Feb 2002 11:12:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C9269127C for ; Tue, 26 Feb 2002 11:12:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D8405DDA1; Tue, 26 Feb 2002 11:12:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 7A2B25DDCC for ; Tue, 26 Feb 2002 11:12:50 -0500 (EST) Received: from jariws1 ([62.248.153.130]) by fep06-app.kolumbus.fi with SMTP id <20020226161117.OLPU20539.fep06-app.kolumbus.fi@jariws1>; Tue, 26 Feb 2002 18:11:17 +0200 Message-ID: <003c01c1bee0$3f2ab600$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat R. Calhoun" , "'Jari Arkko'" , "IETF AAA List" , References: Subject: Re: [AAA-WG]: Request for closure on issue 235 Date: Tue, 26 Feb 2002 18:11:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RE: [AAA-WG]: Request for closure on issue 235 > The conclusion that I came up with is that a search is required > regardless of whether the D bit was set or not, because you cannot > guarantee the order in which the packets are received. > So what is the gain here? In case (d) -- the normal case -- the search is performed not to the whole set of records but to a potentially smaller set, the pool of records with D bit set. This set might even be typically empty. So, a search is always needed but not necessarily same type of search. At the end of my e-mail I made some calculations on whether this saves something or not. The conclusions depend on whether you believe the pool search will be less costly than the full record search. Jari From owner-aaa-wg@merit.edu Tue Feb 26 11:36:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08033 for ; Tue, 26 Feb 2002 11:36:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC2C99127E; Tue, 26 Feb 2002 11:36:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE0A09127F; Tue, 26 Feb 2002 11:35:59 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AFD799127E for ; Tue, 26 Feb 2002 11:35:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 906755DDBB; Tue, 26 Feb 2002 11:35:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 4F1305DDA1 for ; Tue, 26 Feb 2002 11:35:58 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 183657B; Tue, 26 Feb 2002 11:35:58 -0500 (EST) From: "Bob Kopacz" To: "John Loughney" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Minor corrections to draft-base-08 Date: Tue, 26 Feb 2002 11:35:05 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Minor corrections to draft-base-08 Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-26-2002 Reference: Document: base 08 Comment type: Editorial Priority: 1 Section: Rationale/Explanation of issue: Minor corrections. Requested change: In Section 2.7 "Peer Table" > The Diameter Peer Table is used in message forwarding, and referenced > by the Realm Routing Table. A Peer Table entry contains the following > fields: > - Host identity. following the conventions described for the > DiameterIdentity derived AVP data format in section 4.4. This > field contains the contents of the Origin-Host AVP found in the > CER or CEA message. > - Status. This is the state of the peer entry, and MUST match one > of the values listed in section 5.6. > - Role. This field specifies whether a peer is a primary, > secondary or alternate. Remove the "-Role" entry. Section 5.1 makes the observation: "Note that a given peer MAY act as a primary for a given realm, while acting as a secondary for another realm." - - - - - In Section 4.5.1 "Example AVP with a Grouped Data type" > The Example AVP (AVP Code 999999) is of type Grouped and is used to > clarify how Grouped AVP values work. The Grouped Data field has the > following ABNF grammar: > > Example-AVP ::= < AVP Header: 999999 > > { Origin-Host } > 1*{ Session-Id } > *[ AVP ] > > An Example AVP with Grouped Data follows. > > The Origin-Host AVP is required. In this case: > > Origin-Host = "example.com". This example is just for illustrative purposes, but it might be better if the Origin-Host value followed the syntax for DiameterIdentity [whatever that is these days :) ]. - - - - - In Section 4.6 "Diameter Base Protocol AVPs" > AVP Section | | | > Attribute Name Code Defined Data Type |MUST| MAY | > -----------------------------------------|----+-----+ > Firmware- 267 5.3.4 Unsigned32 | | P | > Revision | | | > Product-Name 269 5.3.7 UTF8String | | P | I think the 'P' should move from the MAY to the MUST NOT column for AVPs that appear only in CER/CEA messages, such as Firmware-Revision and Product-Name. To my understanding, at the time the CERs/CEAs are exchanged, there couldn't yet be a security assocation between the peers. - - - - - In Section 8.9 "Authorization-Lifetime AVP" > A value of zero (0) means that immediate re-auth is necessary by the > access device. This is typically used in cases where multiple > authentication methods are used, and a successful auth response with > this AVP set to one is used to signal that the next authentication Change "this AVP set to one" to "this AVP set to zero" in the last line. - - - - - In Section 8.10 "Auth-Grace-Period AVP" > This AVP MAY be provided by the client as a hint of the maximum > lifetime that it is willing to accept. However, the server MAY return > a value that is equal to, or smaller, than the one provided by the > client. Remove this paragraph entirely. This is a duplicate of the last paragraph of the section 8.9; looks like a cut&paste error. - - - - - In Section 10.2 "Accounting AVP Table" > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > ... | ... | ... | > Max-Time-Wait | 0+ | 0 | Remove the obsoleted Max-Time-Wait AVP entry. From owner-aaa-wg@merit.edu Tue Feb 26 11:54:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09936 for ; Tue, 26 Feb 2002 11:54:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3924591281; Tue, 26 Feb 2002 11:54:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F2E2C91282; Tue, 26 Feb 2002 11:54:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 113D091281 for ; Tue, 26 Feb 2002 11:54:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEED75DDA9; Tue, 26 Feb 2002 11:54:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by segue.merit.edu (Postfix) with ESMTP id 3177F5DDA1 for ; Tue, 26 Feb 2002 11:54:34 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g1QGsXJ92466 for aaa-wg@merit.edu; Tue, 26 Feb 2002 11:54:33 -0500 (EST) (envelope-from barney) Date: Tue, 26 Feb 2002 11:54:33 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 Message-ID: <20020226115433.A91992@tp.databus.com> References: <003c01c1bee0$3f2ab600$8a1b6e0a@arenanet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <003c01c1bee0$3f2ab600$8a1b6e0a@arenanet.fi>; from jari.arkko@kolumbus.fi on Tue, Feb 26, 2002 at 06:11:28PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk The D-bit is an optimization, so we are entitled to assume that another optimization, namely using User-Name as a primary search key, is also taken. In that case, the two searches are likely to take the same time. But I'd be very careful with the notion of keeping a database of "recent" records - that implies an insert and delete operation on every record in real time and is likely to be painful. There is also the end-to-end argument: the biller should certainly make a check that the line items it is billing contain no duplicates. Therefore making such checks at earlier stages is only justified if the cost of detection and correction is substantially greater at the billing stage. On the other hand, Diameter already contains so many bells and whistles that no argument for simplicity has any force. Barney Wolff On Tue, Feb 26, 2002 at 06:11:28PM +0200, Jari Arkko wrote: > RE: [AAA-WG]: Request for closure on issue 235 > > The conclusion that I came up with is that a search is required > > regardless of whether the D bit was set or not, because you cannot > > guarantee the order in which the packets are received. > > So what is the gain here? > > In case (d) -- the normal case -- the search is performed not to the > whole set of records but to a potentially smaller set, the pool of records > with D bit set. This set might even be typically empty. > > So, a search is always needed but not necessarily same type > of search. At the end of my e-mail I made some calculations on > whether this saves something or not. The conclusions depend on > whether you believe the pool search will be less costly than the > full record search. From owner-aaa-wg@merit.edu Tue Feb 26 11:59:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10155 for ; Tue, 26 Feb 2002 11:59:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 60BD491282; Tue, 26 Feb 2002 11:59:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 283E491283; Tue, 26 Feb 2002 11:59:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EFEDE91282 for ; Tue, 26 Feb 2002 11:59:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2DE45DDA9; Tue, 26 Feb 2002 11:59:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 43E165DDA1 for ; Tue, 26 Feb 2002 11:59:11 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1QGxAd23051 for ; Tue, 26 Feb 2002 16:59:10 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 26 Feb 2002 16:54:16 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA16386 for ; Tue, 26 Feb 2002 16:59:06 GMT Message-ID: <3C7BBEDA.264DF3A0@baltimore.ie> Date: Tue, 26 Feb 2002 16:59:06 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: IETF AAA List Subject: [AAA-WG]: Additional cms issues Content-Type: multipart/mixed; boundary="------------B381C351D64A9313AB6A9F35" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------B381C351D64A9313AB6A9F35 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks, While *still* attempting to catch up on this mailing list, I've come across the following, hopefully easy to handle, CMS issues. Let me know if you disagree with the resolutions (ideally this week). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com --------------B381C351D64A9313AB6A9F35 Content-Type: text/plain; charset=us-ascii; name="cms-04-issues.txt" Content-Disposition: inline; filename="cms-04-issues.txt" Content-Transfer-Encoding: 7bit Submitter name: Stephen Farrell Submitter email address: stephen.farrell@baltimore.ie Date first submitted: 2002-02-26 Reference: Document: cms Comment type: E Priority: 1 Section: 1.0 & others Rationale/Explanation of issue: The term non-repudiation has a long and convoluted history in the PKI community. IMO, its use has generally confused things - something we don't want here. I think that what we are really required to provide is data origin authentication, which is both clear and is something that signatures do provide nicely. Requested changes: s/non-repudiation/data origin authentication/g Submitter name: Stephen Farrell Submitter email address: stephen.farrell@baltimore.ie Date first submitted: 2002-02-26 Reference: Document: cms Comment type: T Priority: S Section: 6.0, 6.2 Rationale/Explanation of issue: CMS-Encrypted-Data can be multivalued, so OctetString is the wrong type for this AVP. Requested changes: s/OctetString/Grouped/g Submitter name: Stephen Farrell Submitter email address: stephen.farrell@baltimore.ie Date first submitted: 2002-02-26 Reference: Document: cms Comment type: T Priority: S Section: 6.8 Rationale/Explanation of issue: CA-Chain-AVP has a bunch of certs, but the spec doesn't say in what format. The usual thing here is to support the CMS degenerate form of SignedData, known as a certs-only message. Requested changes: Add: The OctetString contains a CMS "certs-only" message. Submitter name: Stephen Farrell Submitter email address: stephen.farrell@baltimore.ie Date first submitted: 2002-02-26 Reference: Document: cms Comment type: T Priority: 1 Section: 1.3 Rationale/Explanation of issue: Section 1.3 (2nd para) says: "Therefore proxy agents either MUST NOT modify protected AVPs or else MUST NOT allow the DSA to be established." This seems overly restrictive, quite hard to implement and of little value esp since we say that if a signature is present then don't mess with AVPs. Later on the same section says: "Although the proxy agent MAY receive many PDSRs from access devices, only one DSA per realm MUST be established." This seems both overly prescriptive and restrictive. Requested changes: Delete first sentence and change MUST -> MAY in 2nd case. --------------B381C351D64A9313AB6A9F35-- From owner-aaa-wg@merit.edu Tue Feb 26 12:09:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10666 for ; Tue, 26 Feb 2002 12:09:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3667691283; Tue, 26 Feb 2002 12:09:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0448691284; Tue, 26 Feb 2002 12:09:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7D2991283 for ; Tue, 26 Feb 2002 12:09:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id B5BDB5DDBB; Tue, 26 Feb 2002 12:09:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id F12795DDA1 for ; Tue, 26 Feb 2002 12:09:09 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1QH99d23376 for ; Tue, 26 Feb 2002 17:09:09 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 26 Feb 2002 17:04:16 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA16639; Tue, 26 Feb 2002 17:09:06 GMT Message-ID: <3C7BC132.EABDDB3A@baltimore.ie> Date: Tue, 26 Feb 2002 17:09:06 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] Ambiguities in AVP Flag rules tables References: <3C76BCAA.7CAA2E9B@Interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'll delete the "P" from the MUST NOT column for DSA-TTL in the cms draft. If that's wrong, let me know. Stephen. David Spence wrote: > > Subject: [issue] Ambiguities in AVP Flag rules tables > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: 2/22/2 > Reference: > Document: base, cms-sec > Comment type: T > Priority: 1 > Section: base sec. 4.6, cms-sec sec. 6.0 > Rationale/Explanation of issue: > > Several AVPs listed in the table in sec. 4.6 of the base draft do not > include all three flags in the AVP Flag rules columns. This leads to > ambiguities. For example, how should I set the 'M' flag in the > Error-Message AVP? 'M' is not listed in the MAY column so I guess I > can't set it, but then 'M' is not listed in the MUST NOT column so > perhaps I can set it. > > In the AVP Flag rules table in sec. 6.0 of the cms-sec draft, in the > DSA-TTL row, the 'P' flag is listed twice. It appears in both the > MAY and MUST NOT columns. > > Requested change: > > The following rows in the table in sec. 4.6 of the base draft need to > be fixed: > > Error-Message > Error-Reporting-Host > Product-Name > Redirect-Host > > The following row in the table in sec 6.0 of the cms-sec draft needs > to be fixed: > > DSA-TTL -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Feb 26 12:11:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10794 for ; Tue, 26 Feb 2002 12:11:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57CE491284; Tue, 26 Feb 2002 12:11:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 255EA91285; Tue, 26 Feb 2002 12:11:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35CDB91284 for ; Tue, 26 Feb 2002 12:11:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 19C3B5DDBB; Tue, 26 Feb 2002 12:11:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 05BBA5DDA1 for ; Tue, 26 Feb 2002 12:11:06 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id C180D7B; Tue, 26 Feb 2002 12:11:05 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: Subject: RE: [AAA-WG]: ISSUE 266: ready for closure? Date: Tue, 26 Feb 2002 12:10:12 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C7AC672.644E268@ericsson.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > > Bob Kopacz wrote: > > > > Hi Tony, > > > > (1) One thought: If the AAAH wants to hide an AAAH-generated key being > > sent to the FA (or foreign HA), the AAAH sets up a CMS security > > assocation with the FA (or foreign HA), not with the AAAF. If the > > destination AAAF wants to hide the FA-HA key, shouldn't it then just > > do the same, i.e. set up a CMS security assocation with the FA, rather > > than adding protocol and setting up a CMS security assocation with the > > originating AAAF? Otherwise, an AAAH wanting to hide an FA-HA key and > > an AAAF wanting to hide an FA-HA key invoke different solutions. When, > > in the course of the mailing list dialogue, the HAA-to-AMA-Data AVP > > was superseded by CMS, this thought hadn't occurred to me. > > Hi Bob, > > Well, we must still make it possible encrypt the FA-HA Key between the > two AAAFs involved, since there is only a SHOULD for Diameter clients > to support DSA. > > /Tony Your note that clients are not required to support CMS is a good one, so I'm back on track with you. Forget my "One thought". But now I've got another problem: Because clients are not required to support CMS, the proposed issue#266 solution (for the case where the HA is in a foreign realm and the destination-AAAF generates the FA-to-HA key and wants to hide it) is to set up a DSA between the originating-AAAF and the destination-AAAF, and pass the FA-to-HA-Key as encrypted CMS data. And the FA trusts his local AAAF, so no hiding is required for the final hop. All is good. Question: This "client might not support CMS" problem affects all the keys that might need to be hidden, not just the FA-HA key, right? That is, suppose we have the simple case where we have an FA in foreign domain talking to his local AAAF, and the HA is in the home network. Suppose the AAAH wants send FA-to-xx keys back to the FA via the AMA, but wants to hide them, as the AMA may be traversing intermediate networks. If so, my understanding is that the AAAH would set up a DSA with the FA and pass the CMS-encrypted keys to the FA, which may not work because the FA doesn't do CMS. If the solution is to have the AAAH instead set up a DSA with the originating-AAAF and pass the hidden keys ala Issue#266, then this is ok, but would need to be added to the draft-mobileip. This also applies in another case: if the AAAH is generating an HA-to-MN-Key for the HA in a foreign network, and wants to hide it. Bob K. From owner-aaa-wg@merit.edu Tue Feb 26 12:11:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10832 for ; Tue, 26 Feb 2002 12:11:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 40DFF91285; Tue, 26 Feb 2002 12:11:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 168E291286; Tue, 26 Feb 2002 12:11:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0EA1391285 for ; Tue, 26 Feb 2002 12:11:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id E0F3C5DDBB; Tue, 26 Feb 2002 12:11:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 0A9055DDA1 for ; Tue, 26 Feb 2002 12:11:40 -0500 (EST) Received: from jariws1 ([62.248.153.130]) by fep06-app.kolumbus.fi with SMTP id <20020226171139.ORTK20539.fep06-app.kolumbus.fi@jariws1>; Tue, 26 Feb 2002 19:11:39 +0200 Message-ID: <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "IETF AAA List" References: <3C7BBEDA.264DF3A0@baltimore.ie> Subject: Re: [AAA-WG]: Additional cms issues Date: Tue, 26 Feb 2002 19:11:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > s/non-repudiation/data origin authentication/g Yes. > s/OctetString/Grouped/g Yes. > The OctetString contains a CMS "certs-only" message. Yes. > "Therefore proxy agents either MUST NOT modify protected AVPs or > else MUST NOT allow the DSA to be established." > > This seems overly restrictive, quite hard to implement and of > little value esp since we say that if a signature is present > then don't mess with AVPs. This I don't understand. If the proxy has an intent to sometimes modify AVPs that have been specified as encrypted/signed in our specs, then it MUST NOT modify those AVPs. Or else it simply refuses to let DSAR through, and establishes its own end-to-end security association. > "Although the proxy agent MAY receive many PDSRs from access > devices, only one DSA per realm MUST be established." > Change MUST -> MAY. Yes. Jari From owner-aaa-wg@merit.edu Tue Feb 26 12:29:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11750 for ; Tue, 26 Feb 2002 12:29:34 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A7AF91288; Tue, 26 Feb 2002 12:29:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C21C91289; Tue, 26 Feb 2002 12:29:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 37CDA91288 for ; Tue, 26 Feb 2002 12:29:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 111CC5DDA9; Tue, 26 Feb 2002 12:29:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 4D0ED5DDA1 for ; Tue, 26 Feb 2002 12:29:22 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1QHTLd24039 for ; Tue, 26 Feb 2002 17:29:21 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 26 Feb 2002 17:24:28 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA17063; Tue, 26 Feb 2002 17:29:18 GMT Message-ID: <3C7BC5EE.4F8FD5BB@baltimore.ie> Date: Tue, 26 Feb 2002 17:29:18 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: IETF AAA List Subject: Re: [AAA-WG]: Additional cms issues References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, > > "Therefore proxy agents either MUST NOT modify protected AVPs or > > else MUST NOT allow the DSA to be established." > > > > This seems overly restrictive, quite hard to implement and of > > little value esp since we say that if a signature is present > > then don't mess with AVPs. > > This I don't understand. Huh? Do you not understand my problem or the text (if the latter, then we're in the same boat:-). > If the proxy has an intent to sometimes > modify AVPs that have been specified as encrypted/signed > in our specs, then it MUST NOT modify those AVPs. Or else > it simply refuses to let DSAR through, and establishes its own > end-to-end security association. I *think* that's a restatment of the sentence that causes me a problem. Is it ok for me to delete the offending sentence? Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Feb 26 12:31:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11822 for ; Tue, 26 Feb 2002 12:31:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E979691289; Tue, 26 Feb 2002 12:31:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B30119128A; Tue, 26 Feb 2002 12:31:33 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90AA391289 for ; Tue, 26 Feb 2002 12:31:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 71C905DDA1; Tue, 26 Feb 2002 12:31:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 8E8665DDA9 for ; Tue, 26 Feb 2002 12:31:31 -0500 (EST) Received: from jariws1 ([62.248.153.130]) by fep06-app.kolumbus.fi with SMTP id <20020226173128.OTXZ20539.fep06-app.kolumbus.fi@jariws1>; Tue, 26 Feb 2002 19:31:28 +0200 Message-ID: <00b301c1beeb$72e6b9c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "IETF AAA List" References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> <3C7BC5EE.4F8FD5BB@baltimore.ie> Subject: Re: [AAA-WG]: Additional cms issues Date: Tue, 26 Feb 2002 19:31:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Huh? Do you not understand my problem or the text (if the > latter, then we're in the same boat:-). I do understand the text, but not your problem. But I must be missing something. > > If the proxy has an intent to sometimes > > modify AVPs that have been specified as encrypted/signed > > in our specs, then it MUST NOT modify those AVPs. Or else > > it simply refuses to let DSAR through, and establishes its own > > end-to-end security association. > > I *think* that's a restatment of the sentence that causes me > a problem. > > Is it ok for me to delete the offending sentence? Here's the two issues that I didn't understand in your problem: 1) Why would we need to modify AVPs that have been signed? It's going to fail anyway. 2) What is the implementation difficulty of not modifying those AVPs? Jari From owner-aaa-wg@merit.edu Tue Feb 26 12:33:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12029 for ; Tue, 26 Feb 2002 12:33:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8444C9128A; Tue, 26 Feb 2002 12:33:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 55E939128B; Tue, 26 Feb 2002 12:33:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6048A9128A for ; Tue, 26 Feb 2002 12:33:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 469FB5DDA9; Tue, 26 Feb 2002 12:33:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 360E75DDA1 for ; Tue, 26 Feb 2002 12:33:01 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QHYux23593 for ; Tue, 26 Feb 2002 11:34:56 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 11:32:51 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 11:32:05 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Feb 2002 11:32:05 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12828@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG+5lLkYj20kouOQziWpADvfKAmcQABScnA From: To: , X-OriginalArrivalTime: 26 Feb 2002 17:32:05.0597 (UTC) FILETIME=[825030D0:01C1BEEB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA12029 Barney Wolff [barney@databus.com] wrote: >The D-bit is an optimization, so we are entitled to assume that another >optimization, namely using User-Name as a primary search key, is also >taken. Agreed. The "D" bit will not necessarily cause every implementation to do duplicate detection based on this bit. Duplicate detection can be done via other means as has been discussed on the list. However with the "D" bit it would allow searches to be done on a very small subset of all records and thereby improve efficiency. >In that case, the two searches are likely to take the same time. >But I'd be very careful with the notion of keeping a database of "recent" >records - that implies an insert and delete operation on every record >in real time and is likely to be painful. > As I mentioned above, with the "D" bit you would not have to do an insert/delete database op on every record. >There is also the end-to-end argument: the biller should certainly make >a check that the line items it is billing contain no duplicates. Therefore >making such checks at earlier stages is only justified if the cost of >detection and correction is substantially greater at the billing stage. > >On the other hand, Diameter already contains so many bells and whistles >that no argument for simplicity has any force. > >Barney Wolff > -Basavaraj From owner-aaa-wg@merit.edu Tue Feb 26 12:33:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12073 for ; Tue, 26 Feb 2002 12:33:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E22B49128B; Tue, 26 Feb 2002 12:33:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABB389128C; Tue, 26 Feb 2002 12:33:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE31C9128B for ; Tue, 26 Feb 2002 12:33:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3CF05DDA9; Tue, 26 Feb 2002 12:33:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8FECA5DDA1 for ; Tue, 26 Feb 2002 12:33:35 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 6CBCF7E; Tue, 26 Feb 2002 12:33:35 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: Subject: RE: [AAA-WG]: ISSUE 266: ready for closure? Date: Tue, 26 Feb 2002 12:32:42 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C7B2C7F.F72162DE@ericsson.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > > Bob Kopacz wrote: > > > > (4) I don't understand how the originating AAAF intelligently sets the > > Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a > > "real" HA IP address (not all zeroes or all ones). The AAAF only sees > > an IP address. The AAAF doesn't know just from the HA's IP address > > whether that represents an HA in the home network, or an HA in another > > foreign network. And maybe doesn't even know if the IP address is in > > his own network. So how does the AAAF set the > > Home-Agent-In-Foreign-Network flag? > > [Tony] E.g. the AAAF could use a DNS look up to find out the HAs realm > and host name. If this is what the AAAF would have to do to correctly set the Home-Agent-In-Foreign-Network flag, then maybe we should just get rid of this flag altogether. Or change it to a flag that is not set by the originating-AAAF, but instead by the AAAH. The reason is that, if the AAAF is using DNS to find out the HA's realm and host name, the AAAF is just duplicating work the AAAH has to do anyway: When the AAAH receives the AMR with the a specified HA IP address, the AAAH has to map this IP address into the HA's realm and DiameterIdentity, which will be used as the Destination-Realm and Destination-Host of the HAR. The AAAH may be able to do this a lot easier than the AAAF, as a session-stateful AAAH may just have this information at hand. Bob K. From owner-aaa-wg@merit.edu Tue Feb 26 12:36:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12235 for ; Tue, 26 Feb 2002 12:36:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1099C9128C; Tue, 26 Feb 2002 12:36:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC7B39128D; Tue, 26 Feb 2002 12:36:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D07ED9128C for ; Tue, 26 Feb 2002 12:36:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id A944F5DDBF; Tue, 26 Feb 2002 12:36:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id C76685DDA9 for ; Tue, 26 Feb 2002 12:36:05 -0500 (EST) Received: from jariws1 ([62.248.153.130]) by fep06-app.kolumbus.fi with SMTP id <20020226173604.OUMD20539.fep06-app.kolumbus.fi@jariws1>; Tue, 26 Feb 2002 19:36:04 +0200 Message-ID: <00c201c1beec$17ac1f40$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , , References: <697DAA22C5004B4596E033803A7CEF44A12828@daebe007.NOE.Nokia.com> Subject: Re: [AAA-WG]: Request for closure on issue 235 Date: Tue, 26 Feb 2002 19:36:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Barney Wolff [barney@databus.com] wrote: >The D-bit is an optimization, so we are entitled to assume that another >optimization, namely using User-Name as a primary search key, is also >taken. >In that case, the two searches are likely to take the same time. I think one of the central question to answer is why the User-Name optimization is not sufficient. Basavaraj, can you comment on that? Jari From owner-aaa-wg@merit.edu Tue Feb 26 12:51:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12894 for ; Tue, 26 Feb 2002 12:51:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 893519128D; Tue, 26 Feb 2002 12:51:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58D3B9128E; Tue, 26 Feb 2002 12:51:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 388E19128D for ; Tue, 26 Feb 2002 12:51:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 133B55DDA9; Tue, 26 Feb 2002 12:51:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 456E15DDA1 for ; Tue, 26 Feb 2002 12:51:14 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1QHpDd24566 for ; Tue, 26 Feb 2002 17:51:13 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 26 Feb 2002 17:46:20 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA17382; Tue, 26 Feb 2002 17:51:11 GMT Message-ID: <3C7BCB0F.79CF5955@baltimore.ie> Date: Tue, 26 Feb 2002 17:51:11 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: IETF AAA List Subject: Re: [AAA-WG]: Additional cms issues References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> <3C7BC5EE.4F8FD5BB@baltimore.ie> <00b301c1beeb$72e6b9c0$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari, > > Huh? Do you not understand my problem or the text (if the > > latter, then we're in the same boat:-). > > I do understand the text, but not your problem. But I must > be missing something. My problem is that I find the quoted sentence confusing and useless. I'm definitely missing something, if the sentence belongs where it is. > "Therefore proxy agents either MUST NOT modify protected AVPs or > else MUST NOT allow the DSA to be established." Given that there can only be a signed AVP is there's a CMS-Signed-Data AVP in the message and that signed AVPs always have the "P" bit set then a proxy agent can always tell what not to mess with. So I don't see any need to say "don't mess" again. Following on from that, I see no need for a proxy to disallow DSA establishment just because it might sometime want to mess with signed stuff. Is there such a need? If so, under what circumstances? > 1) Why would we need to modify AVPs that have been > signed? It's going to fail anyway. I don't know & agree, in that order. I want to loose that text. > 2) What is the implementation difficulty of not modifying > those AVPs? Huh? The fact that follow-on questions like that crop up is yet another reason for me to ask: > > > Is it ok for me to delete the offending sentence? :-) Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Tue Feb 26 13:18:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14274 for ; Tue, 26 Feb 2002 13:18:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 29C269128F; Tue, 26 Feb 2002 13:18:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED84E91290; Tue, 26 Feb 2002 13:18:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7A539128F for ; Tue, 26 Feb 2002 13:18:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id A83B35DDD3; Tue, 26 Feb 2002 13:18:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id C84105DDC1 for ; Tue, 26 Feb 2002 13:18:09 -0500 (EST) Received: from jariws1 ([62.248.153.130]) by fep06-app.kolumbus.fi with SMTP id <20020226181808.OYOM20539.fep06-app.kolumbus.fi@jariws1>; Tue, 26 Feb 2002 20:18:08 +0200 Message-ID: <00ff01c1bef1$f8599220$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: "IETF AAA List" References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> <3C7BC5EE.4F8FD5BB@baltimore.ie> <00b301c1beeb$72e6b9c0$8a1b6e0a@arenanet.fi> <3C7BCB0F.79CF5955@baltimore.ie> Subject: Re: [AAA-WG]: Additional cms issues Date: Tue, 26 Feb 2002 20:18:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > "Therefore proxy agents either MUST NOT modify protected AVPs or > > else MUST NOT allow the DSA to be established." > > Given that there can only be a signed AVP is there's a > CMS-Signed-Data AVP in the message and that signed AVPs always > have the "P" bit set then a proxy agent can always tell what not > to mess with. So I don't see any need to say "don't mess" again. Ok, now I think I understand this part... > Following on from that, I see no need for a proxy to disallow > DSA establishment just because it might sometime want to mess > with signed stuff. Is there such a need? If so, under what > circumstances? Well, the first paragraph of 1.3 talks about cases where the proxy agent wants to implement policy or modify potentially harm-causing AVPs. Assuming this is a real need, imagine a network scenario wher a new NAS is brought to the network, and since the operator didn't bother configuring it too much, it tries to establish a DSA to the home AAA server. At this point all policy management and harm-prevention stops, because the NAS happened to establish a DSA of its own. Don't we need something in the proxy agent to catch the DSA establishment attempt? Isn't this what DIAMETER_NO_CMS_THROUGH_PROXY is for? Jari From owner-aaa-wg@merit.edu Tue Feb 26 13:24:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14642 for ; Tue, 26 Feb 2002 13:24:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 744DB91290; Tue, 26 Feb 2002 13:23:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A0BD91291; Tue, 26 Feb 2002 13:23:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1404A91290 for ; Tue, 26 Feb 2002 13:23:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3C9F5DDCC; Tue, 26 Feb 2002 13:23:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id CF3CB5DDC1 for ; Tue, 26 Feb 2002 13:23:36 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 8FB707A; Tue, 26 Feb 2002 13:23:36 -0500 (EST) From: "Bob Kopacz" To: "John Loughney" Cc: "aaa-wg" Subject: [AAA-WG]: base-08 reference to CMS-Cert AVP Date: Tue, 26 Feb 2002 13:22:43 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, base-08 Section 6.1.7 "Redirecting requests", says: > Redirect agents MAY also include the certificate of the servers in > the Redirect-Host AVP(s). These certificates are encapsulated in a > CMS-Cert AVP [11]. The above sentence references a CMS-Cert AVP. It looks like that AVP has been removed from the CMS draft. Maybe "AAA-Node-Cert AVP" is what should be above. Bob K. From owner-aaa-wg@merit.edu Tue Feb 26 13:52:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15952 for ; Tue, 26 Feb 2002 13:52:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CB15C91291; Tue, 26 Feb 2002 13:52:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2D3691294; Tue, 26 Feb 2002 13:52:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B143591291 for ; Tue, 26 Feb 2002 13:52:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8734F5DDBE; Tue, 26 Feb 2002 13:52:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by segue.merit.edu (Postfix) with ESMTP id D6FF35DDB1 for ; Tue, 26 Feb 2002 13:52:12 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g1QIqC193082 for aaa-wg@merit.edu; Tue, 26 Feb 2002 13:52:12 -0500 (EST) (envelope-from barney) Date: Tue, 26 Feb 2002 13:52:12 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 Message-ID: <20020226135212.A92866@tp.databus.com> References: <697DAA22C5004B4596E033803A7CEF44A12828@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12828@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Tue, Feb 26, 2002 at 11:32:05AM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk When the D record arrives, all "recent" records must be searched to find the possible original. Either this is a brute-force sequential search, or some sort of indexing on all records must be maintained, and records aged out when no longer recent. Yes, the delete could be effectively done in batches, by keeping hourly databases. My problem with the D-bit is that it invites doing something in real time that does not need to be done in real time, and puts a burden on the sender while saving very little if anything for the receiver. The biller is going to sort the records anyway, and finding adjacent duplicates is trivial with or without the D-bit. Barney Wolff On Tue, Feb 26, 2002 at 11:32:05AM -0600, Basavaraj.Patil@nokia.com wrote: > ... However with > the "D" bit it would allow searches to be done on a very small subset > of all records and thereby improve efficiency. > > >In that case, the two searches are likely to take the same time. > >But I'd be very careful with the notion of keeping a database of "recent" > >records - that implies an insert and delete operation on every record > >in real time and is likely to be painful. > > > > As I mentioned above, with the "D" bit you would not have to do an > insert/delete database op on every record. From owner-aaa-wg@merit.edu Tue Feb 26 14:01:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16489 for ; Tue, 26 Feb 2002 14:01:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5AE2391225; Tue, 26 Feb 2002 14:00:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CF8B91294; Tue, 26 Feb 2002 14:00:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1666B91225 for ; Tue, 26 Feb 2002 14:00:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A28BE5DDA1; Tue, 26 Feb 2002 14:00:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 329185DDCA for ; Tue, 26 Feb 2002 14:00:25 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QJ0YZ14929 for ; Tue, 26 Feb 2002 21:00:34 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 21:00:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 21:00:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 249: Editorial nits in Diameter Base -08 (CLOSED) Date: Tue, 26 Feb 2002 21:00:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A41@esebe004.NOE.Nokia.com> Thread-Topic: Issue 249: Editorial nits in Diameter Base -08 (CLOSED) Thread-Index: AcG+99ZXp13/cAHCRZ6onyZeJ208rA== From: To: X-OriginalArrivalTime: 26 Feb 2002 19:00:24.0269 (UTC) FILETIME=[D8915FD0:01C1BEF7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA16489 Hi all, I've commited the editorial nits to the -09 doc. John From owner-aaa-wg@merit.edu Tue Feb 26 14:16:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17122 for ; Tue, 26 Feb 2002 14:16:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 87FDA91293; Tue, 26 Feb 2002 14:15:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 237B291294; Tue, 26 Feb 2002 14:15:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2391991293 for ; Tue, 26 Feb 2002 14:15:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBE635DDB1; Tue, 26 Feb 2002 14:15:11 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id B88565DDA1 for ; Tue, 26 Feb 2002 14:15:11 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 734C67A; Tue, 26 Feb 2002 14:15:11 -0500 (EST) Message-ID: <3C7BDEC5.D5904675@Interlinknetworks.com> Date: Tue, 26 Feb 2002 14:15:17 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 251: References to ADIF in NASREQ-08 References: Content-Type: multipart/mixed; boundary="------------BE330FB144EA13D0E62EED54" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------BE330FB144EA13D0E62EED54 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Done. I deleted these and many other references to ADIF throughout the draft. Bernard Aboba wrote: > > Submitter: Bernard Aboba > Date: December 28, 2001 > Document: Nasreq-08 > Rationale: Support for ADIF was removed a while back > Sections 7.4.3 and 7.4.4 > > In both sections it is stated "This AVP SHOULD Be included in the ADIF > Record of the corresponding Accounting-Request messages" > > Suggestion: strike "the ADIF Record of" --------------BE330FB144EA13D0E62EED54 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------BE330FB144EA13D0E62EED54-- From owner-aaa-wg@merit.edu Tue Feb 26 14:54:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19126 for ; Tue, 26 Feb 2002 14:54:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7121F91296; Tue, 26 Feb 2002 14:53:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44CC491297; Tue, 26 Feb 2002 14:53:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D28291296 for ; Tue, 26 Feb 2002 14:53:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 350145DDB1; Tue, 26 Feb 2002 14:53:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 208595DDA1 for ; Tue, 26 Feb 2002 14:53:51 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id D63E27B; Tue, 26 Feb 2002 14:53:50 -0500 (EST) Message-ID: <3C7BE7D4.1C57B0AD@Interlinknetworks.com> Date: Tue, 26 Feb 2002 14:53:56 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: Jari.Arkko@lmf.ericsson.se, aaa-wg Subject: Re: [AAA-WG]: Issue 264: User-Name in Answer messages References: Content-Type: multipart/mixed; boundary="------------0D31168CBAF2396FC52BC3A0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------0D31168CBAF2396FC52BC3A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In order to maintain consistency with RADIUS, I do not support MUST. RFC 2865 states that the User-Name attribute MAY be sent in an Access-Accept packet. If I say that the User-Name AVP MUST pe present in a Diameter AA-Answer message, then I will make life difficult for gateway implementors. If a gateway receives a RADIUS Access-Accept message that does not contain a User-Name attribute and generates a Diameter AA-Answer message, it would have to go back and sift through the Access-Request to find the User-Name. So I vote for MAY. It also appears that Tony missed the thread and edited a MAY into the MIP draft per the original request. See: http://www.merit.edu/mail.archives/aaa-wg/2002-01/msg00090.html David S. Bob Kopacz wrote: > > Hi, > > > > > >Since it is natural and harmless for an implementation to echo back > > >the User-Name, allow but do not require the User-Name AVP to appear in > > >Answer messages, if present in the Request. > > > > I agree with this issue. > > > > Maybe we could give less room for interpretation in the > > text though. I propose "MUST echo back User-Name AVP if present > > in the Request". > > Sure, this is fine. I'm mainly after consistency. > > > Jari > > > > Bob K. --------------0D31168CBAF2396FC52BC3A0 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------0D31168CBAF2396FC52BC3A0-- From owner-aaa-wg@merit.edu Tue Feb 26 15:27:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20424 for ; Tue, 26 Feb 2002 15:27:48 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE62191258; Tue, 26 Feb 2002 15:27:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A22E991297; Tue, 26 Feb 2002 15:27:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AA62991258 for ; Tue, 26 Feb 2002 15:27:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 898545DDA1; Tue, 26 Feb 2002 15:27:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 0DCA05DD9E for ; Tue, 26 Feb 2002 15:27:35 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKTcx09199 for ; Tue, 26 Feb 2002 14:29:38 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 14:27:33 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 14:27:04 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BF03.F3CC20D0" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Feb 2002 14:27:03 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12830@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG+2Rz34qCaNonpS4aBbu7e5zSwMwAKsYGA From: To: , , , X-OriginalArrivalTime: 26 Feb 2002 20:27:04.0384 (UTC) FILETIME=[F413F400:01C1BF03] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1BF03.F3CC20D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comment below: >> a. 1) Non-D, 2) D: Here the arrival=20 >> of the D record triggers search=20 >> against all records. Duplicate is found.=20 >> >> b. 1) D, 2) Non-D: First the D record=20 >> arrives, an all record search is=20 >> performed. The D record goes to a special=20 >> pool, and the Non-D record, when it arrives,=20 >> is checked against this pool and duplicate=20 >> is found.=20 >> >> c. 1) D: A search against all records is=20 >> performed, but no result hence the record=20 >> is accepted.=20 >> >> d. 1) Non-D: A search against the pool is=20 >> performed, but no result hence the record=20 >> is accepted.=20 >> >>In conclusion, the method requires the following:=20 >> 1. Checking all D-marked records against *all*=20 >> other records.=20 >> 2. Checking all regular records against those=20 >> stored in the D-pool.=20 >> 3. The D-pool contents must have some expiration=20 >> time after which the records are moved out of=20 >> the pool.=20 > > The conclusion that I came up with is that a search is required=20 >regardless of whether the D bit was set or not, because you cannot=20 >guarantee the order in which the packets are received.=20 > >So what is the gain here?=20 =20 Rather than checking every record against every other record, you would only check a very small set of records that are marked with the "D" bit against every other record. =20 > >PatC=20 > =20 -Basavaraj ------_=_NextPart_001_01C1BF03.F3CC20D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235
Comment = below:

>>   a. 1) Non-D, 2) = D: Here the=20 arrival
>>      of the D record = triggers=20 search
>>      against all records. = Duplicate=20 is found.
>>
>>   b. 1) D, 2) Non-D: First = the D=20 record
>>      arrives, an all record = search=20 is
>>      performed. The D record = goes to a=20 special
>>      pool, and the Non-D = record,=20 when it arrives,
>>      is checked = against=20 this pool and duplicate
>>      is = found.=20
>>
>>   c. 1) D: A search against all = records is=20
>>      performed, but no result = hence the=20 record
>>      is accepted.=20
>>
>>   d. 1) Non-D: A search against the = pool is=20
>>      performed, but no result = hence the=20 record
>>      is accepted.=20
>>
>>In conclusion, the method requires the = following:=20
>>  1. Checking all D-marked records against *all*=20
>>     other records.
>>  = 2.=20 Checking all regular records against those =
>>    =20 stored in the D-pool.
>>  3. The D-pool contents must = have some=20 expiration
>>     time after which the = records are=20 moved out of
>>     the pool.=20
>
><PRC> The conclusion that I came up with is that a = search=20 is required
>regardless of whether the D bit was set or not, = because you=20 cannot
>guarantee the order in which the packets are received.=20
>
>So what is the gain here?
 
Rather than checking = every record=20 against every other record, you
would only check a very small set of = records=20 that are marked with the
"D" bit against every other = record.
 
>
>PatC=20
>
 
-Basavaraj
------_=_NextPart_001_01C1BF03.F3CC20D0-- From owner-aaa-wg@merit.edu Tue Feb 26 15:46:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20814 for ; Tue, 26 Feb 2002 15:46:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BE54191297; Tue, 26 Feb 2002 15:45:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FFBA91298; Tue, 26 Feb 2002 15:45:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 71B1D91297 for ; Tue, 26 Feb 2002 15:45:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A3C35DDBB; Tue, 26 Feb 2002 15:45:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 68F7B5DDA1 for ; Tue, 26 Feb 2002 15:45:32 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjeZ13147 for ; Tue, 26 Feb 2002 22:45:41 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:31 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 243: Session State Machine for Diameter agents Date: Tue, 26 Feb 2002 22:45:31 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22A9E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue: Collection of Accounting data Thread-Index: AcG+oGmyS/4w53hmSiuw58HReGKzRgAWj/vQ From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:31.0357 (UTC) FILETIME=[87E2A0D0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20814 Hi all, This issue was marked as a possible reject. At this point, I personally feel that is unnescessary. If noone speaks up on behalf of this, I will mark this as a reject. br, John Submitter name: Yoshihiro Ohba Submitter email address: yohba@tari.toshiba.com Date first submitted: November 13, 2001 Document: base Comment type: E Priority: 1 Section: 8.1, 8.2 Rationale/Explanation of issue: Authorization Session State Machine and Accounting Session State Machine seem to define FSM for Diameter clients and servers but not for Diameter agents (i.e., relay, proxy, redirect and translation agents). For example, in section 8.1, when a Service-specific authorization request is received from a peer in Idle state, there is no action to *forward* the received request to the next-hop peer of the session and move to Pending state, which would be a normal action for relay agents. Similarly, when a Service-specific authorization answer is received from the next-hop peer of the session in Pending state, there is no action to *return* the received answer to the previous-hop peer of the session and move to Open state (in the case of stateful relay agents) or Idle state (in the case of stateless relay agents), which would also be a normal action for relay agents. Requested change: Additional state transitions need to be included in section 8.1 and 8.2 to support relay, proxy, redirect and translation agents. From owner-aaa-wg@merit.edu Tue Feb 26 15:46:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20836 for ; Tue, 26 Feb 2002 15:46:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 04F2F9129B; Tue, 26 Feb 2002 15:45:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B876E9129A; Tue, 26 Feb 2002 15:45:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E02C91299 for ; Tue, 26 Feb 2002 15:45:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 698B35DDA1; Tue, 26 Feb 2002 15:45:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id AE9275DDBB for ; Tue, 26 Feb 2002 15:45:36 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKk8i13330 for ; Tue, 26 Feb 2002 22:46:08 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:35 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 245: User-Name avp in the RAR and RAA message CLOSED Date: Tue, 26 Feb 2002 22:45:34 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA0@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG+18DDemrvf07aS/u+5R1EVNbQKwAJdW2Q From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:35.0651 (UTC) FILETIME=[8A71D730:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20836 Hi all, Correction has been committed to the document. John Issue 245: User-Name avp in the RAR and RAA message Submitter name: Michael Chen Submitter email address: cchen@erilab.com Date first submitted: 19-Nov-01 Reference: Document: base-08 Comment type: E Priority: 1 Section: Base: 8.3.1 8.3.2 10.1 Rationale/Explanation of issue: User-Name avp should be option is the RAR and RAA message There is typepo in the RAA which shows "RAR" in the ABNF Requested change: 1. change User-Name Avp as option in the ABNF of RAR and RAA 2. change the RAR typepo to RAA 3. change the comand avp table according to this issue From owner-aaa-wg@merit.edu Tue Feb 26 15:47:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20864 for ; Tue, 26 Feb 2002 15:47:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9405D91299; Tue, 26 Feb 2002 15:45:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 598FD9129C; Tue, 26 Feb 2002 15:45:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8BCC91299 for ; Tue, 26 Feb 2002 15:45:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C44125DDBB; Tue, 26 Feb 2002 15:45:38 -0500 (EST) 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 1FB985DDA1 for ; Tue, 26 Feb 2002 15:45:38 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKj5322481 for ; Tue, 26 Feb 2002 22:45:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:37 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 247: Inconsistencies between the base and transport drafts CLOSED Date: Tue, 26 Feb 2002 22:45:37 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA1@esebe004.NOE.Nokia.com> Thread-Topic: Issue 247: Inconsistencies between the base and transport drafts CLOSED Thread-Index: AcG+/vUpKIqdLBJwR1yecvLn6rT7Iw== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:37.0034 (UTC) FILETIME=[8B44DEA0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20864 Hi all, I have made the changes listed in this issue. In order not to have inconsistencies in the specs, it makes sense just to reference the Transport document. I have left the defination of Tc in the document, as it is used in the document. br, John Issue 247: Inconsistencies between the base and transport drafts Submitter name: Jonathan Wood Submitter email address: jonathan.wood@sun.com Date first submitted: 21-Nov-01 Reference: Document: base Comment type: E Priority: 1 Section: Base (version 8 alpha2), sections 5.6, 5.6.2, and 12 Rationale/Explanation of issue: The transport draft and the base spec are in conflict about sending watchdogs. The state machine in the base spec section 5.6 requires that watchdogs be sent on each expiration of the watchdog timer. However, the transport draft requires that a watchdog be send once on the first expiration of the watchdog timer. On the next expiration of the watchdog timer, the connection is put in the suspect state, and the connection is failed over. Also, section 5.6 states When the state machine below requests a transport connection with the peer, the state machine in [52] is invoked. Once the connection has been established, the state machine in this section is followed. This is not completely accurate. The state machine in the transport draft should be followed throughout the life of the connection as well to manage the connection. There are also some leftover timer descriptions in section 12 that are no longer relevant. Requested change: I recommend that text specifying how to control sending watchdogs and management of the watchdog timer be stricken from the base spec, and that the base spec refer to the transport draft on this matter. Specifically: 5.6 Peer State Machine (Modify 2nd paragraph) This state machine is closely coupled with the state machine described in [52], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [52] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used. Remove from R-Open: WatchDog-Timer R-Snd-DWR R-Open Remove from I-Open: WatchDog-Timer I-Snd-DWR I-Open Remove from section 5.6.2 Events: WatchDog-Timer The Watchdog timer expired, indicating that a DWR message is to be sent to the peer. Rcv-DWR A DWR message was received. Rcv-DWA A DWA message was received. Section 12.0 Diameter protocol related configurable parameters Recommend removing the following timers: Td timer The Td timer controls the termination of connections with peer in the SUSPECT state. The recommended value is 5 seconds. Ti timer The Ti timer controls the frequency the watchdog messages are to be sent to idle peers. The recommended value is 30 seconds. Tr timer The Tr timer controls the frequency the watchdog messages are to be sent to peers when there are pending requests, but not messages have been received from the peer. The recommended value is 10 seconds. Tw timer The Tw timer controls the changing of a peer to the SUSPECT state when no answer is received to a watchdog request. The recommended value is 5 seconds. What about the Tc timer? From owner-aaa-wg@merit.edu Tue Feb 26 15:48:18 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20892 for ; Tue, 26 Feb 2002 15:48:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BB86291298; Tue, 26 Feb 2002 15:45:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EF149129C; Tue, 26 Feb 2002 15:45:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D11D91298 for ; Tue, 26 Feb 2002 15:45:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 31C3F5DDC1; Tue, 26 Feb 2002 15:45:37 -0500 (EST) 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 802365DDA1 for ; Tue, 26 Feb 2002 15:45:36 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKj3322474 for ; Tue, 26 Feb 2002 22:45:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Tue, 26 Feb 2002 22:45:33 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22A9F@esebe004.NOE.Nokia.com> Thread-Topic: Issue 244: ELECTION_LOST result code Thread-Index: AcG++4q/GztQ/Q9aRs6/Gwo2j6OT/g== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:33.0721 (UTC) FILETIME=[894B5890:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20892 This issue has been marked as a poosible reject. I agree & unless someone speaks up, I will mark this as a reject. John Issue 244: ELECTION_LOST result code Submitter name: Michael Chen Submitter email address: cchen@erilab.com Date first submitted: 19-Nov-01 Reference: Document: base-08 Comment type: E Priority: 1 Section: Base: 5.4.3 Rationale/Explanation of issue: DPR is not sent to its peer when lost the election so ELECTION_LOST result code is not used. Requested change: Remove this result code. From owner-aaa-wg@merit.edu Tue Feb 26 15:48:36 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20913 for ; Tue, 26 Feb 2002 15:48:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id ABBBB9129D; Tue, 26 Feb 2002 15:45:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4F99129C; Tue, 26 Feb 2002 15:45:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDA1B9129A for ; Tue, 26 Feb 2002 15:45:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1B4A5DDA1; Tue, 26 Feb 2002 15:45:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 094E75DDC1 for ; Tue, 26 Feb 2002 15:45:40 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKkBi13344 for ; Tue, 26 Feb 2002 22:46:11 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:38 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 248: Error messages: decimal or hex? CLOSED Date: Tue, 26 Feb 2002 22:45:38 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA2@esebe004.NOE.Nokia.com> Thread-Topic: Issue 248: Error messages: decimal or hex? CLOSED Thread-Index: AcG+/2OmO9Te8dugTXOPJA+jut+ZQQ== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:38.0982 (UTC) FILETIME=[8C6E1C60:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20913 Hi all, At this late point, I think that decimal is OK. These have been implemented and tested. I fear that changing this now will introduce confusion & editorial mishaps. John Issue 248: Error messages: decimal or hex? Submitter name: Bernard Aboba aboba@internaut.com Submitter email address: aboba@internaut.com Date first submitted: 28-Dec-01 Reference: Document: base 08 Comment type: Priority: 2 Section: 7.1 Rationale/Explanation of issue: Diameter distinguishes error classes according to the DECIMAL value of the Result-Code data field. This is widely used in protocols that utilize ASCII encoding (SMTP, HTTP, etc.). But it doesn't make much sense in a binary protocol such as Diameter. Shouldn't the HEX value of the Result-Code data field be used instead? For example: Is an Informational error message 1000 - 1999 in DECIMAL? Or is it 10000000 - 1FFFFFFF in HEX? From owner-aaa-wg@merit.edu Tue Feb 26 15:48:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20931 for ; Tue, 26 Feb 2002 15:48:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0730A9129F; Tue, 26 Feb 2002 15:45:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 36BE39129C; Tue, 26 Feb 2002 15:45:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C7BDE9129E for ; Tue, 26 Feb 2002 15:45:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id A714B5DDBB; Tue, 26 Feb 2002 15:45:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C65095DDA1 for ; Tue, 26 Feb 2002 15:45:42 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjpZ13203 for ; Tue, 26 Feb 2002 22:45:51 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:41 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 252: Granting Access via Accounting Date: Tue, 26 Feb 2002 22:45:41 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA4@esebe004.NOE.Nokia.com> Thread-Topic: Issue 252: Granting Access via Accounting Thread-Index: AcG/AMYDccMjoUyFSLqfA8aC3r9EWw== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:41.0823 (UTC) FILETIME=[8E1F9CF0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20931 Hi all, Just to be sure I've got it, should the following be removed from 8.2 Accounting Session State Machine. Pending Successful accounting grant Open start answer received access or ?? John Issue 252: Granting Access via Accounting Submitter name: Bernard Aboba aboba@internaut.com Submitter email address: aboba@internaut.com Date first submitted: 28-Dec-01 Reference: Document: base 08 Comment type: Technical Priority: S Section: 8.2 Rationale/Explanation of issue: Access is not granted based on receipt of a successful accounting start answer Change: In the state table on pp. 86, it states that in Pending state, receipt of a Successful accounting start answer results in "grant access" and movement to the Open state. Since access is granted within the authentication/authorization state machine, this appears to be an error. From owner-aaa-wg@merit.edu Tue Feb 26 15:49:06 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20966 for ; Tue, 26 Feb 2002 15:49:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 11572912A2; Tue, 26 Feb 2002 15:45:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAEBB9129E; Tue, 26 Feb 2002 15:45:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C25A9129F for ; Tue, 26 Feb 2002 15:45:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id EFC765DDC1; Tue, 26 Feb 2002 15:45:44 -0500 (EST) 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 49ABC5DDA1 for ; Tue, 26 Feb 2002 15:45:44 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjB322490 for ; Tue, 26 Feb 2002 22:45:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:43 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 256: TLS Usage Issues Date: Tue, 26 Feb 2002 22:45:43 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA5@esebe004.NOE.Nokia.com> Thread-Topic: Issue 256: TLS Usage Issues Thread-Index: AcG/ASdP/ZQ3uhZXQUa3wPShyyI7aA== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:43.0354 (UTC) FILETIME=[8F0939A0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20966 Hi all, The proposed text seems sensible. Unless there are objections, I shall add this. John Issue 256: TLS Usage Issues Submitter name: Bernard Aboba aboba@internaut.com Submitter email address: aboba@internaut.com Date first submitted: 28-Dec-01 Reference: Document: base 08 Comment type: Technical Priority: S Section: 2.2 Rationale/Explanation of issue: There is no discussion of how TLS authentication is used with Diameter. For example: a. Are both peers required to support certificates? b. If not, how is it decided which peer authenticates to who? Proposed change: Add: "Diameter clients act as TLS clients according to [RFC2246], and Diameter servers act as TLS servers. Diameter clients and servers implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, Diameter servers MUST request certificates from Diameter clients, and the client MUST be prepared to supply a certificate on request." From owner-aaa-wg@merit.edu Tue Feb 26 15:49:23 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20986 for ; Tue, 26 Feb 2002 15:49:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 76BAF912A0; Tue, 26 Feb 2002 15:45:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C1BF912A6; Tue, 26 Feb 2002 15:45:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C982912A0 for ; Tue, 26 Feb 2002 15:45:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 497685DDBB; Tue, 26 Feb 2002 15:45:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 68D855DDA1 for ; Tue, 26 Feb 2002 15:45:46 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjtZ13213 for ; Tue, 26 Feb 2002 22:45:55 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:45 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments Date: Tue, 26 Feb 2002 22:45:45 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA6@esebe004.NOE.Nokia.com> Thread-Topic: Issue 254: More details needed on Diameter IPsec usage - Need Comments Thread-Index: AcG/AYmpoxd/iwKgT+ySa9ZqNsngBQ== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:45.0448 (UTC) FILETIME=[9048BE80:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20986 Hello all, The proposed text seems to be adding additional requirements - we need to have some discussion on this before I can make a decision on whether to support this or not. John Issue 254: More details needed on Diameter IPsec usage Submitter name: Bernard Aboba aboba@internaut.com Submitter email address: aboba@internaut.com Date first submitted: 28-Dec-01 Reference: Document: base 08 Comment type: Technical Priority: S Section: 2.2 Rationale/Explanation of issue: The IPsec mode is not specified. IPsec is also mispelled (do a global replace of IPSec with IPsec). Add: "All Diameter implementations MUST support IPsec ESP [RFC2406] in transport mode with a non-null transform to provide per-packet authentication, integrity protection and confidentiality, and MUST support the replay protection mechanisms of IPsec. Diameter implemenations MUST support IKE for peer authentication, negotiation of security associations, and key management, using the IPsec DOI [RFC2407]. Manual keying MUST NOT be used since it does not provide the necessary rekeying support. Diameter implementations MUST support peer authentication using a pre-shared key, and MAY support certificate-based peer authentication using digital signatures. Peer authentication using the public key encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] SHOULD NOT be used. Conformant implementations MUST support both IKE Main Mode and Aggressive Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY be used. In all cases, access to locally stored secret information (pre-shared key, or private key for digital signing) must be suitably restricted, since compromise of the secret information nullifies the security properties of the IKE/IPsec protocols. When digital signatures are used to achieve authentication, an IKE negotiator SHOULD use IKE Certificate Request Payload(s) to specify the certificate authority (or authorities) that are trusted in accordance with its local policy. IKE negotiators SHOULD check the pertinent Certificate Revocation List (CRL) before accepting a PKI certificate for use in IKE's authentication procedures. The Phase 2 Quick Mode exchanges used to negotiate protection for Diameter connections MUST explicitly carry the Identity Payload fields (IDci and IDcr). The DOI provides for several types of identification data. However, when used in conformant implementations, each ID Payload MUST carry a single IP address and a single non-zero port number, and MUST NOT use the IP Subnet or IP Address Range formats. This allows the Phase 2 security association to correspond to specific TCP and SCTP connections. Since IPsec acceleration hardware may only be able to handle a limited number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent for idle SAs, as a means of keeping the number of active Phase 2 SAs to a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be interpreted as a reason for tearing down a Diameter connection. Rather, it is preferable to leave the connection up, and if additional traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. This avoids the potential for continually bringing connections up and down. If an IKE implementation receives a Phase 1 Delete message for a Phase 1 Security Association bound to one or more sessions, then it SHOULD delete the associated IKE Phase 2 security associations." From owner-aaa-wg@merit.edu Tue Feb 26 15:49:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20998 for ; Tue, 26 Feb 2002 15:49:30 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 20FF09129E; Tue, 26 Feb 2002 15:45:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD45E912A5; Tue, 26 Feb 2002 15:45:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48A3A912A1 for ; Tue, 26 Feb 2002 15:45:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1142F5DDBB; Tue, 26 Feb 2002 15:45:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 5463B5DDA1 for ; Tue, 26 Feb 2002 15:45:48 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKkKi13368 for ; Tue, 26 Feb 2002 22:46:20 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:47 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:47 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 257: peer connection inconsistent between base08 and transport05 Date: Tue, 26 Feb 2002 22:45:47 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA7@esebe004.NOE.Nokia.com> Thread-Topic: Issue 257: peer connection inconsistent between base08 and transport05 Thread-Index: AcG/Af4jFI45R/PnRbe4HMART+4GwA== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:47.0278 (UTC) FILETIME=[915FFAE0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA20998 Hi all, The text seems reasonable, but would referencing the transport document be cleaner? John Issue 257: peer connection inconsistent between base08 and transport05 Submitter name: yanqun le Submitter email address: yanqun.le@nokia.com Date first submitted: 30-Dec-01 Reference: Document: Base -08, dratf-ietf-aaa-transport-05 Comment type: Technical Priority: S Section: Section 5.1 of Base- 08, Section 3.4.1 of Transport -05 Rationale/Explanation of issue: The last third paragraphs in Section 5.1 is inconsistent with Section 3. 4.1 of transport-05. Requested change: The last third paragraphs in Section 5.1 should be changed to: When a peer is deemed suspect, which could occur for various reasons, including not receiving a DWA within an alloted timeframe, no new requests should be forwarded to the peer, and failover procedures should be invoked. When an active peer is moved to this mode, additional connections SHOULD be established to ensure that the necessary number of active connections exists. There are two ways that a peer is removed from the suspect peer list: 1. the peer's watchdog timer has expired without a response, causing a trasport reset or close to be done on the connection. 2. a response is received from the peer within the watchdog timer, and the connection to the peer is considered stabilized. In the event the peer being removed is either the primary or secondary, an alternate peer SHOULD replace the deleted peer, and assume the role of either primary or secondary. From owner-aaa-wg@merit.edu Tue Feb 26 15:49:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21022 for ; Tue, 26 Feb 2002 15:49:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4AE66912A4; Tue, 26 Feb 2002 15:46:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1CB74912A9; Tue, 26 Feb 2002 15:45:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D0C19129C for ; Tue, 26 Feb 2002 15:45:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEEFB5DDC1; Tue, 26 Feb 2002 15:45:53 -0500 (EST) 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 2C03E5DDA1 for ; Tue, 26 Feb 2002 15:45:53 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjK322529 for ; Tue, 26 Feb 2002 22:45:20 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:52 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 261: Peer discovery mechanism requirements CLOSED Date: Tue, 26 Feb 2002 22:45:52 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AAA@esebe004.NOE.Nokia.com> Thread-Topic: Issue 261: Peer discovery mechanism requirements CLOSED Thread-Index: AcG/AtImOPPo6fckT6yI8GZZYrB55w== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:52.0166 (UTC) FILETIME=[9449D460:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21022 Hi all, Text accepted & modified accordingly. John Issue 261: Peer discovery mechanism requirements Submitter email address: jari@arkko.com Date first submitted: 02-Jan-02 Reference: Document: Base 08 Comment type: Technical Priority: S Section: 5.2 Rationale/Explanation of issue: Current text does not clearly enough specify which peer discovery mechanisms are mandatory and which are not. There's two approaches to handling this issue. One, (apparently the current approach) we stay clear of using MUST/SHOULD/MAY in section 5.2 and therefore all of the text falls to Informative, and nothing is really mandated. The second approach is that we explicitly state what DIAMETER nodes MUST/SHOULD/MAY be capable of in this area. I favor the latter approach. Proposed change: Indicate in the list under 5.2 that the first option (manual configuration) MUST be supported by all DIAMETER nodes, while the latter two options (SRVLOC and DNS SRV records) MAY be supported. From owner-aaa-wg@merit.edu Tue Feb 26 15:50:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21044 for ; Tue, 26 Feb 2002 15:50:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 89CF0912A9; Tue, 26 Feb 2002 15:47:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA33F912A8; Tue, 26 Feb 2002 15:45:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 845F5912A4 for ; Tue, 26 Feb 2002 15:45:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5AFBB5DDBB; Tue, 26 Feb 2002 15:45:52 -0500 (EST) 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 A4AAD5DDA1 for ; Tue, 26 Feb 2002 15:45:51 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjJ322524 for ; Tue, 26 Feb 2002 22:45:19 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:50 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 260: SNTP referencing CLOSED Date: Tue, 26 Feb 2002 22:45:50 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA9@esebe004.NOE.Nokia.com> Thread-Topic: Issue 260: SNTP referencing CLOSED Thread-Index: AcG/AlJQ1atx3hJ8R/21RzlgIu3h9g== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:50.0549 (UTC) FILETIME=[93531850:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21044 Hi all, Text accepted and added to the base spec. John Issue 260: SNTP referencing Submitter name: Jari Arkko Submitter email address: jari@arkko.com Date first submitted: 02-Jan-02 Reference: Document: Base 08 Comment type: Technical Priority: S Section: Rationale/Explanation of issue: Current text reads as follows: The Time format is derived from the Unsigned32 AVP Base Format. This is 32 bit unsigned value containing the four most significant octets returned from NTP [18], in network byte order. This represent the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. NTP [18] describes a procedure to extend the time to 2104. This has two problems. First, it is unclear whether NTP or SNTP is meant and what format is really used. Second, we don't mandate the extension to year 2104. Also, I find it easier to explain the format issue if Time is derived from OctetString, not Unsigned32. Bits on the wire are not changed. Proposed change: The Time format is derived from the OctetString AVP Base Format. The string MUST contain four octets, in the same format as the four first bytes are in the NTP Timestamp Format. The NTP Timestamp format is defined in Chapter 3 of reference [18]. This represents the number of seconds since 0h on 1 January 1900 with respect to the Coordinated Universal Time (UTC). On 6h 28m 16s UTC, 7 February 2036 the time value will overflow. SNTP [18] describes a procedure to extend the time to 2104. This procedure MUST be used by all DIAMETER nodes. From owner-aaa-wg@merit.edu Tue Feb 26 15:50:13 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21069 for ; Tue, 26 Feb 2002 15:50:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6BEA69129C; Tue, 26 Feb 2002 15:45:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B926D912A1; Tue, 26 Feb 2002 15:45:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F806912A3 for ; Tue, 26 Feb 2002 15:45:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C3E55DDBB; Tue, 26 Feb 2002 15:45:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 2FA9A5DDA1 for ; Tue, 26 Feb 2002 15:45:50 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKkLi13381 for ; Tue, 26 Feb 2002 22:46:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 259: Qualifier of Vendor-Specific-Application-Id in CEA CLOSED Date: Tue, 26 Feb 2002 22:45:48 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA8@esebe004.NOE.Nokia.com> Thread-Topic: Issue 259: Qualifier of Vendor-Specific-Application-Id in CEA CLOSED Thread-Index: AcG/Ai+Asn94+/cjTSSez/BdWe9iwQ== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:49.0135 (UTC) FILETIME=[927B55F0:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21069 Hi all, Correction accepted, text modified in base spec. John Issue 259: Qualifier of Vendor-Specific-Application-Id in CEA Submitter name: Miguel-Angel Pallares Submitter email address: miguel-angel.pallares-lopez@ece.ericsson.se Date first submitted: 02-Jan-02 Reference: Document: Base 08 Comment type: Editorial Priority: 1 Section: 5.3.2 Rationale/Explanation of issue: The qualifier for Vendor-Specific-Application-Id AVP in CEA should be "*", as in CER. Change in definition of CEA in 5.3.2, from: [ Vendor-Specific-Application-Id ] to: * [ Vendor-Specific-Application-Id ] From owner-aaa-wg@merit.edu Tue Feb 26 15:50:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21088 for ; Tue, 26 Feb 2002 15:50:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 96861912A8; Tue, 26 Feb 2002 15:47:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B34FB912A5; Tue, 26 Feb 2002 15:46:01 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10286912A3 for ; Tue, 26 Feb 2002 15:45:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3E325DDC1; Tue, 26 Feb 2002 15:45:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 089BA5DDBB for ; Tue, 26 Feb 2002 15:45:55 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKk3Z13255 for ; Tue, 26 Feb 2002 22:46:03 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 26 Feb 2002 22:45:54 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issues 262 & 263: A Diameter node must use its own TLS certificate Issue 263: Mandate required TLS cipher suites Date: Tue, 26 Feb 2002 22:45:53 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AAB@esebe004.NOE.Nokia.com> Thread-Topic: Issues 262 & 263: A Diameter node must use its own TLS certificate Issue 263: Mandate required TLS cipher suites Thread-Index: AcG/AyI/NEOd/wgoTSiAQRQHCkbrmQ== From: To: X-OriginalArrivalTime: 26 Feb 2002 20:45:53.0892 (UTC) FILETIME=[95513240:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21088 Hi all, These seem like reasonable requests, however I'd like some feedback from the security experts on the list before I make the changes. John Issue 262: A Diameter node must use its own TLS certificate Submitter name: Don Zick Submitter email address: Date first submitted: 08-Jan-02 Reference: Document: Base 08 Comment type: Technical Priority: 1 Section: 2.2 Rationale/Explanation of issue: The Diameter base draft does not address how to ensure that a Diameter node is using its own TLS certificate. It is important to ensure that a Diameter node is using its own TLS certificate so that if a single Diameter node becomes compromised, it won't break security for all of the other Diameter nodes. It is a common practice with TLS to put a node's identity into the certificate's subjectAltName dNSName field. The Diameter CMS Security Application takes this approach. Below is a section from the Diameter CMS Security Application draft 3: >3.2 Certificate Requirements > > Certificates used for the purposes of Diameter MUST conform to the > PKIX profile [4], and MUST also include a Diameter node's FQDN, which > is typically added in the Origin-Host AVP [1], as one of the values > of the subjectAltName extension of the Certificate. The FQDN is to > be encoded as a dNSName within the subjectAltName. > > For Diameter nodes (capable of acting as recipients for > confidentiality), the FQDN MUST be of the form > "Diameter-.". Other Diameter nodes MAY use this naming > scheme. Note that this naming constraint is for PKI purposes only, > and in no way restricts a Diameter's host name. Requested change: Make Diameter TLS have the same dNSName field requirements as the Diameter CMS Security Application. Issue 263: Mandate required TLS cipher suites Submitter name: Don Zick Submitter email address: Date first submitted: 08-Jan-02 Reference: Document: Base 08 Comment type: Technical Priority: S Section: 2.2 Rationale/Explanation of issue: Diameter implementations should not be required to support all TLS cipher suites listed in RFC 2246. Not all cipher suites are supported by available TLS tool kits and one cipher suite contains the proprietary IDEA encryption algorithm that you have to get permission to use. Therefore, to ensure inter operability, it is necessary to specify which cipher suites must be supported. Requested change: Add: Diameter nodes MUST be able to negotiate the following TLS cipher suites: TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA Diameter nodes MAY negotiate other TLS cipher suites. From owner-aaa-wg@merit.edu Tue Feb 26 15:50:46 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21106 for ; Tue, 26 Feb 2002 15:50:46 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D11D3912B9; Tue, 26 Feb 2002 15:47:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D729F912AA; Tue, 26 Feb 2002 15:46:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83301912A7 for ; Tue, 26 Feb 2002 15:45:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id C299E5DDC1; Tue, 26 Feb 2002 15:45:57 -0500 (EST) 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 DACAA5DDBB for ; Tue, 26 Feb 2002 15:45:56 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKjN322538 for ; Tue, 26 Feb 2002 22:45:24 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 22:45:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 26 Feb 2002 22:45:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Tue, 26 Feb 2002 22:45:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AAC@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG+18DDemrvf07aS/u+5R1EVNbQKwAK3vsQ From: To: , X-OriginalArrivalTime: 26 Feb 2002 20:45:55.0682 (UTC) FILETIME=[96625420:01C1BF06] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21106 Hi David, > Wow! This is a big change and I don't understand where this > might lead well enough to know how it impacts my issue. This I think we need to sort out. Essentially, section 5.2 needs updating with regards to SRV records. Actually, I am wondering if the DiameterIdentity needs to be directly modified for this or not. John > So as you deal with your changes > regarding how server discovery works, keep in mind the AVPs of type > DiameterIndentity which are used for message routing and make > sure their > requirements are met, to wit: > > 1) A value of type DiameterIdentity must uniquely identify a > "Diameter node", which is an instance of a Diameter process running on an IP > host. > > 2) There may be more than one "Diameter node" running on the same host > and sharing the same IP address. > > 3) It must be possible to express a value of type > DiameterIdentity in a > canonical form so that each "Diameter node" will only have a single > identifier in a domain. Thus the type must not contain > any parameters > that are specific to a particular peer-to-peer connection. > > john.loughney@nokia.com wrote: > > > > Hi all, > > > > I noticed that my example wasn't exactly correct, here is > an update version: > > > > === updated example ==== > > > > As an example, consider a client that wishes to resolve > > aaa:example.com. The client performs a NAPTR query for that > > domain, and the following NAPTR records are returned: > > > > ;; order pref flags service regexp > replacement > > IN NAPTR 50 50 "s" "AAA+D2S" "" > _aaa._sctp.example.com. > > IN NAPTR 90 50 "s" "AAAS+D2T" "" > _aaas._tcp.example.com. > > IN NAPTR 100 50 "s" "AAA+D2T" "" > _aaa._tcp.example.com > > > > This indicates that the server supports SCTP, TLS over > TCP, and TCP, > > in that order. Since the client supports SCTP, SCTP will be > > used, targeted to a host determined by an SRV lookup of > > _aaa._sctp.example.com. That lookup would return: > > > > ;; Priority Weight Port Target > > IN SRV 0 1 xxxx server1.example.com > > IN SRV 0 2 xxxx server2.example.com > > ;; where xxxx is replaced by the well-known port > for Diameter > > > > John > From owner-aaa-wg@merit.edu Tue Feb 26 15:51:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21124 for ; Tue, 26 Feb 2002 15:51:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5ECEC91349; Tue, 26 Feb 2002 15:49:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 301D291345; Tue, 26 Feb 2002 15:49:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C83A9133D for ; Tue, 26 Feb 2002 15:49:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 129115DDBB; Tue, 26 Feb 2002 15:49:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 89A625DDA1 for ; Tue, 26 Feb 2002 15:49:13 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1QKpHx11321 for ; Tue, 26 Feb 2002 14:51:17 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 26 Feb 2002 14:49:12 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 26 Feb 2002 14:49:10 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 26 Feb 2002 14:49:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12832@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG+7B/I02AISr1yQBqnDlY1WEBvFQAGuFLA From: To: , , X-OriginalArrivalTime: 26 Feb 2002 20:49:10.0808 (UTC) FILETIME=[0AB03180:01C1BF07] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA21124 Jari Arkko [jari.arkko@kolumbus.fi] wrote: >Barney Wolff [barney@databus.com] wrote: > >>The D-bit is an optimization, so we are entitled to assume that another >>optimization, namely using User-Name as a primary search key, is also >>taken. But the User-Name does not necessarily indicate that it is a possible duplicate. >>In that case, the two searches are likely to take the same time. > >I think one of the central question to answer is why the User-Name >optimization is not sufficient. Basavaraj, can you comment on that? Simply because the "D" bit based optimization mechanism is a significant improvement in terms of performance. And by this I am refering to the number of records that need to be checked. So if a server needs to determine duplicates (outside the premises of post-processing methods), having the "D" bit would make this processing more optimal. > >Jari -Basavaraj From owner-aaa-wg@merit.edu Tue Feb 26 15:54:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21257 for ; Tue, 26 Feb 2002 15:54:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7D7F39129A; Tue, 26 Feb 2002 15:54:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51263912A1; Tue, 26 Feb 2002 15:54:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5F93E9129A for ; Tue, 26 Feb 2002 15:54:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44D885DDC1; Tue, 26 Feb 2002 15:54:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 307015DDA1 for ; Tue, 26 Feb 2002 15:54:25 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E5B577A for ; Tue, 26 Feb 2002 15:54:24 -0500 (EST) Message-ID: <3C7BF606.D063BEDF@Interlinknetworks.com> Date: Tue, 26 Feb 2002 15:54:30 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Remove references to CMS-Cert in cms-sec-03 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Remove references to CMS-Cert in cms-sec-03 Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: February 26, 2002 Reference: Document: cms-sec Comment type: E Priority: S Section: many Rationale/Explanation of issue: Cms-sec-02 defined an AVP called CMS-Cert. This AVP was removed in cms-sec-03, however many references to it remain. Requested change: Remove all references to the CMS-Cert AVP. From owner-aaa-wg@merit.edu Tue Feb 26 16:11:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21807 for ; Tue, 26 Feb 2002 16:11:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F3C75912A1; Tue, 26 Feb 2002 16:11:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C15EB912A3; Tue, 26 Feb 2002 16:11:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D1D20912A1 for ; Tue, 26 Feb 2002 16:11:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id A96095DDC9; Tue, 26 Feb 2002 16:11:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 937E05DDA1 for ; Tue, 26 Feb 2002 16:11:15 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 4C19B7A; Tue, 26 Feb 2002 16:11:15 -0500 (EST) Message-ID: <3C7BF9F8.3678C21@Interlinknetworks.com> Date: Tue, 26 Feb 2002 16:11:20 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: stephen.farrell@baltimore.ie, IETF AAA List Subject: Re: [AAA-WG]: Additional cms issues References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> Content-Type: multipart/mixed; boundary="------------1B4AC5661B82950EA8E75F2D" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------1B4AC5661B82950EA8E75F2D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote: >... > > s/OctetString/Grouped/g > > Yes. >... No! For reasons I explained privately to Stephen, Octet String is correct; Grouped is incorrect. From original message: >... > Submitter name: Stephen Farrell > Submitter email address: stephen.farrell@baltimore.ie > Date first submitted: 2002-02-26 > Reference: > Document: cms > Comment type: T > Priority: S > Section: 6.0, 6.2 > > Rationale/Explanation of issue: > > CMS-Encrypted-Data can be multivalued, so OctetString is > the wrong type for this AVP. > > Requested changes: > > s/OctetString/Grouped/g >... --------------1B4AC5661B82950EA8E75F2D Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------1B4AC5661B82950EA8E75F2D-- From owner-aaa-wg@merit.edu Tue Feb 26 16:17:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21935 for ; Tue, 26 Feb 2002 16:17:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 918F4912A3; Tue, 26 Feb 2002 16:17:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 590EB912A5; Tue, 26 Feb 2002 16:17:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0604A912A3 for ; Tue, 26 Feb 2002 16:17:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF03D5DDC9; Tue, 26 Feb 2002 16:17:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 94E8A5DDA1 for ; Tue, 26 Feb 2002 16:17:27 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1QLFiD01130; Tue, 26 Feb 2002 16:15:44 -0500 Message-ID: <3C7BFB00.E94C8334@interlinknetworks.com> Date: Tue, 26 Feb 2002 16:15:44 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 256: TLS Usage Issues References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA5@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA21935 The proposed text states that Diameter Clients act as TLS clients and that Diameter Servers act as TLS servers. I don't think this is quite right. I think the connection initiator acts as the TLS client and the connection acceptor acts as the TLS server. When two Diameter servers connect, the Diameter server that initiates the connection acts as the TLS client. If a Diameter client accepts a connetion from a Diameter server then I think the Diameter client should act as the TLS server. I think the connection initiator should be responsible for initiating TLS negotiations just as it is responsible for sending the initial CER message. Don Z. john.loughney@nokia.com wrote: > Hi all, > > The proposed text seems sensible. Unless there are objections, I > shall add this. > > John > > Issue 256: TLS Usage Issues > Submitter name: Bernard Aboba aboba@internaut.com > Submitter email address: aboba@internaut.com > Date first submitted: 28-Dec-01 > Reference: > Document: base 08 > Comment type: Technical > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > There is no discussion of how TLS authentication is used with > Diameter. For example: > > a. Are both peers required to support certificates? > b. If not, how is it decided which peer authenticates to who? > > Proposed change: > > Add: > > "Diameter clients act as TLS clients according to [RFC2246], and Diameter > servers act as TLS servers. Diameter clients and servers implementing > TLS for security MUST mutually authenticate as part of TLS session > establishment. In order to ensure mutual authentication, Diameter servers > MUST request certificates from Diameter clients, and the client MUST be > prepared to supply a certificate on request." From owner-aaa-wg@merit.edu Tue Feb 26 16:20:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22009 for ; Tue, 26 Feb 2002 16:20:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AD515912A5; Tue, 26 Feb 2002 16:20:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AE81912A6; Tue, 26 Feb 2002 16:20:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 87519912A5 for ; Tue, 26 Feb 2002 16:20:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68F965DDC9; Tue, 26 Feb 2002 16:20:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 4FD0A5DDA1 for ; Tue, 26 Feb 2002 16:20:01 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1QLIRD01134; Tue, 26 Feb 2002 16:18:27 -0500 Message-ID: <3C7BFBA3.E447AEC2@interlinknetworks.com> Date: Tue, 26 Feb 2002 16:18:27 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22A9F@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA22009 I don't understand why this is being rejected. Is the ELECTION_LOST result code used anymore? Don Z. john.loughney@nokia.com wrote: > This issue has been marked as a poosible reject. I agree & unless > someone speaks up, I will mark this as a reject. > > John > > Issue 244: ELECTION_LOST result code > Submitter name: Michael Chen > Submitter email address: cchen@erilab.com > Date first submitted: 19-Nov-01 > Reference: > Document: base-08 > Comment type: E > Priority: 1 > Section: Base: 5.4.3 > > Rationale/Explanation of issue: > DPR is not sent to its peer when lost the election so ELECTION_LOST > result code is not used. > > Requested change: > Remove this result code. From owner-aaa-wg@merit.edu Tue Feb 26 16:44:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22697 for ; Tue, 26 Feb 2002 16:44:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3B510912A6; Tue, 26 Feb 2002 16:43:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06E03912A7; Tue, 26 Feb 2002 16:43:50 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF0EF912A6 for ; Tue, 26 Feb 2002 16:43:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id C30DD5DDCC; Tue, 26 Feb 2002 16:43:49 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 706E15DDC9 for ; Tue, 26 Feb 2002 16:43:49 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1QLfWD01146; Tue, 26 Feb 2002 16:41:32 -0500 Message-ID: <3C7C010C.255E909C@interlinknetworks.com> Date: Tue, 26 Feb 2002 16:41:32 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA6@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id QAA22697 I don't understand why we care about specifying IPsec usage details. My understanding is that the Diameter server itself need not even know that IP sec is in use. Is this correct? If so, it would seem to me that the details of how an administrator configures IPsec in a network need not be mandated in the Diameter drafts. Thanks, Don john.loughney@nokia.com wrote: > Hello all, > > The proposed text seems to be adding additional requirements - > we need to have some discussion on this before I can > make a decision on whether to support this or not. > > John > > Issue 254: More details needed on Diameter IPsec usage > Submitter name: Bernard Aboba aboba@internaut.com > Submitter email address: aboba@internaut.com > Date first submitted: 28-Dec-01 > Reference: > Document: base 08 > Comment type: Technical > Priority: S > Section: 2.2 > Rationale/Explanation of issue: > The IPsec mode is not specified. IPsec is also mispelled (do a global > replace of IPSec with IPsec). > > Add: > > "All Diameter implementations MUST support IPsec ESP [RFC2406] in transport > mode with a non-null transform to provide per-packet authentication, > integrity protection and confidentiality, and MUST > support the replay protection mechanisms of IPsec. > > Diameter implemenations MUST support IKE for peer authentication, > negotiation of security associations, and key management, using the > IPsec DOI [RFC2407]. Manual keying MUST NOT > be used since it does not provide the necessary rekeying support. > Diameter implementations MUST support peer authentication using a > pre-shared key, and MAY support certificate-based peer authentication > using digital signatures. Peer authentication using the public key > encryption methods outlined in IKE's sections 5.2 and 5.3 [RFC2409] > SHOULD NOT be used. > > Conformant implementations MUST support both IKE Main Mode and Aggressive > Mode. When pre-shared keys are used for authentication, IKE Aggressive Mode > SHOULD be used, and IKE Main Mode SHOULD NOT be used. When digital signatures > are used for authentication, either IKE Main Mode or IKE Aggressive Mode MAY > be used. In all cases, access to locally stored secret information > (pre-shared key, or private key for digital signing) must be suitably restricted, > since compromise of the secret information nullifies the security properties of > the IKE/IPsec protocols. > > When digital signatures are used to achieve authentication, an IKE > negotiator SHOULD use IKE Certificate Request Payload(s) to specify the > certificate authority (or authorities) that are trusted in accordance > with its local policy. IKE negotiators SHOULD check the pertinent > Certificate Revocation List (CRL) before accepting a PKI certificate for > use in IKE's authentication procedures. > > The Phase 2 Quick Mode exchanges used to negotiate protection for > Diameter connections MUST explicitly carry > the Identity Payload fields (IDci and IDcr). The DOI provides for > several types of identification data. However, when used in conformant > implementations, each ID Payload MUST carry a > single IP address and a single non-zero port number, and MUST NOT use > the IP Subnet or IP Address Range formats. This allows the Phase 2 > security association to correspond to specific TCP and SCTP > connections. > > Since IPsec acceleration hardware may only be able to handle a limited > number of active IKE Phase 2 SAs, Phase 2 delete messages may be sent > for idle SAs, as a means of keeping the number of active Phase 2 SAs to > a minimum. The receipt of an IKE Phase 2 delete message SHOULD NOT be > interpreted as a reason for tearing down a Diameter connection. > Rather, it is preferable to leave the connection up, and if additional > traffic is sent on it, to bring up another IKE Phase 2 SA to protect it. > This avoids the potential for continually bringing connections up and > down. > > If an IKE implementation receives a Phase 1 Delete message for a Phase 1 > Security Association bound to one or more sessions, then it SHOULD > delete the associated IKE Phase 2 security associations." From owner-aaa-wg@merit.edu Tue Feb 26 16:58:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23020 for ; Tue, 26 Feb 2002 16:58:22 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C0A02912AA; Tue, 26 Feb 2002 16:58:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 903FE912AB; Tue, 26 Feb 2002 16:58:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72057912AA for ; Tue, 26 Feb 2002 16:58:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 483A75DDDD; Tue, 26 Feb 2002 16:57:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A55595DDCA for ; Tue, 26 Feb 2002 16:57:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1QLHQF12675; Tue, 26 Feb 2002 13:17:27 -0800 Date: Tue, 26 Feb 2002 13:17:26 -0800 (PST) From: Bernard Aboba To: Don Zick Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments In-Reply-To: <3C7C010C.255E909C@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I don't understand why we care about specifying IPsec usage details. My > understanding is that the Diameter server itself need not even know that IP sec is > in use. Is this correct? If so, it would seem to me that the details of how an > administrator configures IPsec in a network need not be mandated in the Diameter > drafts. > > Thanks, > Don The problem is that without *some* guidelines interoperability can be tricky. Surely we must have some idea of how IPsec would be used with Diameter, right? Why not spell this out explicitly? For example, implementations MUST USE encryption, since otherwise we have no hiding capabilities. Transport mode ESP with non-null transform seems like a reasonable way to go. In terms of transforms, 3DES seems like a reasonable thing to implement at least. Remember, DES is still mandatory within IPsec, but will soon be deprecated. Diameter clients and servers are likely to have fixed IP addresses, but where they don't, then a warning is appropriate against use of pre-shared keys with Main Mode, since this requires group secrets. From owner-aaa-wg@merit.edu Tue Feb 26 17:02:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23098 for ; Tue, 26 Feb 2002 17:02:01 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BD5A3912AD; Tue, 26 Feb 2002 17:01:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16035912AC; Tue, 26 Feb 2002 17:01:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95D4B912AB for ; Tue, 26 Feb 2002 17:01:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 410E35DDB1; Tue, 26 Feb 2002 17:01:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id 714905DDC3 for ; Tue, 26 Feb 2002 17:01:47 -0500 (EST) Received: (qmail 10238 invoked by uid 500); 26 Feb 2002 22:01:40 -0000 Date: Tue, 26 Feb 2002 16:01:40 -0600 From: David Frascone To: Bernard Aboba Cc: Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments Message-ID: <20020226220140.GG8806@newman.frascone.com> Mail-Followup-To: Bernard Aboba , Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu References: <3C7C010C.255E909C@interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk My vote is to leave the details *out* of the draft. On Tuesday, 26 Feb 2002, Bernard Aboba wrote: > > I don't understand why we care about specifying IPsec usage details. My > > understanding is that the Diameter server itself need not even know that IP sec is > > in use. Is this correct? If so, it would seem to me that the details of how an > > administrator configures IPsec in a network need not be mandated in the Diameter > > drafts. > > > > Thanks, > > Don > > The problem is that without *some* guidelines interoperability can be > tricky. Surely we must have some idea of how IPsec would be used with > Diameter, right? Why not spell this out explicitly? > > For example, implementations MUST USE encryption, since otherwise we > have no hiding capabilities. Transport mode ESP with non-null transform > seems like a reasonable way to go. In terms of transforms, 3DES seems like > a reasonable thing to implement at least. Remember, DES is still mandatory > within IPsec, but will soon be deprecated. > > Diameter clients and servers are likely to have fixed IP addresses, but > where they don't, then a warning is appropriate against use of pre-shared > keys with Main Mode, since this requires group secrets. > > > -- David Frascone If wishes were horses, dogfood would be a lot cheaper. From owner-aaa-wg@merit.edu Tue Feb 26 17:06:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23186 for ; Tue, 26 Feb 2002 17:06:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF8569120C; Tue, 26 Feb 2002 17:05:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5931E912AB; Tue, 26 Feb 2002 17:05:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 181B49120C for ; Tue, 26 Feb 2002 17:05:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAB7C5DDC3; Tue, 26 Feb 2002 17:05:50 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 839625DDB1 for ; Tue, 26 Feb 2002 17:05:50 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1QM5nh27578; Tue, 26 Feb 2002 16:05:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1QM5mW02581; Tue, 26 Feb 2002 16:05:49 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA17317; Tue, 26 Feb 2002 16:05:47 -0600 (CST) Received: from ericberk107 (letmein2-025.exu.ericsson.se [138.85.130.25]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with SMTP id QAA29659; Tue, 26 Feb 2002 16:05:46 -0600 (CST) Message-ID: <009101c1bf11$be7a2630$6400a8c0@ew.us.am.ericsson.se> From: "Kevin Purser" To: "Don Zick" , , References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22A9F@esebe004.NOE.Nokia.com> <3C7BFBA3.E447AEC2@interlinknetworks.com> Subject: Re: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Tue, 26 Feb 2002 14:05:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I don't understand why this is being rejected. Is the ELECTION_LOST > result code used anymore? Agreed. If memory serves, originally when a peer lost an election, it would send a CEA with a result code indicating success and then immediately send a DPR with a Disconnect-Cause indicating ELECTION_LOST. As a result of the last interop event, it was decided it would be better to just send a CEA with the ELECTION_LOST result code. Thus, the idea with this issue was to simply move this result code from the enumerated Disconnect-Cause AVP into the Result-Code AVP. -Kev > > Don Z. > > john.loughney@nokia.com wrote: > > > This issue has been marked as a poosible reject. I agree & unless > > someone speaks up, I will mark this as a reject. > > > > John > > > > Issue 244: ELECTION_LOST result code > > Submitter name: Michael Chen > > Submitter email address: cchen@erilab.com > > Date first submitted: 19-Nov-01 > > Reference: > > Document: base-08 > > Comment type: E > > Priority: 1 > > Section: Base: 5.4.3 > > > > Rationale/Explanation of issue: > > DPR is not sent to its peer when lost the election so ELECTION_LOST > > result code is not used. > > > > Requested change: > > Remove this result code. > From owner-aaa-wg@merit.edu Tue Feb 26 17:25:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23505 for ; Tue, 26 Feb 2002 17:25:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 06EB3912AB; Tue, 26 Feb 2002 17:25:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CAA34912AC; Tue, 26 Feb 2002 17:25:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C2C17912AB for ; Tue, 26 Feb 2002 17:25:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2FFF5DDC3; Tue, 26 Feb 2002 17:25:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 636D25DDA1 for ; Tue, 26 Feb 2002 17:25:04 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 093A97A; Tue, 26 Feb 2002 17:25:03 -0500 (EST) Message-ID: <3C7C0B44.D81952D0@Interlinknetworks.com> Date: Tue, 26 Feb 2002 17:25:08 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: [Issue] Routing of session messages defined in base References: <3C7BB9D2.3000104@ipunplugged.com> Content-Type: multipart/mixed; boundary="------------87FDAC3E2C8F7C7CBA292D43" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------87FDAC3E2C8F7C7CBA292D43 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think I agree that Auth-Application-Id should be present in these messages assuming it is known. It could help in the routing. One reason that these messages may not have included the Auth-Application-Id AVP is that it was thought that this AVP would most likely be used at the last hop, and the messages under discussion here would usually contain a Destination-Host AVP to be used at the last hop instead. However, the presence of the Destination-Host AVP does not help in Johan's scenario: > S----------------X------------X------------N > | > +------------X------------M This scenario might describe a roaming broker (running the Xs) who deploys separate proxy agents for different applications. Johan Johansson wrote: > > Yes, the issue has been cloned. Sorry about that. I even looked at the > issues list first but I guess I wasn't paying attention closely enough. > Nice to see that we are suggesting the same resolution at least. > > j > > Bob Kopacz wrote: > > >Hi Johan, > > > >I think your issue is very similar to an existing one: > > > >>-----Original Message----- > >> > >From: Bob Kopacz [BKopacz@InterlinkNetworks.com] > >Sent: Friday, January 25, 2002 2:49 PM > >To: aaa-wg > >Subject: [AAA-WG]: [issue] Proxiable messages MUST contain Axxx-Application-Id > >AVP > > > >Issue : Proxiable messages MUST contain Axxx-Application-Id AVP > >Submitter name: Bob Kopacz > >Submitter email address: BKopacz@InterlinkNetworks.com > >Date first submitted: 01-25-2002 > >Reference: > >Document: Base > >Comment type: Technical > >Priority: 1 > >Section: > > > > [I know last-call is over, but pending issues haven't been resolved > > yet, and I think this is a bug]. > > > >Rationale/Explanation of issue: > > > > Accounting messages and application-specific messages have an > > Axxx-Application-Id AVP which identifies the application (e.g. > > Mobile IP). > > > > The Auth-Application-Id AVP is currently prohibited from being present > > in the Session-Terminate-Request, Abort-Session-Request, and > > Re-Auth-Request messages. > > > > This creates a routing problem for intermediate proxy or relay servers > > when receiving an STR/ASR/RAR. The intermediate server's routing > > table may indicate that, say, Mobile-IP messages route to a different > > next hop than NASREQ messages. An STR message, however, contains no > > application-id AVP indicating NASREQ-v-MobileIp, so the intermediate > > server doesn't know how to route it. > > > > > >Requested change: > > > > 1. Require an Auth-Application-Id AVP in Session-Terminate-Request, > > Abort-Session-Request, and Re-Auth-Request messages. > > > > 2. Update occurrence rule tables for the "Auth-Application-Id AVP" > > row, from "0" to "1", for STR and ASR and RAR. > > --------------87FDAC3E2C8F7C7CBA292D43 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------87FDAC3E2C8F7C7CBA292D43-- From owner-aaa-wg@merit.edu Tue Feb 26 18:01:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24283 for ; Tue, 26 Feb 2002 18:01:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 717DE912AC; Tue, 26 Feb 2002 18:00:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45437912AE; Tue, 26 Feb 2002 18:00:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35202912AC for ; Tue, 26 Feb 2002 18:00:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 106BB5DDCA; Tue, 26 Feb 2002 18:00:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C182C5DDA1 for ; Tue, 26 Feb 2002 18:00:30 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5C7BD7A; Tue, 26 Feb 2002 18:00:30 -0500 (EST) Message-ID: <3C7C1393.4B1EC393@Interlinknetworks.com> Date: Tue, 26 Feb 2002 18:00:35 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: Bernard Aboba , Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments References: <3C7C010C.255E909C@interlinknetworks.com> <20020226220140.GG8806@newman.frascone.com> Content-Type: multipart/mixed; boundary="------------ECBAF96607794886E91E651E" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------ECBAF96607794886E91E651E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit My question would be, Who do we expect to claim conformance to the Diameter standards? Certainly not the service providers. So specifying what a service provider MUST do to be in compliance seems out of place. Service providers would not even expect to read these standards. So if we are trying to reach the service providers we should write a BCP on Diameter security practices. It is the access device and server vendors who will claim conformance to the Diameter standards. For the access device vendors, perhaps including this material is relevant. It seems irrelevant, however, to server vendors unless the server has to actually do something in order to comply. So my question is, are we suggesting that a Diameter server should be able to originate an IKE exchange that would trigger establishment of an IPsec tunnel? If so, then we should describe what the real requirements are. Under what circumstances would the server take what action and what is the server required to do if the attempt fails and how does the server verify that the correct security is in place? Otherwise, we should put this material in a BCP rather than the Diameter standards themselves. David Frascone wrote: > > My vote is to leave the details *out* of the draft. > > On Tuesday, 26 Feb 2002, Bernard Aboba wrote: > > > I don't understand why we care about specifying IPsec usage details. My > > > understanding is that the Diameter server itself need not even know that IP sec is > > > in use. Is this correct? If so, it would seem to me that the details of how an > > > administrator configures IPsec in a network need not be mandated in the Diameter > > > drafts. > > > > > > Thanks, > > > Don > > > > The problem is that without *some* guidelines interoperability can be > > tricky. Surely we must have some idea of how IPsec would be used with > > Diameter, right? Why not spell this out explicitly? > > > > For example, implementations MUST USE encryption, since otherwise we > > have no hiding capabilities. Transport mode ESP with non-null transform > > seems like a reasonable way to go. In terms of transforms, 3DES seems like > > a reasonable thing to implement at least. Remember, DES is still mandatory > > within IPsec, but will soon be deprecated. > > > > Diameter clients and servers are likely to have fixed IP addresses, but > > where they don't, then a warning is appropriate against use of pre-shared > > keys with Main Mode, since this requires group secrets. > > > > > > > > -- > David Frascone > > If wishes were horses, dogfood would be a lot cheaper. --------------ECBAF96607794886E91E651E Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------ECBAF96607794886E91E651E-- From owner-aaa-wg@merit.edu Tue Feb 26 22:16:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29595 for ; Tue, 26 Feb 2002 22:16:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1AA3C912BB; Tue, 26 Feb 2002 22:16:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE6F2912BC; Tue, 26 Feb 2002 22:16:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A7C9F912BB for ; Tue, 26 Feb 2002 22:16:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88D4F5DDC1; Tue, 26 Feb 2002 22:16:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 5605A5DDA1 for ; Tue, 26 Feb 2002 22:16:42 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1R3Gfh02280; Tue, 26 Feb 2002 21:16:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1R3Gfh23389; Tue, 26 Feb 2002 21:16:41 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA13344; Tue, 26 Feb 2002 21:16:40 -0600 (CST) Received: from ericsson.com (pc136070.webcom.us.am.ericsson.se [138.85.136.70]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA04428; Tue, 26 Feb 2002 21:16:39 -0600 (CST) Message-ID: <3C7C4F07.F46B482@ericsson.com> Date: Tue, 26 Feb 2002 19:14:16 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: ISSUE 266: ready for closure? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > > > > > Well, we must still make it possible encrypt the FA-HA Key between the > > two AAAFs involved, since there is only a SHOULD for Diameter clients > > to support DSA. > > > > /Tony > > Your note that clients are not required to support CMS is a good one, > so I'm back on track with you. Forget my "One thought". Good, so do we agree on the solution for issue #266 (with the editorial changes you sent earlier)? From owner-aaa-wg@merit.edu Tue Feb 26 22:22:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29729 for ; Tue, 26 Feb 2002 22:22:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 01934912BC; Tue, 26 Feb 2002 22:21:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF3ED912BD; Tue, 26 Feb 2002 22:21:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 98E71912BC for ; Tue, 26 Feb 2002 22:21:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7AB275DDC1; Tue, 26 Feb 2002 22:21:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id 47BFA5DDA1 for ; Tue, 26 Feb 2002 22:21:42 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g1R3Lfh03193; Tue, 26 Feb 2002 21:21:41 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1R3LfX27766; Tue, 26 Feb 2002 21:21:41 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA13820; Tue, 26 Feb 2002 21:21:41 -0600 (CST) Received: from ericsson.com (pc136070.webcom.us.am.ericsson.se [138.85.136.70]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA04494; Tue, 26 Feb 2002 21:21:40 -0600 (CST) Message-ID: <3C7C5033.507BE184@ericsson.com> Date: Tue, 26 Feb 2002 19:19:16 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: Accounting-Multi-Session-Id AVP (draft-mobileip-08) References: <000b01c1bdab$1aeecf00$f6512844@sanarb01.mi.comcast.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I tend to agree with you. However, can you please submit this as an issue with the proposed change so we get this right according to our work process.. Regards, /Tony Bob Kopacz wrote: > Hi Tony, > > Here's some feedback regarding draft-mobileip-08's treatment of the > Accounting-Multi-Session-Id AVP. > > The following lines prefixed with "*" are extracted from > draft-mobileip-08. The extracted lines includes ALL places where the > Accounting-Multi-Session-Id AVP is mentioned. I numbered the lines to > make them referencable. > > Here goes... > > *01 1.2 Inter-Realm Mobile IP > *02 > *03 [...] > *04 > *05 For new sessions, the AAAH MUST create an accounting session > *06 identifier, which is added to the Accounting-Multi-Session-Id AVP in > *07 the HAR message sent to the home agent. > *08 > *09 During the creation of the HAR, the AAAH MUST use a different session > *10 identifier than the one used in the AMR/AMA (see figure 2). Of > *11 course, an AAAH MUST use the same session identifier for all HARs > *12 initiated on behalf of a given mobile node's session. [...] > *13 > > (1) According to the Introduction, an AAAH may be session-stateless. I > don't think a session-stateless AAAH can differentiate a new session > from a handoff of an existing session. Therefore a session-stateless > AAAH couldn't send the same session-id for handoffs, as stated in > line *11. > > So lines *05-*12 should be replaced by: > > "During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA. > > "If the AAAH is session-stateful, it should send the same session > identifier for all HARs initiated on behalf of a given mobile node's > session. > > "If the AAAH is not session-stateful, it will manufacture a unique > session-id for every HAR. (Note--This will not cause a problem for > the HA, who must be able to recognize a handoff even if the AAAH > thinks the session is new; an AAAH may incorrectly view a session as > new when the handoff AMR goes to a different AAAH than the previous > AMR). > > "Similarly, a session-stateful AAAH should send the same > Accounting-Multi-Session-Id identifier for all HARs initiated on > behalf of a given mobile node's session, while a session-stateless > AAAH will manufacture a unique Accounting-Multi-Session-Id in every > HAR." > > (In a later section, I will propose eliminating the last paragraph > which begins "Similarly...") > > *14 [...] > *15 > *16 Upon receipt of the HAR, the Home Agent first processes the Diameter > *17 message. [...] The Accounting-Multi-Session-Id AVP in > *18 the HAR MUST be included in the HAA, which is then forwarded to the > *19 AAAH. > *20 > > (2) The last sentence is not quite right. While the HA does send an > Accounting-Multi-Session-Id AVP in the HAA, it may be a different one > than was received in the HAR. (see lines *44-*46). > > *21 Upon receipt of the HAA, the AAAH creates the AA-Mobile-Node-Answer > *22 (AMA) message, includes the Accounting-Multi-Session-Id that was > *23 present in the HAA, and the MIP-Home-Agent-Address, [...] > *24 > *25 1.3 Support for Mobile IP Handoffs > *26 > *27 [...] > *28 > *29 Since the new AAAH in the home network MAY not have access to the > *30 session identifier that was used by the old AAAH, it is necessary for > *31 the resulting HAR received by the HA to be identified as a > *32 continuation of an existing session. If the HA receives an HAR for a > *33 mobile node, with a new session identifier, and the HA can guarantee > *34 that this request is to extend service for an existing service, then > *35 the HA MUST be able to modify its internal session state information > *36 to reflect the new AAAH and session identifier. The HA MUST also > *37 issue an STR message with the old session identifier to the AAAH it > *38 was communicating with when using the old session identifier. > *39 > *40 It is necessary for accounting records to have some commonality > *41 across handoffs in order for correlation to occur. Therefore, in the > *42 event that a home agent receives an HAR with a different Accounting- > *43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the > *44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP > *45 that was received by the AAAH in the first HAR for the mobile's > *46 session. This modified Accounting-Multi-Session-Id AVP will be > *47 returned to the foreign agent by the AAAH in the AMA. Both the > *48 foreign and home agents MUST include the Accounting-Multi-Session-Id > *49 in the accounting messages. > *50 > > (3) Since the AAAH must be prepared to have the AAAH-generated > Accounting-Multi-Session-Id overridden by the HA, why don't we just > have the HA always specify the Accounting-Multi-Session-Id? > > The thinking is that the HA is constant over the MN's session, while the > AAAHs and AAAFs and FAs change. So the HA is in a position to specify a > constant Accounting-Multi-Session-Id, eliminating the extra > complications of a switcheroo. > > The proposal here is that the AAAH MUST NOT send a > Accounting-Multi-Session-Id in the HAR. The HA MUST send a > Accounting-Multi-Session-Id in the HAA. All of the messages for a > MN's session will have the same value for the > Accounting-Multi-Session-Id AVP. > > (4) Since the AAAH may be session-stateless, the HA would send the STR > to the AAAH, as indicated in lines *36-*38, if and only if the AAAH > has changed. > > (5) So then lines *29-*50 are replaced by: > > "Since the new AAAH in the home network MAY not have access to the > session identifier that was used by the old AAAH, or since the AAAH > may be session-stateless, it is necessary for the resulting HAR > received by the HA to be identified as a continuation of an existing > session. > > "If the HA receives an HAR for a mobile node, with a new session > identifier, and the HA can guarantee that this request is to extend > service for an existing service, then the HA MUST be able to modify > its internal session state information to reflect the (possibly) new > AAAH and new session identifier. > > "If the AAAH is new, the HA MUST also issue an STR message with the old > session identifier to the AAAH it was communicating with when using > the old session identifier. > > "It is necessary for accounting records to have some commonality across > handoffs in order for correlation to occur. Therefore, the home agent > MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for > the mobile's session. That is, the HA generates a unique > Accounting-Multi-Session-Id when receiving an HAR for a new session, and > returns this same value in every HAA for the session. > > "This Accounting-Multi-Session-Id AVP will be returned to the foreign > agent by the AAAH in the AMA. Both the foreign and home agents MUST > include the Accounting-Multi-Session-Id in the accounting messages." > > (6) And if you agree that the HA should generate the > Accounting-Multi-Session-Id, then Section 1.5 "Co-located Mobile Node", > should add the sentence: > > "The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to > the AAAH, as the AAAH may find this a useful tidbit of session-state or > log entry information." > > *51 2.2 AA-Mobile-Node-Answer > *52 > *53 [...] > *54 > *55 ::= < Diameter Header: 260, PXY > > *56 [...] > *57 [ Accounting-Multi-Session-Id ] > *58 [...] > *59 > *60 > *61 2.3 Home-Agent-MIP-Request > *62 > *63 [...] > *64 > *65 ::= < Diameter Header: 262, REQ, PXY > > *66 [...] > *67 { Accounting-Multi-Session-Id } > *68 [...] > *69 > *70 2.4 Home-Agent-MIP-Answer > *71 > *72 [...] > *73 > *74 ::= < Diameter Header: 262, PXY > > *75 [...] > *76 [ Accounting-Multi-Session-Id ] > *77 [...] > *78 > > *79 8.1 Mobile IP Command AVP Table > *80 > *81 The table in this section is limited to the Command Codes defined in > *82 this specification. > > (7) The AMR/AMA/HAR/HAA occurrence table doesn't include the > Accounting-Multi-Session-Id AVP. It needs an entry like: > > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 | > > *83 > *84 8.2 Accounting AVP Table > *85 > > (8) The Accounting occurrence table doesn't mention the > Accounting-Multi-Session-Id AVP, but it should because the Base protocol > defines the Accounting-Multi-Session-Id AVP, and makes the general > statement that the Accounting-Multi-Session-Id AVP can occur in the ACR > and ACA messages "0-1" times. But the applications have their own > specific requirements. The Mobile IPv4 application requires the > following: > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > Accounting-Multi-Session-Id | 1 | 0-1 | > > (9) The above Accounting occurrence table should indicate any other > application-specific ACR/ACA requirements that are different from the > Base protocol's more general Accounting occurrence table. > > Bob K. From owner-aaa-wg@merit.edu Tue Feb 26 22:26:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29779 for ; Tue, 26 Feb 2002 22:26:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DD7B2912BD; Tue, 26 Feb 2002 22:26:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3316912BE; Tue, 26 Feb 2002 22:26:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92F33912BD for ; Tue, 26 Feb 2002 22:26:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5FDE75DDCA; Tue, 26 Feb 2002 22:26:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id EFCB35DDA1 for ; Tue, 26 Feb 2002 22:26:24 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1R3QOS15427; Tue, 26 Feb 2002 21:26:24 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1R3QOK26297; Tue, 26 Feb 2002 21:26:24 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id VAA14155; Tue, 26 Feb 2002 21:26:23 -0600 (CST) Received: from ericsson.com (pc136070.webcom.us.am.ericsson.se [138.85.136.70]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA04561; Tue, 26 Feb 2002 21:26:22 -0600 (CST) Message-ID: <3C7C514E.84CDDA40@ericsson.com> Date: Tue, 26 Feb 2002 19:23:58 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: (draft-mobileip-08) Session-Binding & Re-Auth-Request-Type clarifications References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, Can you please send an issue on what you believe should be clarified in the spec. It is really hard for me to keep track of all possible changes otherwise. Regards, /Tony Bob Kopacz wrote: > A couple clarifications. My real concern is interoperability: that the > mobility agents know what to expect from the AAA servers. > > Session-Binding AVP > -------------------- > > Section 1.2. of draft-mobileip-08 says: > > > 1.2 Inter-Realm Mobile IP > > > > [...] > > > > In the event that the AMR generated by the FA is for a session that > > has was previously authorized by the AAAH, it MUST include the > > Destination-Host AVP, with the identity of the AAAH. > > (1) Question: Does this mean the AAAH, when sending back an AMA, > should include a Session-Binding AVP with the RE-AUTH flag OFF? > > Recall that the Base drafts says that "The Session-Binding AVP MAY be > present in application-specific authorization answer messages. If > present, this AVP MAY inform the Diameter client that all future > application-specific re-auth messages for this session MUST be sent to > the same authorization server." > > So the Session-Binding AVP can be used to specify the exact behavior > that draft-mobileip-08 wants from the FA. > > Or, putting the question another way, since this is the required > behavior of the FA, is it necessary for the AAAH to send the > Session-Binding AVP? > > (2) The Session-Binding AVP is not mentioned at all in > draft-mobileip-08; not in the AMR/AMA/HAR/HAA occurrence rule table, > not in the message ABNF, not in the text. > > So maybe add an occurrence rule entry like: > > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Session-Binding | 0 | 0-1 | 0 | 0 | > > .............................................................. > > Re-Auth-Request-Type AVP > ------------------------ > > (3) Question: Should the AAAH, when sending back an AMA which includes > a positive Authorization-Lifetime, also send a Re-Auth-Request-Type > AVP with the value AUTHORIZE_AUTHENTICATE (to let the FA know the > re-auth requirements)? > > This seems so, since the occurrence rules indicate the > Re-Auth-Request-Type can be present 0-1 times in an AMA. From owner-aaa-wg@merit.edu Tue Feb 26 22:36:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00741 for ; Tue, 26 Feb 2002 22:36:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CCD94912BF; Tue, 26 Feb 2002 22:36:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A685912C1; Tue, 26 Feb 2002 22:36:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D7A1912BF for ; Tue, 26 Feb 2002 22:35:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 63C975DDCA; Tue, 26 Feb 2002 22:35:58 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by segue.merit.edu (Postfix) with ESMTP id 7FC3E5DDA1 for ; Tue, 26 Feb 2002 22:35:57 -0500 (EST) Received: from jariws1 ([62.248.144.123]) by fep06-app.kolumbus.fi with SMTP id <20020227033556.QPEB20539.fep06-app.kolumbus.fi@jariws1>; Wed, 27 Feb 2002 05:35:56 +0200 Message-ID: <01b101c1bf3f$e6f14160$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Frascone" , "Bernard Aboba" Cc: "Don Zick" , , References: <3C7C010C.255E909C@interlinknetworks.com> <20020226220140.GG8806@newman.frascone.com> Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments Date: Wed, 27 Feb 2002 05:36:11 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe Bernard is right and interoperability is enhanced if we give specific rules about how IPsec must be used. I think we should keep the details. Some small nits though: - "with a non-null transform" => "with non-null encryption and authentication algorithms" - IKE is a MUST and manual keying is a MUST NOT. I don't know, but I'd be able to live with manual keying as well and that could be the low-cost solution to some low-cost NASes... given that there is a (weak) protection against replay attacks through Hop-by-Hop identifier at Diameter layer. - "...access to locally stored secret ... " this sentence may be unnecessary, or? - "SHOULD check the pertinent Certificate Revocation List (CRL)" => "SHOULD use pertinent certificate revocation checks"? CRLs are not the only possible way, so maybe we should make the sentence a bit more general as attempted here. - "... Phase 1 Delete message ..." - Could we leave this paragraph out, is it really necessary? Jari From owner-aaa-wg@merit.edu Tue Feb 26 22:52:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01284 for ; Tue, 26 Feb 2002 22:52:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7DDDF912C3; Tue, 26 Feb 2002 22:52:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2287912C4; Tue, 26 Feb 2002 22:52:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06C50912C3 for ; Tue, 26 Feb 2002 22:52:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E20FD5DDD1; Tue, 26 Feb 2002 22:52:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 67DA35DDA1 for ; Tue, 26 Feb 2002 22:52:20 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1R3CSr32191 for ; Tue, 26 Feb 2002 19:12:28 -0800 Date: Tue, 26 Feb 2002 19:12:28 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Text, please In-Reply-To: <01b101c1bf3f$e6f14160$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The editorial team is struggling mightily to get as many issues as possible resolved by the March 1, 2002 submission deadline. They need your help. Life as an editor is a *lot* easier if people post proposed text, making it clear what is to be replaced. That allows the editor to do a simple "search and replace". One can cycle through quite a few changes rapidly that way. So if you would like a document changed, and haven't submitted an issue, *please* do so in the prescribed format, with detailed change recommendations. This helps us track the issue and determine whether it was resolved or just fell between the cracks. It also helps the editors get what they need to be most efficient. If you are commenting on a proposed resolution, please include your complete alternative text. That way, the editor doesn't have to wind through a long thread to piece together what the resolution is -- since the final message of the thread will presumably have complete text agreed to by the discussants. From owner-aaa-wg@merit.edu Tue Feb 26 23:01:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01418 for ; Tue, 26 Feb 2002 23:01:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 24DCD912C5; Tue, 26 Feb 2002 23:00:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E256C912C6; Tue, 26 Feb 2002 23:00:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 00D61912C5 for ; Tue, 26 Feb 2002 23:00:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id D59585DDCC; Tue, 26 Feb 2002 23:00:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 67B395DDCA for ; Tue, 26 Feb 2002 23:00:27 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1R3KUv32686; Tue, 26 Feb 2002 19:20:30 -0800 Date: Tue, 26 Feb 2002 19:20:30 -0800 (PST) From: Bernard Aboba To: David Spence Cc: David Frascone , Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage - Need Comments In-Reply-To: <3C7C1393.4B1EC393@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Are we suggesting that a Diameter server should be able to > originate an IKE exchange that would trigger establishment of an IPsec > tunnel? Why should a Diameter server (or client for that matter) be establishing IPsec tunnels? > We should describe what the real requirements are. I agree. This implies a security considerations section with a threat model. Better late than never, I guess :( From owner-aaa-wg@merit.edu Tue Feb 26 23:13:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01599 for ; Tue, 26 Feb 2002 23:13:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F0396912C6; Tue, 26 Feb 2002 23:12:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7780912C7; Tue, 26 Feb 2002 23:12:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CE385912C6 for ; Tue, 26 Feb 2002 23:12:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id B6CED5DDCC; Tue, 26 Feb 2002 23:12:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A43685DDCA for ; Tue, 26 Feb 2002 23:12:52 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id E57B17A; Tue, 26 Feb 2002 23:12:49 -0500 (EST) Message-ID: <3C7C5CC6.925EBD40@Interlinknetworks.com> Date: Tue, 26 Feb 2002 23:12:54 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: David Frascone , Don Zick , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage- Need Comments References: Content-Type: multipart/mixed; boundary="------------6FE9439B11C07396D28F6C0F" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------6FE9439B11C07396D28F6C0F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > Are we suggesting that a Diameter server should be able to > > originate an IKE exchange that would trigger establishment of an IPsec > > tunnel? > > Why should a Diameter server (or client for that matter) be establishing > IPsec tunnels? I didn't think it would. But if it doesn't, then it isn't necessary to specify the IPsec requirements in the Diameter standard because there would be nothing in those requirements for a Diameter implementation to comply with. > > > We should describe what the real requirements are. > > I agree. This implies a security considerations section with a threat > model. Better late than never, I guess :( O.K. I guess we should cover the operational requirements in the security considerations section. We probably don't need to specify specific IPsec options there except to note the minimal requirements. --------------6FE9439B11C07396D28F6C0F Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------6FE9439B11C07396D28F6C0F-- From owner-aaa-wg@merit.edu Wed Feb 27 00:27:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03292 for ; Wed, 27 Feb 2002 00:27:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A64AC912CB; Wed, 27 Feb 2002 00:27:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 75BEB912CD; Wed, 27 Feb 2002 00:27:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3935C912CB for ; Wed, 27 Feb 2002 00:27:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17E925DDD6; Wed, 27 Feb 2002 00:27:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id D504A5DDCA for ; Wed, 27 Feb 2002 00:27:04 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1R5R3S05375; Tue, 26 Feb 2002 23:27:03 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1R5R2K16949; Tue, 26 Feb 2002 23:27:03 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id XAA24245; Tue, 26 Feb 2002 23:27:00 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA06123; Tue, 26 Feb 2002 23:26:58 -0600 (CST) Message-ID: <3C7C6D90.64A9DCE5@ericsson.com> Date: Tue, 26 Feb 2002 21:24:32 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Panagiotis-PTHOMAS1 Cc: "Pat R. Calhoun" , Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit So, do you want me to remove the recommendation and then it is OK? /Tony Thomas Panagiotis-PTHOMAS1 wrote: > Tony, > > "The value of the MIP-Key-Lifetime AVP MUST be at least equal to > the value in the Authorization Lifetime AVP. If the value is greater, > it SHOULD be a multiple of the value in the Authorization Lifetime AVP." > > Recommending the MIP-Key-Lifetime to be a multiple of the MIP > (Authorization) > lifetime doesn't mean much when you don't want to go through AAA upon every > handoff - the two timers will soon get out of sync. > > -Panos > > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Monday, February 25, 2002 7:21 PM > To: Pat R. Calhoun > Cc: Bob Kopacz; aaa-wg > Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP > > > "Pat R. Calhoun" wrote: > > > But, in the AAA Registration Keys for Mobile IP, which we are > > dependent on, you can only > tell the mobile one timer (the > > Lifetime). The Lifetime AAA Registration Keys for Mobile IP > > indicates the duration of time (in seconds) for which the MN-FA and > > MN-HA keys are valid. When the keys expires the MN must re-auth, > > so seen from the MN the authorization lifetime and the key > > lifetime is very much the same thing. Right? > But there is a fundamental difference between the Lifetime field in > the MIP header, and the lifetime fields in the individual aaa-key > extensions. Right? > > Ahh, the Authorization lifetime is used for the tunnel update and the > MIP-Key lifetime is used for the keys.... > So, what about to following additional text to the draft to explain / > clarify the usage of the MIP-Key-Lifetime AVP and Authorization Lifetime > AVP, see below. All, comments / objections. > Regards, > /Tony > "1.6 Diameter Session Termination > A Foreign and Home Agent following this specification MAY expect > their respective Diameter servers to maintain session state > information for each mobile node in their networks. In order for the > Diameter Server to release any resources allocated to a specific > mobile node, the mobility agents MUST send a Session-Termination- > Request (STR) to the Diameter server that authorized the service. The > Session-Termination-Request (STR) MUST be issued by the mobility > agents if the Authorization Lifetime has expired and no subsequent > MIP registration request have been received. > ........ " > > New section: > > "5.1 Authorization Lifetime vs. MIP Key Lifetime > > The Diameter Mobile IP application makes use of two timers the > Authorization-Lifetime AVP [DIAMBASE] and the MIP-Key-Lifetime AVP. > The Authorization-Lifetime contains the number of seconds before the > Mobile Node must issue a subsequent MIP registration request. The > content of Authorization-Lifetime AVP corresponds to the Lifetime > field in the MIP header [MOBILEIP]. > The MIP-Key-Lifetime AVP contains the number of seconds before > session keys destined for the Home Agent and/or Foreign Agent expire. > A value of zero indicates infinity (no timeout). The value of the > MIP-Key-Lifetime AVP MUST be at least equal to the value in the > Authorization Lifetime AVP. If the value is greater, it SHOULD be a > multiple of the value in the Authorization Lifetime AVP." From owner-aaa-wg@merit.edu Wed Feb 27 00:41:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03505 for ; Wed, 27 Feb 2002 00:41:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 02C81912CD; Wed, 27 Feb 2002 00:41:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0594912CE; Wed, 27 Feb 2002 00:41:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FBCE912CD for ; Wed, 27 Feb 2002 00:41:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 54D2B5DDD7; Wed, 27 Feb 2002 00:41:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id E6BCF5DDD6 for ; Wed, 27 Feb 2002 00:41:18 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1R5fIS07599; Tue, 26 Feb 2002 23:41:18 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1R5fHK19212; Tue, 26 Feb 2002 23:41:18 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id XAA25394; Tue, 26 Feb 2002 23:41:16 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA06315; Tue, 26 Feb 2002 23:41:14 -0600 (CST) Message-ID: <3C7C70EA.FB484ECE@ericsson.com> Date: Tue, 26 Feb 2002 21:38:50 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: [issue] More Minor corrections/clarifications to draft-mobileip-08 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I will go ahead and add these editorial correction / clarifications. Comments / objections. Regards, /Tony Bob Kopacz wrote: > Issue : More Minor corrections/clarifications to draft-mobileip-08 > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: 02-25-2002 > Reference: > Document: mobile-ip 08 > Comment type: Editorial > Priority: 1 > Section: > Rationale/Explanation of issue: > > Minor corrections/clarifications. > > Requested change: > > In Section 1 "INTRODUCTION" > > > An AAA Home server (AAAH) and AAA foreign server (AAAF) which > > supports the Mobile-IP authentication application MAY maintain > > session-state or MAY be session-stateless. AAA redirect agents and > > AAA relay agents MUST not maintain session-state. AAAH, AAAF, proxies > > and relays agents MUST maintain transaction state. > > Change the beginning of the last sentence from "AAAH..." to "The > AAAH...". > > - - - - - > > In Section 1.4 "Allocation of Home Agent in Foreign Network" > > Since the AAAF has to send an HAA whether the HA's Result-Code is > success or not: > > Replace > > > Upon receipt of a HAA from the Home Agent in the visited realm, with > > the Result-Code AVP indicating success, the AAAF forwards the HAA to > > the AAAH in the home realm. The AMA is then constructed, and issued > > to the AAAF, and finally to the FA. The HAA and AMA MUST include the > > MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > With: > > Upon receipt of a HAA from the Home Agent in the visited realm, the > AAAF forwards the HAA to the AAAH in the home realm. The AMA is then > constructed, and issued to the AAAF, and finally to the FA. If the > Result-Code indicates success, the HAA and AMA MUST include the > MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. > > Similarly, replace: > > > When the AAAF receives a successful HAA, the AAAF will forward the > > HAA back to the AAAH. The HAA MUST include the MIP-Home-Agent-Address > > and the MIP-Mobile-Node-Address AVPs. The AAAH will then send back an > > AMA to the AAAF in foreign network 2. > > With: > > When the AAAF receives a HAA, the AAAF will forward the HAA back to > the AAAH. If successful, the HAA MUST include the > MIP-Home-Agent-Address and the MIP-Mobile-Node-Address AVPs. The AAAH > will then send back an AMA to the AAAF in foreign network 2. > > In the final paragraph of this section: > > > If the old Foreign Network does not permit the use of its Home Agent > > when the Mobile Node moves to a new foreign network, the AAAH or AAAF > > MUST return an AMA with the Result-Code AVP set to > > DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the > > Foreign Agent MUST issue a Mobile IP Registration Reply to the Mobile > > Node with an appropriate error. The Mobile Node MAY attempt to > > request that a new Home Agent and Address be allocated. When the AAAH > > transmits such an error, it MUST issue a Diameter Abort-Session- > > Request message to the AAAF overseeing the Home Agent to enable it to > ^^^^^^^^^^^^^^^ > > Remove "AAAF overseeing". I think the ASR goes to the Home Agent. > I'm not sure the AAAH even has the AAAF's DiameterIdentity to target > the ASR there. > > > release any resources. > > - - - - - > > In section 5.1 "Key Material vs. Session Key" > > > The AAAH then generates the session key which is destined for the > > mobility agent, in this case the foreign agent, by following the > > above procedures. It is important that the hashing algorithm used by > > the mobile node is the same as the one used by the AAAH in the > > session key generation procedure. Therefore, the AAAH MUST know a > > priori the transform used, which is typically contained in the mobile > > node's configuration profile. > > Remove the last two sentences, which begin "It is important..." and > "Therefore...". I think this is outdated baggage. The AAAH indicates > the algorithm used and the SPI in the Key AVPs which contain key > material, so the a priori stuff goes away. Or if you don't want to > remove them, then replace them with > > "It is important that the hashing algorithm used by the mobile node to > construct the session key is the same as the one used by the AAAH in > the session key generation procedure. The AAAH therefore indicates > the transform used along with the key material." > > > The session keys destined for mobility > > agents are encoded using the security association available between > > Change "are encoded" to "may be encoded". The other places in the > draft indicate that hiding the keys is a SHOULD or MAY. > > > the AAA server and the agents (e.g. IPSec, TLS, CMS). > > The Foreign-Home session key is shared between two mobility agents: > > the FA and HA. Since this key is not destined for the mobile node, > > there is no need to follow the session key generation procedures > > detailed above. Instead, the AAAH generates a random [18] value of at > > least 64 bits for use as the Foreign-Home session key. > > - - - - - > > In section 5.2 "Distributing the Mobile-Home Session Key" > > Since the HAR still contains the HA's identity as the Destination-Host, > Replace: > > > If, on the other hand, the home agent is to be allocated in the > > visited realm, the AAAH does not transmit the HAR to the home agent, > > but instead transmits the HAR to the AAAF. > > With: > > "If, on the other hand, the home agent is to be allocated in the > visited realm, the AAAH transmits the HAR to the foreign home agent, > where, prior to delivery to the home agent, it is perused by the AAAF > hosting the home agent." > > - - - - - > > In section 6.11 "MIP-FA-to-HA-SPI AVP" > > > The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and > > contains the Security Parameter Index the Foreign Agent is to use to > > refer to the session key it shares with the Home Agent. The SPI > > created MUST NOT be a value between zero (0) and 255, which is the > > reserved namespace defined in [4]. This AVP MAY be added in the HAA > > message by the Home Agent for the AAAH's use in MIP-FA-to-HA-SPI AVP > > of the MIP-FA-to-HA-Key AVP. > > Replace the last sentence by: > > "If FA-HA keys are being generated, this AVP MUST be added in the HAA > message by the Home Agent for the AAAH's (or AAAF's) use in providing > the value of the MIP-FA-to-HA-SPI member of the grouped > MIP-FA-to-HA-Key AVP." > > - - - - - From owner-aaa-wg@merit.edu Wed Feb 27 01:10:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03815 for ; Wed, 27 Feb 2002 01:10:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0D84B912CE; Wed, 27 Feb 2002 01:09:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB06E912CF; Wed, 27 Feb 2002 01:09:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D181D912CE for ; Wed, 27 Feb 2002 01:09:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id B87145DDCA; Wed, 27 Feb 2002 01:09:52 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id 4953B5DD91 for ; Wed, 27 Feb 2002 01:09:52 -0500 (EST) Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios To: "Harri Hakala (LMF)" , "'aaa-wg@merit.edu'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Wed, 27 Feb 2002 07:09:50 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/27/2002 07:09:52 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Harri, I'll try to explain my point again, >Hi Paco, >I see your point and I agree with you that the >explained scenarios are important to cover from a charging >perspective. But I think that you can use the existing mechanism >provided by credit control draft to solve your problem >(check the balance). Yes, to check the balance could be used the several interrogations CCA (session control). However, if what we want is only to check the balance. Why to use several interrogations to get it? Why don't give to the application flexibility enough to ease the ability of checking the balance in an only interrogation? I understand this flexibility could be compatible with the current especified version in the draft. >The focus of the draft is to provide network operator/service provider >with means to check that the end user has credit before rendering the >service in order to prevent credit loss. It does not focus account >update/promotion functions or account enquiry functions. Ok, Harri. Nothing to comment if the focus of your draft is strictly closed. However my idea was to take advantage of the described mecanisms without adding much complexity to endow the application with enhanced capabilities to solve the problem of the increment of credit. Traditionaly, in the network operators, discount and increment of credit were treated in different ways. For the network operator was critic the fraud produced when a service is provided to a user that has no credit. To refund the credit incorrectly discounted, other means could be applied. However when the third parties appear in the scenario of the telecomunications world the rules could be different. A third party could give to a network operator user a number of services for free, or simply give free credit to the user (due to, as commented, the access to advertisement pages as an example), this extra credit could be charged in real time to the third party by the network operator, however the third party could demand to the network operator to increase the credit of this user in real time as well. On the other hand, the market image of the operator could demand for several network operator services to be able to accomplish the increments in the user account in real time as well. In the future, to be able to accomplish these features could be as important as the ability of decrement credit in real time. Credit is credit, this application acts on the user credit, an increment is only a negative decrement, we have the tools and we have a reason to do it. Maybe I'm in a mistake or I'm confussed but, Why don't make it flexible enough? It could be summarized in the question: Why don't open a bit more the focus of the draft to include these abilities? These ones could be of interest from the point of network operators. Thanks for your attention. Regards, Paco. "Harri Hakala (LMF)" con fecha 25/02/2002 14:21:08 Asunto: RE: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios Hi Paco, I see your point and I agree with you that the explained scenarios are important to cover from a charging perspective. But I think that you can use the existing mechanism provided by credit control draft to solve your problem (check the balance). In your scenario when the network operator (credit control client) receives the SM from the third party, it can start accounting session and try to make credit-reservation. If granted-service-unit is returned by the credit control server, the network operator can acknowledge the SM delivery to the third party. If the end user is out of coverage (no acknowledgement), the network operator can stop the accounting session and indicate that the used-service-unit is zero. I assume that the network operator will get indication when the end user is attached again, so it can re-start accounting session and SM delivery to the end-user and there is no need to keep the accounting session open several days. The focus of the draft is to provide network operator/service provider with means to check that the end user has credit before rendering the service in order to prevent credit loss. It does not focus account update/promotion functions or account enquiry functions. Regards.............Harri -----Original Message----- From: fmaring@airtel.es [mailto:fmaring@airtel.es] Sent: 19. helmikuuta 2002 8:41 To: aaa-wg@merit.edu Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenariosu Issue : Possible modification to the Diameter Cost Control Application protocol Submitter name: Paco Marin Submitter email address: fmaring@airtel.es Date first submitted: 02-18-2002 Reference: Document: draft-hakala-diameter-credit-control-01.txt Comment type: Technical Hi all, I've been taking look to the last version of the draft 'Diameter Credit Control Application' (draft-hakala-diameter-credit-control-01.txt). I've been thinking about common services an operator like my company needs to offer and the possibility of applying DIAMETER CCA to the charging part. Sorry if some of the following issues are obvious, but I think despite of the most of the scenarios being covered with the described protocol, however I did'nt find the way to use this protocol to cover two possible scenarios. The referred scenarios are the following: 1.- Check of balance. Sometimes is necessary to check if there is enough balance to grant a service to a subscriber. Imagine a subscriber of a mobile comunications operator wants to download a melody or a 'logo' from the Internet on his mobile phone (using the Short Message Service of GSM). In this scenario, there are three parts: the subscriber, the network operator and a third party which is the service provider. The third party will charge the sent melody (or logo) to the network operator just when the network operator receives it, so it could be interesting to acknowledge the Short Message delivery from the third party only when the subscriber has enough credit. This way the operator avoids to pay for a message that will never be delivered because the final user (the subscriber) has no credit enough. I've been thinking about the possibility of using 'session based credit control'. However is hardly ineficient, the SM must be acknowledged immediately and the short message could wait several days to be delivered to the final user (the user could be out of coverage), it implies to keep the session opened until the SM is finally delivered. 2.- Increment of Credit In some scenarios could be useful to add to the protocol the posibility to increase the balance instead of decrementing it. As an example, could be a way to motivate the user access to advertisement information in the internet or to receive adversiting Short Messages from a third party. In these scenarios could be interesting to be able to increment the credit directly from the client, as an example increase money on the user account or allow 1 free short message every 5 advertisement Short Message received. I think there is no way to make it with the current version of the draft (please, please, please correct me if I am wrong or confused). The solution to these two scenarios should not be fundamental for the overall working of the Diameter CCA, however it would apply flexibility enough to ease the use of the protocol to the legacy architectures of the current network operators. In my humble opinion a possible solution for both scenarios should be to include a new AVP. PROPOSAL OF SOLUTION A new AVP to indicate an operation on the balance is going to be accomplished could be added to the proposed AVPs of the Diameter CCA protocol. This AVP could indicate if the action to be carried out is a decrement, check of balance or an increment. If this new AVP is not included in the request, the server should consider that the value of this one is '0', it will mean the behaviour of the protocol will be the one described up to now. The new AVP could be: 'Balance-Management-Indicator', it should be of tipe Unsigned32 and its values could be: '0': Decrement, the request and answer work as up to now. The 'Requested-Service-Unit' AVP contains the unit to decrement, the 'Granted-Service-Unit' AVP contains the service units granted. This units will be decremented in that moment from the user account. '1':Check of balance, the 'Requested-Service-Unit' AVP could contains the service unit to check if it is allowed to be carried out, the 'Granted-Service-Unit' AVP contains the service units allowed to be carried out. This units will NOT be decremented from the user account. '2': Increment, the request and answer work in a similar way as described for the value '0'. The 'Requested-Service-Unit' AVP contains the unit to increment, the 'Granted-Service-Unit' AVP contains the service units incremented. This units will be incremented in that moment in the user account. The accounted AVP table should be modified as follows: +----------+ | Command | | code | +----+-----+ Attribute Name |ACR | ACA | ------------------------------+----+-----+ Balance-Management-Indicator |0-1 | 0 | ------------------------------+----+-----+ Maybe I'm confused..... correct me in that case. Thanks a lot. Paco. From owner-aaa-wg@merit.edu Wed Feb 27 01:47:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04280 for ; Wed, 27 Feb 2002 01:47:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DB620912CF; Wed, 27 Feb 2002 01:47:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 95EC7912D0; Wed, 27 Feb 2002 01:47:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79D6D912CF for ; Wed, 27 Feb 2002 01:47:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 590745DDD9; Wed, 27 Feb 2002 01:47:09 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 76B7F5DDCA for ; Wed, 27 Feb 2002 01:47:08 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R6lGZ12652 for ; Wed, 27 Feb 2002 08:47:16 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 08:47:08 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 08:47:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage- Need Comments Date: Wed, 27 Feb 2002 08:47:06 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A42@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 254: More details needed on Diameter IPsec usage- Need Comments Thread-Index: AcG/WgUN9jyfXV1eS+OXk0zN1wyONwAAFMxA From: To: , Cc: , , X-OriginalArrivalTime: 27 Feb 2002 06:47:07.0046 (UTC) FILETIME=[9297AC60:01C1BF5A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA04280 Hi David & Bernard, > > > Are we suggesting that a Diameter server should be able to > > > originate an IKE exchange that would trigger > establishment of an IPsec > > > tunnel? > > > > Why should a Diameter server (or client for that matter) be > establishing > > IPsec tunnels? > > I didn't think it would. But if it doesn't, then it isn't > necessary to > specify the IPsec requirements in the Diameter standard > because there would > be nothing in those requirements for a Diameter > implementation to comply > with. > > > > > > We should describe what the real requirements are. > > > > I agree. This implies a security considerations section > with a threat > > model. Better late than never, I guess :( > > O.K. I guess we should cover the operational requirements in > the security > considerations section. We probably don't need to specify > specific IPsec > options there except to note the minimal requirements. I prefer David S's approach, specifying minimum PROTOCOL requirements, operation issues are best saved for a BCP doc. However, can someone document these requirements? Are they similar to Bernard's text or subset? Could we try to resolve it today (Wednesday)? John From owner-aaa-wg@merit.edu Wed Feb 27 01:49:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04310 for ; Wed, 27 Feb 2002 01:49:19 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B1DAB912D0; Wed, 27 Feb 2002 01:49:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 74BD6912D1; Wed, 27 Feb 2002 01:49:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26528912D0 for ; Wed, 27 Feb 2002 01:49:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05B625DDCA; Wed, 27 Feb 2002 01:49:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 4F9D35DD91 for ; Wed, 27 Feb 2002 01:49:01 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R6n9Z13556 for ; Wed, 27 Feb 2002 08:49:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 08:49:00 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 08:49:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue] Routing of session messages defined in base Date: Wed, 27 Feb 2002 08:48:59 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A44@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue] Routing of session messages defined in base Thread-Index: AcG/FH+IsBQk5SG8ReuJnM06XcwdJQARkWRQ From: To: , Cc: , X-OriginalArrivalTime: 27 Feb 2002 06:49:00.0006 (UTC) FILETIME=[D5EC0060:01C1BF5A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA04310 Hi all, Please give exact text for this issue to be added / modified to the base spec. John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 27 February, 2002 00:25 > To: Johan Johansson > Cc: Bob Kopacz; aaa-wg > Subject: Re: [AAA-WG]: [Issue] Routing of session messages defined in > base > > > I think I agree that Auth-Application-Id should be present in > these messages > assuming it is known. It could help in the routing. > > One reason that these messages may not have included the > Auth-Application-Id > AVP is that it was thought that this AVP would most likely be > used at the > last hop, and the messages under discussion here would > usually contain a > Destination-Host AVP to be used at the last hop instead. However, the > presence of the Destination-Host AVP does not help in Johan's > scenario: > > > S----------------X------------X------------N > > | > > +------------X------------M > > This scenario might describe a roaming broker (running the > Xs) who deploys > separate proxy agents for different applications. > > Johan Johansson wrote: > > > > Yes, the issue has been cloned. Sorry about that. I even > looked at the > > issues list first but I guess I wasn't paying attention > closely enough. > > Nice to see that we are suggesting the same resolution at least. > > > > j > > > > Bob Kopacz wrote: > > > > >Hi Johan, > > > > > >I think your issue is very similar to an existing one: > > > > > >>-----Original Message----- > > >> > > >From: Bob Kopacz [BKopacz@InterlinkNetworks.com] > > >Sent: Friday, January 25, 2002 2:49 PM > > >To: aaa-wg > > >Subject: [AAA-WG]: [issue] Proxiable messages MUST contain > Axxx-Application-Id > > >AVP > > > > > >Issue : Proxiable messages MUST contain Axxx-Application-Id AVP > > >Submitter name: Bob Kopacz > > >Submitter email address: BKopacz@InterlinkNetworks.com > > >Date first submitted: 01-25-2002 > > >Reference: > > >Document: Base > > >Comment type: Technical > > >Priority: 1 > > >Section: > > > > > > [I know last-call is over, but pending issues haven't > been resolved > > > yet, and I think this is a bug]. > > > > > >Rationale/Explanation of issue: > > > > > > Accounting messages and application-specific messages have an > > > Axxx-Application-Id AVP which identifies the application (e.g. > > > Mobile IP). > > > > > > The Auth-Application-Id AVP is currently prohibited from > being present > > > in the Session-Terminate-Request, Abort-Session-Request, and > > > Re-Auth-Request messages. > > > > > > This creates a routing problem for intermediate proxy or > relay servers > > > when receiving an STR/ASR/RAR. The intermediate server's routing > > > table may indicate that, say, Mobile-IP messages route > to a different > > > next hop than NASREQ messages. An STR message, however, > contains no > > > application-id AVP indicating NASREQ-v-MobileIp, so the > intermediate > > > server doesn't know how to route it. > > > > > > > > >Requested change: > > > > > > 1. Require an Auth-Application-Id AVP in > Session-Terminate-Request, > > > Abort-Session-Request, and Re-Auth-Request messages. > > > > > > 2. Update occurrence rule tables for the > "Auth-Application-Id AVP" > > > row, from "0" to "1", for STR and ASR and RAR. > > > > From owner-aaa-wg@merit.edu Wed Feb 27 01:55:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04427 for ; Wed, 27 Feb 2002 01:55:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A2217912D1; Wed, 27 Feb 2002 01:55:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AAFE912D2; Wed, 27 Feb 2002 01:55:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06ECB912D1 for ; Wed, 27 Feb 2002 01:55:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA0565DDD9; Wed, 27 Feb 2002 01:55:30 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 267865DDCA for ; Wed, 27 Feb 2002 01:55:30 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R6u1i28207 for ; Wed, 27 Feb 2002 08:56:01 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 08:55:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 08:55:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Deadline for comments on the Base spec Date: Wed, 27 Feb 2002 08:55:28 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A46@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Text, please Thread-Index: AcG/UHCEyZGjvKWYRsedZ/BY0HR45QACqAZQ From: To: X-OriginalArrivalTime: 27 Feb 2002 06:55:28.0851 (UTC) FILETIME=[BDB10A30:01C1BF5B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA04427 Hi all, In order to meet the March 1st deadline, I respectfully request all comments on open issues to be sent no later than Thursday close of businenss (West Coast time). On Friday, I have a flight to catch, which means that I won't have access to mail after 10 AM East Coast Time. I have time after that to submit the document, however. I will concentrate my time on Friday to actually edit the document. Please be precise in what text you want added and/or modified. We're quite close to finishing up here, so all help is appreciated. John From owner-aaa-wg@merit.edu Wed Feb 27 02:04:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06122 for ; Wed, 27 Feb 2002 02:04:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8DAD4912D4; Wed, 27 Feb 2002 02:03:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 408BD912D5; Wed, 27 Feb 2002 02:03:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DB47B912D4 for ; Wed, 27 Feb 2002 02:03:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id C18CD5DDCA; Wed, 27 Feb 2002 02:03:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 19BED5DD91 for ; Wed, 27 Feb 2002 02:03:17 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R73PZ20668 for ; Wed, 27 Feb 2002 09:03:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 09:03:15 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:03:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: base-08 reference to CMS-Cert AVP Date: Wed, 27 Feb 2002 09:03:15 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A4A@esebe004.NOE.Nokia.com> Thread-Topic: base-08 reference to CMS-Cert AVP Thread-Index: AcG+8ra/M4AFso5PRXWVmrzP90BciwAahhjw From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 07:03:15.0784 (UTC) FILETIME=[D4015C80:01C1BF5C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA06122 Hi Bob, Thanks, got it. John > -----Original Message----- > From: ext Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] > Sent: 26 February, 2002 20:23 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg > Subject: base-08 reference to CMS-Cert AVP > > > Hi John, > > base-08 Section 6.1.7 "Redirecting requests", says: > > > Redirect agents MAY also include the certificate of the servers in > > the Redirect-Host AVP(s). These certificates are encapsulated in a > > CMS-Cert AVP [11]. > > The above sentence references a CMS-Cert AVP. It looks like that > AVP has been removed from the CMS draft. Maybe "AAA-Node-Cert AVP" > is what should be above. > > Bob K. > > From owner-aaa-wg@merit.edu Wed Feb 27 02:14:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09345 for ; Wed, 27 Feb 2002 02:14:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0CDE8912D3; Wed, 27 Feb 2002 02:13:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C641B912D5; Wed, 27 Feb 2002 02:13:56 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE8ED912D3 for ; Wed, 27 Feb 2002 02:13:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id A534A5DD91; Wed, 27 Feb 2002 02:13:55 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id ED3125DDE0 for ; Wed, 27 Feb 2002 02:13:54 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7E2Z27235 for ; Wed, 27 Feb 2002 09:14:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 09:13:52 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:13:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [issue] Minor corrections to draft-base-08 Date: Wed, 27 Feb 2002 09:13:50 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D3F@esebe004.NOE.Nokia.com> Thread-Topic: [issue] Minor corrections to draft-base-08 Thread-Index: AcG+46yNP258OcgOSvq8qsFfr02bggAecHbg From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 07:13:50.0490 (UTC) FILETIME=[4E51CFA0:01C1BF5E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA09345 Hi Bob, > In Section 2.7 "Peer Table" > > > The Diameter Peer Table is used in message forwarding, > and referenced > > by the Realm Routing Table. A Peer Table entry contains > the following > > fields: > > - Host identity. following the conventions described for the > > DiameterIdentity derived AVP data format in section 4.4. This > > field contains the contents of the Origin-Host AVP > found in the > > CER or CEA message. > > - Status. This is the state of the peer entry, and > MUST match one > > of the values listed in section 5.6. > > - Role. This field specifies whether a peer is a primary, > > secondary or alternate. > > Remove the "-Role" entry. Section 5.1 makes the observation: "Note > that a given peer MAY act as a primary for a given realm, while acting > as a secondary for another realm." OK, change made. > > In Section 4.5.1 "Example AVP with a Grouped Data type" > > > The Example AVP (AVP Code 999999) is of type Grouped and > is used to > > clarify how Grouped AVP values work. The Grouped Data > field has the > > following ABNF grammar: > > > > Example-AVP ::= < AVP Header: 999999 > > > { Origin-Host } > > 1*{ Session-Id } > > *[ AVP ] > > > > An Example AVP with Grouped Data follows. > > > > The Origin-Host AVP is required. In this case: > > > > Origin-Host = "example.com". > > This example is just for illustrative purposes, but it might be better > if the Origin-Host value followed the syntax for DiameterIdentity > [whatever that is these days :) ]. Is something like this OK? Origin-Host = "aaa://host.abc.com;transport=tcp" > In Section 4.6 "Diameter Base Protocol AVPs" > > > AVP Section | | | > > Attribute Name Code Defined Data Type |MUST| MAY | > > -----------------------------------------|----+-----+ > > Firmware- 267 5.3.4 Unsigned32 | | P | > > Revision | | | > > Product-Name 269 5.3.7 UTF8String | | P | > > I think the 'P' should move from the MAY to the MUST NOT column for > AVPs that appear only in CER/CEA messages, such as Firmware-Revision > and Product-Name. To my understanding, at the time the CERs/CEAs are > exchanged, there couldn't yet be a security assocation between the > peers. Seems OK to make the change. > - - - - - > > In Section 8.9 "Authorization-Lifetime AVP" > > > A value of zero (0) means that immediate re-auth is > necessary by the > > access device. This is typically used in cases where multiple > > authentication methods are used, and a successful auth > response with > > this AVP set to one is used to signal that the next authentication > > Change "this AVP set to one" to "this AVP set to zero" in the > last line. OK, change made. > - - - - - > > In Section 8.10 "Auth-Grace-Period AVP" > > > This AVP MAY be provided by the client as a hint of the maximum > > lifetime that it is willing to accept. However, the > server MAY return > > a value that is equal to, or smaller, than the one provided by the > > client. > > Remove this paragraph entirely. This is a duplicate of the last > paragraph of the section 8.9; looks like a cut&paste error. Got it - change made > - - - - - > > In Section 10.2 "Accounting AVP Table" > > > Attribute Name | ACR | ACA | > > ------------------------------|-----+-----+ > > ... | ... | ... | > > Max-Time-Wait | 0+ | 0 | > > Remove the obsoleted Max-Time-Wait AVP entry. Got it - change made. Thanks! John From owner-aaa-wg@merit.edu Wed Feb 27 02:16:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10061 for ; Wed, 27 Feb 2002 02:16:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8F317912D5; Wed, 27 Feb 2002 02:15:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34223912D6; Wed, 27 Feb 2002 02:15:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 747B8912D5 for ; Wed, 27 Feb 2002 02:15:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 525CA5DDCA; Wed, 27 Feb 2002 02:15:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 914FB5DD91 for ; Wed, 27 Feb 2002 02:15:16 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7Fmi05112 for ; Wed, 27 Feb 2002 09:15:48 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 09:15:15 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:15:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 244: ELECTION_LOST result code Date: Wed, 27 Feb 2002 09:15:15 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A4D@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 244: ELECTION_LOST result code Thread-Index: AcG/EcH+VxE6Bd0PTPCwzwEGZ54xdAATLHhg From: To: , , X-OriginalArrivalTime: 27 Feb 2002 07:15:15.0509 (UTC) FILETIME=[80FEAE50:01C1BF5E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10061 Hi Kevin, > > I don't understand why this is being rejected. Is the ELECTION_LOST > > result code used anymore? > > Agreed. If memory serves, originally when a peer lost an > election, it would > send a CEA with a result code indicating success and then > immediately send a > DPR with a Disconnect-Cause indicating ELECTION_LOST. As a > result of the > last interop event, it was decided it would be better to just > send a CEA > with the ELECTION_LOST result code. Thus, the idea with this > issue was to > simply move this result code from the enumerated > Disconnect-Cause AVP into > the Result-Code AVP. Thanks for the clarification - I agree with the change, so I am removing this. John From owner-aaa-wg@merit.edu Wed Feb 27 02:20:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11334 for ; Wed, 27 Feb 2002 02:20:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FFB4912D6; Wed, 27 Feb 2002 02:19:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2176F912D7; Wed, 27 Feb 2002 02:19:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D86C912D6 for ; Wed, 27 Feb 2002 02:19:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id D843D5DDCA; Wed, 27 Feb 2002 02:19:45 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 30CE05DD91 for ; Wed, 27 Feb 2002 02:19:45 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7JrZ02030 for ; Wed, 27 Feb 2002 09:19:53 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 09:19:44 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:19:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 256: TLS Usage Issues Date: Wed, 27 Feb 2002 09:19:43 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A4E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 256: TLS Usage Issues Thread-Index: AcG/Cvb1Ql5Tomo4TkmBvPdmRC1afQAVCODw From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 07:19:43.0970 (UTC) FILETIME=[21029420:01C1BF5F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA11334 Hi Don, Can you suggest modified text? John > -----Original Message----- > From: ext Don Zick [mailto:dzick@interlinknetworks.com] > Sent: 26 February, 2002 23:16 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 256: TLS Usage Issues > > > The proposed text states that Diameter Clients act as TLS > clients and that > Diameter Servers act as TLS servers. I don't think this is > quite right. I > think the connection initiator acts as the TLS client and the > connection > acceptor acts as the TLS server. When two Diameter servers > connect, the > Diameter server that initiates the connection acts as the TLS > client. If a > Diameter client accepts a connetion from a Diameter server > then I think the > Diameter client should act as the TLS server. > > I think the connection initiator should be responsible for > initiating TLS > negotiations just as it is responsible for sending the > initial CER message. > > Don Z. > > john.loughney@nokia.com wrote: > > > Hi all, > > > > The proposed text seems sensible. Unless there are objections, I > > shall add this. > > > > John > > > > Issue 256: TLS Usage Issues > > Submitter name: Bernard Aboba aboba@internaut.com > > Submitter email address: aboba@internaut.com > > Date first submitted: 28-Dec-01 > > Reference: > > Document: base 08 > > Comment type: Technical > > Priority: S > > Section: 2.2 > > Rationale/Explanation of issue: > > There is no discussion of how TLS authentication is used with > > Diameter. For example: > > > > a. Are both peers required to support certificates? > > b. If not, how is it decided which peer authenticates to who? > > > > Proposed change: > > > > Add: > > > > "Diameter clients act as TLS clients according to > [RFC2246], and Diameter > > servers act as TLS servers. Diameter clients and servers > implementing > > TLS for security MUST mutually authenticate as part of TLS session > > establishment. In order to ensure mutual authentication, > Diameter servers > > MUST request certificates from Diameter clients, and the > client MUST be > > prepared to supply a certificate on request." > From owner-aaa-wg@merit.edu Wed Feb 27 02:27:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12805 for ; Wed, 27 Feb 2002 02:27:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2638F912D7; Wed, 27 Feb 2002 02:27:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3B23912E3; Wed, 27 Feb 2002 02:27:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE078912D7 for ; Wed, 27 Feb 2002 02:27:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C46D15DDCA; Wed, 27 Feb 2002 02:27:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 12CB65DD91 for ; Wed, 27 Feb 2002 02:27:38 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7S9i09217 for ; Wed, 27 Feb 2002 09:28:09 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:27:36 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:27:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 270 - closed Date: Wed, 27 Feb 2002 09:27:36 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A4F@esebe004.NOE.Nokia.com> Thread-Topic: Issue 270 - closed Thread-Index: AcG/YDrqfjMQncRISrSVI32xFTuNJQ== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:27:36.0902 (UTC) FILETIME=[3AE64660:01C1BF60] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12805 Hi all, Changes have been made. John Assigned #270 Hi In the peer state machine section 5.6.2 Events. The Rcv-Message Event states "A message other than CER,CEA,DWR, or DWA was received" In THIS definition DPR & DPA is missed out. suggestion --------- Sections 5.6.2 Events should have Rcv-Message " A message other than CER,CEA,DPR,DPA,DWR, or DWA was received" From owner-aaa-wg@merit.edu Wed Feb 27 02:29:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12837 for ; Wed, 27 Feb 2002 02:29:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D4FB912E3; Wed, 27 Feb 2002 02:29:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EECD6912E4; Wed, 27 Feb 2002 02:29:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3044912E3 for ; Wed, 27 Feb 2002 02:29:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAF0A5DDCA; Wed, 27 Feb 2002 02:29:14 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 266C15DD91 for ; Wed, 27 Feb 2002 02:29:14 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7TMZ07522 for ; Wed, 27 Feb 2002 09:29:22 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:29:13 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:29:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 271: comments needed Date: Wed, 27 Feb 2002 09:29:12 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A50@esebe004.NOE.Nokia.com> Thread-Topic: Issue 271: comments needed Thread-Index: AcG/YHRNpqB+cEqMQ3+RHDrUvQ4dgA== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:29:13.0044 (UTC) FILETIME=[74346140:01C1BF60] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12837 Hi all, I'd appreciate some comments on this, whether to make the changes or not. John Assigned #271 Submitter: Jari Arkko Date: January 3, 2002 Reference: Document: BASE-08 Comment type: T Priority: S Section: 8.2 Rationale/Explanation of issue: Sections 9.4 and 8.2 are in conflict. The former requires clients to store acct records during network outage, and the latter requires immediate sending. The specification is also silent on how the client devices know whether it should grant access during times of network outages towards the accounting server. I can imagine that in some cases we would like to stop services if we can't provide real-time accounting, while in some other cases we would like to continue. Furthermore, the state machine in 8.2 (as well as the one that I just posted) does not specify what to do when things happen to the session faster than what it takes for an ack to come back from the server. For instance, what should we do if the session is terminated while we are still waiting for the start ack? Proposed change: An AVP similar to the Accounting-Interim-Interval could be used to control whether access should be granted or discontinued upon problems in sending the accounting records. The state machine must be modified to consider what to do with session termination and interim record generation while we are still waiting to send previous data. 9.8.x. Accounting-Realtime-Required AVP The Accounting-Realtime-Required AVP (AVP Code TBD) is of type Enumerated and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide what to do if the sending of accounting records to the accounting server has been temporarily prevented due to, for instance, a network problem. DELIVER_AND_GRANT 1 The AVP with Value field set to DELIVER_AND_GRANT means that the service MUST only be granted as long as there is a connection to an accounting server. Note that the set of alternative accounting servers are treated as one server in this sense. Having to move the accounting record stream to a backup server is not a reason to discontinue the service to the user. GRANT_AND_STORE 2 The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in section 9.4. This is the default behaviour if the AVP isn't included in the reply from the authorization server. GRANT_AND_LOSE 3 The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records can not be delivered or stored. 8.2. Accounting State Machine Add the following new entries: PendingE Failure to send and buffer Store Idle space available Event Record PendingE Failure to send and no buffer Idle space available PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failure to send and (buffer Store Open space available or old record Interim can be overwritten) and Record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingD Failure to send and buffer Store Idle space available Stop Record PendingD Failure to send and no buffer Idle space available Idle Records in storage Send PendingB record PendingB Successful accounting answer Delete Idle received record From owner-aaa-wg@merit.edu Wed Feb 27 02:33:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12928 for ; Wed, 27 Feb 2002 02:33:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C55E912E5; Wed, 27 Feb 2002 02:33:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51F1B912E4; Wed, 27 Feb 2002 02:33:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 076D7912E5 for ; Wed, 27 Feb 2002 02:32:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id D21D25DDCA; Wed, 27 Feb 2002 02:32:55 -0500 (EST) 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 2BC3E5DD91 for ; Wed, 27 Feb 2002 02:32:55 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7WL318245 for ; Wed, 27 Feb 2002 09:32:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:32:53 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:32:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #272 - Separation of the prepaid and postpaid accounting sessions Date: Wed, 27 Feb 2002 09:32:53 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A51@esebe004.NOE.Nokia.com> Thread-Topic: Issue #272 - Separation of the prepaid and postpaid accounting sessions Thread-Index: AcG/YPfGF0s/WGUgR2qieb6JNIIdzQ== From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 07:32:53.0769 (UTC) FILETIME=[F7C45790:01C1BF60] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12928 Hi all, The consensus on this issue seemed to indicate that this change should not be made in the base spec, but could be addressed in an application document, so I considering this as a reject. John Issue #272 Description of issue: Separation of the prepaid and postpaid accounting sessions Submitter name: Juha-Pekka Koskinen Submitter email address: juha-pekka.koskinen@nokia.com Date first submitted: January 31, 2002 Reference: draft-hakala-diameter-credit-control-01.txt Document: Base (draft-ietf-aaa-diameter-08.txt) Comment type: T Priority: 1 Section: 9.5 and 9.8.1 Rationale/Explanation of issue: From owner-aaa-wg@merit.edu Wed Feb 27 02:35:39 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12957 for ; Wed, 27 Feb 2002 02:35:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E010A912E4; Wed, 27 Feb 2002 02:35:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A5D88912E6; Wed, 27 Feb 2002 02:35:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A424E912E4 for ; Wed, 27 Feb 2002 02:35:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A0D25DDCA; Wed, 27 Feb 2002 02:35:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id CD2D55DD91 for ; Wed, 27 Feb 2002 02:35:18 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7Zoi11574 for ; Wed, 27 Feb 2002 09:35:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:35:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:35:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 274 - closed Date: Wed, 27 Feb 2002 09:35:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A52@esebe004.NOE.Nokia.com> Thread-Topic: Issue 274 - closed Thread-Index: AcG/YU2VFtzLRt1jSO+IvXb7yNUluQ== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:35:17.0635 (UTC) FILETIME=[4D848D30:01C1BF61] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA12957 This has been added to the base spec. John Issue #274 From: David Frascone Date: Tue Feb 05 16:03:34 2002 An EXTREMELY minor nit . . . But . . . AAA should be defined in the terminology sections of all drafts. (The acronym is never broken down) From owner-aaa-wg@merit.edu Wed Feb 27 02:42:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13044 for ; Wed, 27 Feb 2002 02:42:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B15ED912E6; Wed, 27 Feb 2002 02:42:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7ECBE912E7; Wed, 27 Feb 2002 02:42:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7701D912E6 for ; Wed, 27 Feb 2002 02:42:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 610D15DDDA; Wed, 27 Feb 2002 02:42:25 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 759045DDD9 for ; Wed, 27 Feb 2002 02:42:24 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7gWZ14500 for ; Wed, 27 Feb 2002 09:42:32 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 09:42:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:42:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #275: Changes to state machine for ASR/ASA messages Date: Wed, 27 Feb 2002 09:42:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D40@esebe004.NOE.Nokia.com> Thread-Topic: Issue #275: Changes to state machine for ASR/ASA messages Thread-Index: AcG/YklCmU3FdUQ2TDO9C7lJ1VNurA== From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 07:42:23.0441 (UTC) FILETIME=[4B516410:01C1BF62] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13044 Hi Bob, Some clarification needed: The base spec has: Open Home server wants to send ASR Discon terminate the service Open ASR Received send ASA, Discon STR ..... Discon ASA Received Cleanup Idle Discon ASR Received None Discon Discon STR Received Send STA Idle Discon STA Received Discon. Idle user/device What do you want done with this? Open ASR Received send ASA, Discon STR John Issue #275 Issue : Changes to state machine for ASR/ASA messages Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-06-2002 Reference: Document: base-08 Comment type: Technical Priority: 1 Section: 8.1 Rationale/Explanation of issue: I believe there is an error in the "Authorization Session State Machine", in section 8.1 of the base draft, in the 1st state machine which represents the case where the server maintains session-state. If, for a session in OPEN state, the server wants the session to be be terminated, it sends an ASR and goes into DISCON state. When the ASA is received, the server goes into IDLE state. The state/events I am referring to are: | The following state machine is used when state is maintained on the | server: | | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Discon | terminate the service | | Discon ASA Received Cleanup Idle This seems not quite right for a few reasons. (1) When the server subsequently receives the follow-up STR from the access device, the session will be either non-existent or in IDLE state. (2) An ASR is only a request to terminate a session. It doesn't really go away until the session-timeout expires, the authorization-lifetime expires, or the access device sends an STR. So sending an ASR should not affect the server's state (OPEN), and receiving an ASA should in general not affect the server's state (OPEN). (3) The state machine doesn't take into account the Result-Code returned in the ASA. The draft indicates that an access device is not required to honor an ASR, i.e. the access device can just reply with "unable to comply" and not terminate the session. In this case the server would have incorrectly terminated an active session when receiving the negative ASA. When an ASR is sent, the Result-Code values likely to be returned in the ASA are: SUCCESS -- This means that the access device will be following the ASA with an STR, so the server can just wait for the STR. UNABLE_TO_COMPLY -- The access device has no intention of terminating the session. UNKNOWN_SESSION_ID -- The access device doesn't know about this session. Somehow the access device and server have gotten out of sync. The server can go ahead an clean up this phantom session. UNABLE_TO_DELIVER -- The ASR never made it to the access device, so the access device won't be terminating this session, if it even exists. Requested change: Replace the two entries: | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Discon | terminate the service | | Discon ASA Received Cleanup Idle With: | State Event Action New State | ------------------------------------------------------------- | | Open Home server wants to send ASR Open | terminate the service | | Open ASA Received Cleanup Idle | with Result-Code | = UNKNOWN-SESSION-ID | | Open ASA Received None Open | with Result-Code (ignore) | not = UNKNOWN-SESSION-ID | | Not ASA Received None No Change. | Open Notes on the above four entries (this is FYI, not part of draft): Entry#1. The ASR doesn't do anything on its own, so just stay in OPEN state and wait for the ASA. Entry#2. This is the case where the server is out of sync with the access device. This is a phantom session that the server can remove. Entry#3. If SUCCESS, the access device will soon send an STR, which will terminate the session. If not SUCCESS, the access device won't be terminating the session, so it stays active. Entry#4. Here something happened to the session between the time the ASR was sent and the ASA was received. From owner-aaa-wg@merit.edu Wed Feb 27 02:48:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13092 for ; Wed, 27 Feb 2002 02:48:05 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA2C8912E8; Wed, 27 Feb 2002 02:46:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A1556912EA; Wed, 27 Feb 2002 02:46:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 576F5912E8 for ; Wed, 27 Feb 2002 02:46:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DBEA5DDCA; Wed, 27 Feb 2002 02:46:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 8C3CA5DD91 for ; Wed, 27 Feb 2002 02:46:35 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7khZ16439 for ; Wed, 27 Feb 2002 09:46:44 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:46:34 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:46:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #275: Changes to state machine for ASR/ASA messages (take 2) Date: Wed, 27 Feb 2002 09:46:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A54@esebe004.NOE.Nokia.com> Thread-Topic: Issue #275: Changes to state machine for ASR/ASA messages (take 2) Thread-Index: AcG/YuAlIJkFYQc0RjCoapi30yYmpw== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:46:33.0272 (UTC) FILETIME=[E03A9380:01C1BF62] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13092 Hi all, Ignore my previous mail on this issue, I mistook the ASA for ASR. I need more coffee. I agree with Bob, so the changes are added. John From owner-aaa-wg@merit.edu Wed Feb 27 02:51:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13135 for ; Wed, 27 Feb 2002 02:51:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2B4A9912E9; Wed, 27 Feb 2002 02:51:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0F30912EA; Wed, 27 Feb 2002 02:51:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED37A912E9 for ; Wed, 27 Feb 2002 02:51:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id D64615DD91; Wed, 27 Feb 2002 02:51:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E2BCB5DDD9 for ; Wed, 27 Feb 2002 02:51:09 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7pEZ19199 for ; Wed, 27 Feb 2002 09:51:14 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:51:05 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:51:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #277: session-id & user-name AVPs; NASREQ inconsistancies - CLOSED Date: Wed, 27 Feb 2002 09:51:05 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D41@esebe004.NOE.Nokia.com> Thread-Topic: Issue #277: session-id & user-name AVPs; NASREQ inconsistancies - CLOSED Thread-Index: AcG/Y4JKu4Be5fQgT9qyRN7TC4bsFw== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:51:05.0046 (UTC) FILETIME=[8237FF60:01C1BF63] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13135 Hi all, Agreed, 9.5 modified to read: In all accounting records, the Session-Id AVP MUST be present; the User-Name AVP MUST be present if it is available to the Diameter client. John Issue #277 Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: base, nasreq Comment type: E Priority: 2 Section: 9.5, 9.7.1, 9.7.2, nasreq 10.2 Rationale/Explanation of issue: Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present.". However, the Diameter node sending the accounting request may not know it. Still the target can use the various session-ID AVPs to correlate the records. There also seems to be some inconsistency in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2 (ACR, ACA definition) User-Name AVP is marked as optional while in section 10.2 it is again specified as MUST. Proposed change: I suggest modifying 9.5 so that it reads. "User-Name AVP MUST be present if it is available to the Diameter client." Then change the tables in 10.2 as follows: User-Name | 0+ | 0+ | From owner-aaa-wg@merit.edu Wed Feb 27 02:56:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13194 for ; Wed, 27 Feb 2002 02:56:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0EAC4912EA; Wed, 27 Feb 2002 02:56:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC2E7912EB; Wed, 27 Feb 2002 02:56:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BA49F912EA for ; Wed, 27 Feb 2002 02:56:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9783D5DDCA; Wed, 27 Feb 2002 02:56:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id E5C475DD91 for ; Wed, 27 Feb 2002 02:56:18 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7uRZ22422 for ; Wed, 27 Feb 2002 09:56:27 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:56:18 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:56:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Date: Wed, 27 Feb 2002 09:56:16 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D42@esebe004.NOE.Nokia.com> Thread-Topic: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Thread-Index: AcG/ZDwtaQcGa3NUR8KDfbA2lGdntQ== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:56:17.0059 (UTC) FILETIME=[3C316730:01C1BF64] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13194 Jari, I can add the text to secion 4.6, though the change: Move the last paragraph of 3.1 to the end of 2.0, where I think it would be easier to find. seem to be unclear / unnescessary. John Issue #279 Submitter name: Jari Arkko (Sebastian Zander) Submitter email address: jari@arkko.com Date first submitted: Feb 10, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html Document: cms, base Comment type: E Priority: 2 Section: base 4.6, cms 2.0, 3.1, 5.0 Rationale/Explanation of issue: 1) Base does not sufficiently explain what 'MAY encrypt' means in the AVP tables. Does it mean that it where CMS is used for the particular message, the AVPs MAY be encrypted, or does it mean that if CMS is used, they MUST be encrypted? 2) CMS flow example in 5.0 is misleading as to how the set of protected AVPs is decided. 3) There are several references to somehow negotiating the AVPs to be signed/encrypted. We have removed such functionality since this is really static information. Proposed change: 1) Add to the end of the first paragraph in base 4.6: "If an AVP MAY be encrypted, section 2.0 of the Diameter CMS security extension [11] defines in which situations the encryption is actually employed." Move the last paragraph of 3.1 to the end of 2.0, where I think it would be easier to find. In cms 3.1, change the text ", which specifies which AVPs should be encrypted, signed or both, as well as which public key(s) to use." to ", which specifies which public key(s) to use for signing and encryption of AVPs." Also, in cms 5.0, remove the last sentence of step (f). And the last sentence of (g). In step (h) change "which authenticates the AVPs that were requested by the Home Server in the DSAA." to "which authenticates the AVPs that MUST be authenticated as defined in section 2.0." In step (i) change "whose contents include the AVPs that were specified by the NAS in the DSAR." to "whose contents include the AVPs that MUST be encrypted as defined in section 2.0." From owner-aaa-wg@merit.edu Wed Feb 27 02:58:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13220 for ; Wed, 27 Feb 2002 02:58:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6DFC1912EB; Wed, 27 Feb 2002 02:58:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 229A8912EC; Wed, 27 Feb 2002 02:58:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 91931912EB for ; Wed, 27 Feb 2002 02:58:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 787CB5DDDD; Wed, 27 Feb 2002 02:58:27 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 80B9A5DDEC for ; Wed, 27 Feb 2002 02:58:26 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R7wYZ23851 for ; Wed, 27 Feb 2002 09:58:34 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 09:58:25 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 09:58:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #280 is a clone of 277 Date: Wed, 27 Feb 2002 09:58:25 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A57@esebe004.NOE.Nokia.com> Thread-Topic: Issue #280 is a clone of 277 Thread-Index: AcG/ZIii4CFkUZ/XTOGdle1NmFQJCg== From: To: X-OriginalArrivalTime: 27 Feb 2002 07:58:25.0135 (UTC) FILETIME=[88883FF0:01C1BF64] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA13220 Hi all, I'm marking 280 as reject, as it is a clone of issue 277 which has been handled. John Issue #280 Submitter name: Sebastian Zander Submitter email address: zander@fokus.fhg.de Date first submitted: February 11th, 2002 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg02998.html Document: base-08 Comment type: T Priority: 1 Section: 9.5, 10.2 Rationale/Explanation of issue: Section 9.5 of base-08 reads: "In all accounting records the Session-Id and User-Name AVPs MUST be present." The Diameter client may not know the user's identity. Therefore there can not be a MUST for including it. Furthermore there is some inconsistency in the draft since the User-Name AVP is already marked optional in section 9.7.1 and 9.7.2 but mandatory in section 10.2. Requested change: Section 9.5 should be changed to: "In all accounting records the Session-Id AVP MUST be present. The User-Name AVP MUST be present if it is available to the Diameter client." The table in section 10.2 should be changed so that User-Name is optional. -- Sebastian From owner-aaa-wg@merit.edu Wed Feb 27 03:01:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13292 for ; Wed, 27 Feb 2002 03:01:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1B541912EC; Wed, 27 Feb 2002 03:00:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B2FA912ED; Wed, 27 Feb 2002 03:00:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED270912EC for ; Wed, 27 Feb 2002 03:00:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF8285DDCA; Wed, 27 Feb 2002 03:00:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id C94C95DD91 for ; Wed, 27 Feb 2002 03:00:33 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R815i20022 for ; Wed, 27 Feb 2002 10:01:05 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:00:32 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:00:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #281: Section: 5.6 "Peer State Machine" - CLOSED Date: Wed, 27 Feb 2002 10:00:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A58@esebe004.NOE.Nokia.com> Thread-Topic: Issue #281: Section: 5.6 "Peer State Machine" - CLOSED Thread-Index: AcG/ZNSG1M/fi9buRJSAesg70S2g9A== From: To: X-OriginalArrivalTime: 27 Feb 2002 08:00:32.0791 (UTC) FILETIME=[D49F0270:01C1BF64] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13292 Hi all, This issue is closed, text added: This state machine is closely coupled with the state machine described in [AAATRANS], which is used to open, close, failover, probe, and reopen transport connections. Note in particular that [AAATRANS] requires the use of watchdog messages to probe connections. For Diameter, DWR and DWA messages are to be used. John Issue #281 Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: February 11th, 2002 Reference: none Document: base-08alpha02 Comment type: Editorial Priority: 1 Section: 5.6 "Peer State Machine" Rationale/Explanation of issue: There are a couple of references in this section to "the state machine described in [52]". However, in the latest version of the transport draft, such a state machine is not present. Requested change: Remove these references in the text. From owner-aaa-wg@merit.edu Wed Feb 27 03:11:34 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13445 for ; Wed, 27 Feb 2002 03:11:33 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 16D4D912F7; Wed, 27 Feb 2002 03:08:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E69BA912F6; Wed, 27 Feb 2002 03:05:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 03CFD912ED for ; Wed, 27 Feb 2002 03:03:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id D9B6E5DDCA; Wed, 27 Feb 2002 03:03:01 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id F375C5DD91 for ; Wed, 27 Feb 2002 03:03:00 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R839Z26744 for ; Wed, 27 Feb 2002 10:03:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:02:59 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:02:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 282: allow redirect agents to have the option of providing user to server address resolution - closed Date: Wed, 27 Feb 2002 10:02:59 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A59@esebe004.NOE.Nokia.com> Thread-Topic: Issue 282: allow redirect agents to have the option of providing user to server address resolution - closed Thread-Index: AcG/ZSw3KycwvIg7Sc6Ouappl9aOhw== From: To: X-OriginalArrivalTime: 27 Feb 2002 08:02:59.0909 (UTC) FILETIME=[2C4F6F50:01C1BF65] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13445 Hi all, Consensus seems to indicate the text is warrented. Change made. John Issue #282 Submitter name: Kevin Purser Submitter email address: kevin.purser@ericsson.com Date first submitted: February 14th, 2002 Reference: none Document: base-08alpha02 Comment type: Technical Priority: 1 Sections: 2.9.3, 6.12 Rationale/Explanation of issue: Diameter redirect agents currently provide realm to server address resolution. Within a single administrative domain, it could be useful to allow redirect agents to have the option of providing user to server address resolution. Requested change: * change the first paragraph of section 2.9.3 to read: Redirect agents provide Realm to Server address resolution and MAY also provide User to Server address resolution. These redirect agents would make use of the Diameter routing table or optionally, a user table to determine where a given request should be forwarded. When a request is received by a redirect agent, a special answer is created, which includes the identity of the Diameter server(s) the originator of the request should contact directly. * add the following enumerated value in section 6.12: ALL_USER 6 All messages for the user requested MAY be sent to the host specified in the Redirect-Host AVP. From owner-aaa-wg@merit.edu Wed Feb 27 03:12:00 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13483 for ; Wed, 27 Feb 2002 03:11:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 57D86912F1; Wed, 27 Feb 2002 03:08:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AD4A912F6; Wed, 27 Feb 2002 03:08:16 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5C96912F2 for ; Wed, 27 Feb 2002 03:04:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id B74EA5DDCA; Wed, 27 Feb 2002 03:04:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C48E85DD91 for ; Wed, 27 Feb 2002 03:04:16 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R84PZ27371 for ; Wed, 27 Feb 2002 10:04:25 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:04:15 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:04:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: issue 283: Usage of TLS vs. IPsec CLOSED Date: Wed, 27 Feb 2002 10:04:15 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A5A@esebe004.NOE.Nokia.com> Thread-Topic: issue 283: Usage of TLS vs. IPsec CLOSED Thread-Index: AcG/ZVlQIE/CAScRQYSSz16tYPWmcQ== From: To: X-OriginalArrivalTime: 27 Feb 2002 08:04:15.0431 (UTC) FILETIME=[59532D70:01C1BF65] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13483 Issue #283 Hi all, Consensus indicated text change OK. John Description of issue: Usage of TLS vs. IPsec Submitter name: John Loughney Submitter email address: john.loughney@nokia.com Date first submitted: 18 Feb 2002 Reference: Document: Base Comment type: T Priority: 1 Section: 2.2 Rationale/Explanation of issue: Usage of TLS and IPsec. Aside from more detail on how to use TLS and IPsec, it was noted that the drafts do not say that IPsec is for Intra-domain use and TLS for inter-domain. In practice, IKE isn't very interoperable when used with certs, and can't support the required cert policies very well. TLS has this nailed. Should we say that IPsec is primarily for use with pre-shared keys and only intra-domain, and TLS is for cert usage and inter-domain? Should we adjust the language (TLS as MUST on client, too?) Issue to be filed and raised on the mailing list. Requested change: Proposal Add the following text: Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SEC ARCH], and SHOULD support TLS [TLS]. Diameter servers MUST support TLS and IPSec. Operating the Diameter protocol without any security mechanism is not recommended. It is suggested that IPsec is primarily for use with pre-shared keys and to protect intra-domain traffic. TLS is for certificate usage and to project inter-domain traffic. John From owner-aaa-wg@merit.edu Wed Feb 27 03:12:18 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13494 for ; Wed, 27 Feb 2002 03:12:18 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7B3B4912F6; Wed, 27 Feb 2002 03:08:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A8BF3912F9; Wed, 27 Feb 2002 03:08:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9289A912F6 for ; Wed, 27 Feb 2002 03:08:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 748CE5DDCA; Wed, 27 Feb 2002 03:08:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 34D1C5DD91 for ; Wed, 27 Feb 2002 03:08:39 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R88lZ00417 for ; Wed, 27 Feb 2002 10:08:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:08:31 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:08:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue #285: Accouting AVP issue... REJECT for Base spec Date: Wed, 27 Feb 2002 10:08:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A5B@esebe004.NOE.Nokia.com> Thread-Topic: Issue #285: Accouting AVP issue... REJECT for Base spec Thread-Index: AcG/ZfAuqFgs5pKuQaKWaOAu6zElnw== From: To: X-OriginalArrivalTime: 27 Feb 2002 08:08:29.0343 (UTC) FILETIME=[F0AB12F0:01C1BF65] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13494 Hi all, The consensus was that this issue would be aligned & referenced between the application documents & would not affect the base spec. John Issue #285 Accouting AVP issue... From: Tony Johansson Date: Tue Feb 19 14:30:15 2002 All, In my efforts to update the Diameter MIPv4 application I have stumble on the Accounting AVPs defined and realized that exactly the same AVPs are defined also in the NASREQ application, see below. Unless I have misunderstood something, I would suggest that we move these AVPs to the Base, since they are used by both NASREQ and MIP. From owner-aaa-wg@merit.edu Wed Feb 27 03:12:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13516 for ; Wed, 27 Feb 2002 03:12:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 26EF9912ED; Wed, 27 Feb 2002 03:12:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 892F9912F3; Wed, 27 Feb 2002 03:12:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 805B1912EF for ; Wed, 27 Feb 2002 03:12:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D6CF5DDCA; Wed, 27 Feb 2002 03:12:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 67A9A5DDDC for ; Wed, 27 Feb 2002 03:12:23 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R8CQZ03245 for ; Wed, 27 Feb 2002 10:12:30 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:12:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:12:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 241: Accounting issues - need closure Date: Wed, 27 Feb 2002 10:12:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A5C@esebe004.NOE.Nokia.com> Thread-Topic: Issue 241: Accounting issues - need closure Thread-Index: AcG/Zngg+d37xsYFSaO6HBstPDl4Eg== From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 08:12:17.0365 (UTC) FILETIME=[78947850:01C1BF66] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13516 Hi all, I have the following comment on this: Sub 1&4 accepted, sub 2 discussed, sub 3 clarification request sent to list. Could someone provide a summary where we stand and what text needs to be added? John Issue 241: Accounting issues Submitter name: Jaakko Rajaniemi Submitter email address: jaakko.rajaniemi@nokia.com Date first submitted: 2001-11-12 Document: base Comment type: T Priority: 1 Section: 9.6, 8.2, 9.3 Rationale/Explanation of issue: It says in the section 9.6 "Correlation of Accounting Records" that the correlation for accounting sub-sessions is performed using the Session-Id. Is this correct? Aren't both the Accounting-Sub-Session-Id and Session-Id used for the correlation? I think that it is not possible to terminate one or several accounting sub-session from the server side. Only all accounting sub-sessions can be terminated by using the Abort-Session command. Is this left for each application to handle or should this possibility be in the base protocol? The accounting state machine in the section 8.2 describes that the accounting session is terminated by the action where the accounting stop request is sent. It is not totally clear what the accounting stop request here can mean. I think that it only describes the case where the accounted service is a one-time event (where EVENT_RECORD is sent and the ACA terminates the session) and a measurable length accounting service (where STOP_RECORD is sent to terminate the session). However, it seems to be missing the server initiated termination by the Abort-Session command. This application document requirements for accounting were discussed some time ago and I proposed a change to the section 9.3 which got some support, but not get to the base-08. The issue is that because it is possible that a service makes only use of the Accounting portion of the Diameter application then the application must clearly described in the application specification which part contains the accounting portion. The current text describes in the section 9.3 (Application document requirements) clearly how new accounting AVPs must be described in new applications but it does not say anything how new accounting command codes should be described. One way to guarantee that this is clearly described in the new applications is to modify the section 9.3 according to the changes proposed in the Requested change part below. Requested change: The change to the section 9.3, the Application document requirements: "Each Diameter application (e.g. NASREQ, MobileIP), MUST define their Service-Specific accounting part in a section entitled "Accounting". Under the section "Accounting" they MUST define their Service-Specific AVPs that MUST be present in the Accounting-Request message in a section entitled "Accounting AVPs" and their Service-Specific command codes if exists in a section entitled "Accounting Command-Codes". The application MUST assume that the AVPs described in this document will be present in all Accounting messages, so only their respective service-specific AVPs need to be defined in this section." If the above change is adopted then it would require some minor editing to the NASREQ and Mobile IP application. For other question changes are still open. From owner-aaa-wg@merit.edu Wed Feb 27 03:20:25 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13647 for ; Wed, 27 Feb 2002 03:20:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C85E5912EF; Wed, 27 Feb 2002 03:19:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7B656912F2; Wed, 27 Feb 2002 03:19:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CD19912EF for ; Wed, 27 Feb 2002 03:19:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E3605DDCA; Wed, 27 Feb 2002 03:19:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 53B805DD91 for ; Wed, 27 Feb 2002 03:19:50 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1R8KMi28026 for ; Wed, 27 Feb 2002 10:20:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 10:19:49 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 10:19:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Base Spec status Date: Wed, 27 Feb 2002 10:19:49 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A5D@esebe004.NOE.Nokia.com> Thread-Topic: Base Spec status Thread-Index: AcG/Z4UuwbTkOXgXQiS9HjvIMOElDQ== From: To: X-OriginalArrivalTime: 27 Feb 2002 08:19:49.0046 (UTC) FILETIME=[85CD8560:01C1BF67] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA13647 Hi all, As of Wednesday March 27, 2002 3:20 AM Eastern Time (10:20 AM local time) Here is the status of the issues on the Diameter base spec. Open Issues: 235, 241, 252, 253, 254, 256, 262, 263, 271, 273. Issues can be found from: http://www.drizzle.com/~aboba/AAA/issues.html http://www.drizzle.com/~aboba/AAA/newissues.txt Please comment! John ==== old issues ==== OPEN Issue #235 (base) Duplicates detection OPEN Issue #241 (base) Accounting issues. Sub 1&4 accepted, sub 2 discussed, sub 3 clarification request sent to list. REJECT Issue #243 (base) Session State Machine for Diameter agents CLOSED Issue #244 (base) ELECTION_LOST result code CLOSED Issue #245 (base) Base 08 REJECT Issue #248 (base) hex or decimal CLOSED Issue #249 (base) editorial nits CLOSED Issue #250 (all) Normative vs Informative OPEN Issue #252 (base) Granting Access via Accounting OPEN Issue #253 (base) Diameter Peer discovery (diffs sent) OPEN Issue #254 (base) IPsec usage OPEN Issue #256 (base) Tls usage CLOSED Issue #257 (base/tran) Transport/base inconsistencies CLOSED Issue #259 (base) Simple editorial CLOSED Issue #260 (base) SNTP referencing CLOSED Issue #261 (base) Peer discovery mechanism requirements OPEN Issue #262 (base) Diameter node must use its own TLS certificate OPEN Issue #263 (base) Mandate required TLS cipher suites CLOSED Issue #268 (base) Diameter Extensibility CLOSED Issue #269 (base) Diameter -07 introduction needs improvement ==== new issues ==== CLOSED Issue #270 (base) Sections 5.6.2 - Rcv-Message - add DPR,DPA OPEN Issue #271 (base) Sections 9.4 and 8.2 are in conflict. REJECT Issue #272 (base) Separation of the prepaid and postpaid accounting sessions OPEN Issue #273 (base) TLS & SRV usage to be fixed & DNS SRV text needs to be updated CLOSED Issue #274 (all) Add AAA to terminology CLOSED Issue #275 (base) Changes to state machine for ASR/ASA messages CLOSED Issue #277:(base) session-id & user-name AVPs; NASREQ inconsistancies CLOSED Issue #279 (base,cms) Base does not sufficiently explain what 'MAY encrypt means REJECT Issue #280 (base) close of 277 CLOSED Issue #281 (base) transport state references CLOSED Issue #282 (base) allow redirect agents to have the option of providing user to server address resolution. CLOSED Issue #283 (base) Usage of TLS vs. IPsec REJECT Issue #284 (base) Accouting AVP issue... From owner-aaa-wg@merit.edu Wed Feb 27 05:31:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15767 for ; Wed, 27 Feb 2002 05:31:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 681FB912F9; Wed, 27 Feb 2002 05:31:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3174A912FA; Wed, 27 Feb 2002 05:31:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D580912F9 for ; Wed, 27 Feb 2002 05:30:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCE235DDDF; Wed, 27 Feb 2002 05:30:58 -0500 (EST) 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 A6E695DD91 for ; Wed, 27 Feb 2002 05:30:58 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 232F96A901; Wed, 27 Feb 2002 12:30:33 +0200 (EET) Message-ID: <3C7CB594.1020006@kolumbus.fi> Date: Wed, 27 Feb 2002 12:31:48 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D42@esebe004.NOE.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 john.loughney@nokia.com wrote: > Jari, > > I can add the text to secion 4.6, though the change: > > Move the last paragraph of 3.1 to the end of 2.0, where I > think it would be easier to find. > > seem to be unclear / unnescessary. Sure, I don't care really that much where it is. As long as it is explicitly referenced from the base 4.6. Preferrably also very visible on the CMS document, but what is very visible is of course debatable... Jari From owner-aaa-wg@merit.edu Wed Feb 27 06:07:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16198 for ; Wed, 27 Feb 2002 06:07:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 897979120F; Wed, 27 Feb 2002 06:07:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B68991229; Wed, 27 Feb 2002 06:07:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AD629120F for ; Wed, 27 Feb 2002 06:07:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1239F5DDDC; Wed, 27 Feb 2002 06:07:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 560975DDDA for ; Wed, 27 Feb 2002 06:07:43 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RB8Fi07876 for ; Wed, 27 Feb 2002 13:08:15 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:07:42 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:07:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 13:07:41 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A62@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQDrFsiA From: To: , X-OriginalArrivalTime: 27 Feb 2002 11:07:42.0015 (UTC) FILETIME=[F9C29CF0:01C1BF7E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16198 Hi All, > The problem is that the URI format is currently defined in > only one place (sec. 4.4 under the "DiameterIdentity" type) and makes no > distinction between its use for the two different purposes > described above. I propose the following resolution for defining the aaa URI ==> clarification, is this a AAA URI or Diameter URI or ..? <== 2.9 Diameter URI The Diameter URI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below: "aaa[ transport-security ]://" fqdn [ port ] [ transport ] [ protocol ] transport-security = ( "" | "s" ) ; If absent, the default, no transport security ; is assumed. fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (TBD) is ; assumed. transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [SCTP] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. transport-protocol = ( "tcp" | "sctp" | "udp" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) The following are examples of valid Diameter host identities: aaa://host.abc.com;transport=tcp aaa://host.abc.com:6666;transport=tcp aaa://host.abc.com;protocol=diameter aaa://host.abc.com:6666;protocol=diameter aaa://host.abc.com:6666;transport=tcp;protocol=diameter aaa://host.abc.com:1813;transport=udp;protocol=radius aaas://host.abc.com;transport=tcp aaas://host.abc.com;protocol=diameter John From owner-aaa-wg@merit.edu Wed Feb 27 06:11:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16268 for ; Wed, 27 Feb 2002 06:11:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A1A1891229; Wed, 27 Feb 2002 06:11:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77AF4912D9; Wed, 27 Feb 2002 06:11:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 695E791229 for ; Wed, 27 Feb 2002 06:11:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 48E125DDDC; Wed, 27 Feb 2002 06:11:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 684155DDDA for ; Wed, 27 Feb 2002 06:11:34 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBC6i09253 for ; Wed, 27 Feb 2002 13:12:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:10:28 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:10:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Issue 273 Resolution Date: Wed, 27 Feb 2002 13:10:27 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A63@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG+AnT6EYmc+nozQYCZZazb8ZM7BgBfJy3w From: To: Cc: , X-OriginalArrivalTime: 27 Feb 2002 11:10:28.0145 (UTC) FILETIME=[5CC80A10:01C1BF7F] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16268 Hi all, Here is my proposed resolution on issue 27. Please note that the IESG has review Diameter's use of SRV records and found them to be incorrect. This is based on the currently approved method for using SRV records (see the SIP SRV document). 5.2 Diameter Peer Discovery . . . . 3. The Diameter implementation performs a NAPTR query for a server in a particular realm. The Diameter implementation has to know in advance which realm to look for a Diameter agent in. This could be deduced, for example, from the 'realm' in a NAI that a Diameter implementation needed to perform a Diameter operation on. 3.1 The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "AAA+D2x" and "AAAS+D2X", where x is a letter that corresponds to a transport protocol supported by the domain. This specification defines D2T for TCP and D2S for SCTP. We also establish an IANA registry for NAPTR service name to transport protocol mappings. These NAPTR records provide a mapping from a domain, to the SRV record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record will contain an empty regular expression and a replacement value, which is the SRV record for that particular transport protocol. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per RFC 2915 [NAPTR], the client discards any records whose services fields are not applicable. For the purposes of this specification, several rules are defined. 3.1 First, a client resolving a AAAS URI MUST discard any services that do not contain "AAAS" as the protocol in the service field. The converse is not true, however. A client resolving an AAA URI SHOULD retain records with "AAAS" as the protocol, if the client supports TLS. Second, a client MUST discard any service fields that identify a resolution service whose value is not "D2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 2915 will result in discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server. It will also allow the client to discover if TLS is available and its preference for its usage. The domain suffixes in the NAPTR replacement field SHOULD match the domain of the original query. It is not necessary for the domain suffixes in the NAPTR replacement field to match the domain of the original query. 3.3 If no NAPTR records are found, the requester queries for those address records for the destination address, '_diameters._sctp'.realm or '_diameters._tcp'.realm when using TLS or '_diameter._sctp'.realm or '_diameter._tcp'.realm when not using TLS. Address records include A RR's, AAAA RR's or other similar records, chosen according to the requestor's network protocol capabilities. If the DNS server returns no address records, the requestor gives up. For NAPTR records with AAAS protocol fields, if the server is using a site certificate, the domain name in the query and the domain name in the replacement field MUST both be valid based on the site certificate handed out by the server in the TLS exchange. Similarly, the domain name in the SRV query and the domain name in the target in the SRV record MUST both be valid based on the same site certificate. Otherwise, an attacker could modify the DNS records to contain replacement values in a different domain, and the client could not validate that this was the desired behavior, or the result of an attack. A dynamically discovered peer causes an entry in the Peer Table (see section 2.7) to be created. Note that entries created via DNS MUST expire (or be refreshed) within the DNS TTL. If a peer is discovered outside of the local realm, a routing table entry (see Section 2.8) for the peer's realm is created. The routing table entry's expiration MUST match the peer's expiration value. Add to references: [NAPTR] M. Mealling and R. Daniel, "The naming authority pointer (NAPTR) DNS resource record," Request for Comments 2915, Internet Engineering Task Force, Sept. 2000. [TLSSCTP] M. Tuexen, et al. "TLS over SCTP" IETF Work in Progress, November 2001. Appendix B: NAPTR Example As an example, consider a client that wishes to resolve aaa:example.com. The client performs a NAPTR query for that domain, and the following NAPTR records are returned: ;; order pref flags service regexp replacement IN NAPTR 20 50 "s" "AAAS+D2S" "" _diameters._sctp.example.com. IN NAPTR 50 50 "s" "AAA+D2S" "" _diameter._sctp.example.com. IN NAPTR 90 50 "s" "AAAS+D2T" "" _diameters._tcp.example.com. IN NAPTR 100 50 "s" "AAA+D2T" "" _diameter._tcp.example.com This indicates that the server supports TLS over SCTP, SCTP, TLS over TCP, and TCP, in that order. If the client supports TLS over SCTP, SCTP will be used, targeted to a host determined by an SRV lookup of _diameters._sctp.example.com. That lookup would return: ;; Priority Weight Port Target IN SRV 0 1 5060 server1.example.com IN SRV 0 2 5060 server2.example.com From owner-aaa-wg@merit.edu Wed Feb 27 06:18:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16378 for ; Wed, 27 Feb 2002 06:18:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3980E912D9; Wed, 27 Feb 2002 06:18:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 00E6D912FA; Wed, 27 Feb 2002 06:18:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96D14912D9 for ; Wed, 27 Feb 2002 06:17:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 68CFF5DDDC; Wed, 27 Feb 2002 06:17:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 7AC155DDDA for ; Wed, 27 Feb 2002 06:17:42 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBHoZ22358 for ; Wed, 27 Feb 2002 13:17:50 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:17:41 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:17:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 13:17:40 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D44@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQDrSCQg From: To: , Cc: X-OriginalArrivalTime: 27 Feb 2002 11:17:40.0811 (UTC) FILETIME=[5EABA1B0:01C1BF80] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16378 Hi David, Would the changes suggest inline be sufficiengt: > Requested change: > > Define the format of the URI somewhere other than section 4.4. In > the definition of the DiameterIdentity type in section 4.4, specify > that only the prefix, fqdn, and port number portions of the URI are > included in AVP value fields of this type. The sentences cited above > may now be left in section 4.4 because they no longer cause a > problem. DiameterIdentity = "aaa://" fqdn [ port ] fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (TBD) is ; assumed. ; A single port number MUST be used ; in all AVPs of type DiameterIdentity. > If the URI prefix may either be aaa: or aaas: depending on transport > security, then text should be added to section 6 stating that when > matching URIs for routing purposes, the "s" in aaas: should be > dropped before the compare is made. My feeling is that for DiameterIdentity, we do not need to discriminate aaa vs. aaas. John From owner-aaa-wg@merit.edu Wed Feb 27 06:19:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16395 for ; Wed, 27 Feb 2002 06:19:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F036C912FA; Wed, 27 Feb 2002 06:18:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1AC3912FB; Wed, 27 Feb 2002 06:18:52 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBF34912FA for ; Wed, 27 Feb 2002 06:18:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A405E5DDDA; Wed, 27 Feb 2002 06:18:51 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id A04035DDDC for ; Wed, 27 Feb 2002 06:18:50 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBImZ22961 for ; Wed, 27 Feb 2002 13:18:48 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:18:39 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:18:39 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 13:18:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Wed, 27 Feb 2002 13:18:38 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF2718401682490@trebe002.NOE.Nokia.com> Thread-Topic: Issue 271: comments needed Thread-Index: AcG/YHRNpqB+cEqMQ3+RHDrUvQ4dgAAHeNpg From: To: , Cc: X-OriginalArrivalTime: 27 Feb 2002 11:18:39.0217 (UTC) FILETIME=[817BAE10:01C1BF80] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16395 Hi, I think some change related to this issue is needed. As Jari has stated: "..in some cases we would like to stop services if we can't provide real-time accounting, while in some other cases we would like to continue." That was also in my mind when I suggested issue 272. There is cases where the accounting records could simply be stored by the client if the accounting server doesn't response even to intial ACR but in some cases the services must be stopped if ACA is not received. That was the reason I proposed new Accounting-Record-Type values 5-8. When these values (5-8) is sent in ACR, the service must be stopped if ACA is not received. Any other comments?? br, JPK -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 27. February 2002 9:29 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 271: comments needed Hi all, I'd appreciate some comments on this, whether to make the changes or not. John Assigned #271 Submitter: Jari Arkko Date: January 3, 2002 Reference: Document: BASE-08 Comment type: T Priority: S Section: 8.2 Rationale/Explanation of issue: Sections 9.4 and 8.2 are in conflict. The former requires clients to store acct records during network outage, and the latter requires immediate sending. The specification is also silent on how the client devices know whether it should grant access during times of network outages towards the accounting server. I can imagine that in some cases we would like to stop services if we can't provide real-time accounting, while in some other cases we would like to continue. Furthermore, the state machine in 8.2 (as well as the one that I just posted) does not specify what to do when things happen to the session faster than what it takes for an ack to come back from the server. For instance, what should we do if the session is terminated while we are still waiting for the start ack? Proposed change: An AVP similar to the Accounting-Interim-Interval could be used to control whether access should be granted or discontinued upon problems in sending the accounting records. The state machine must be modified to consider what to do with session termination and interim record generation while we are still waiting to send previous data. 9.8.x. Accounting-Realtime-Required AVP The Accounting-Realtime-Required AVP (AVP Code TBD) is of type Enumerated and is sent from the Diameter home authorization server to the Diameter client. The client uses information in this AVP to decide what to do if the sending of accounting records to the accounting server has been temporarily prevented due to, for instance, a network problem. DELIVER_AND_GRANT 1 The AVP with Value field set to DELIVER_AND_GRANT means that the service MUST only be granted as long as there is a connection to an accounting server. Note that the set of alternative accounting servers are treated as one server in this sense. Having to move the accounting record stream to a backup server is not a reason to discontinue the service to the user. GRANT_AND_STORE 2 The AVP with Value field set to GRANT_AND_STORE means that service SHOULD be granted if there is a connection, or as long as records can still be stored as described in section 9.4. This is the default behaviour if the AVP isn't included in the reply from the authorization server. GRANT_AND_LOSE 3 The AVP with Value field set to GRANT_AND_LOSE means that service SHOULD be granted even if the records can not be delivered or stored. 8.2. Accounting State Machine Add the following new entries: PendingE Failure to send and buffer Store Idle space available Event Record PendingE Failure to send and no buffer Idle space available PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingI Failure to send and (buffer Store Open space available or old record Interim can be overwritten) and Record realtime not equal to DELIVER_AND_GRANT PendingI Failure to send and no buffer Open space available and realtime equal to GRANT_AND_LOSE PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE PendingD Failure to send and buffer Store Idle space available Stop Record PendingD Failure to send and no buffer Idle space available Idle Records in storage Send PendingB record PendingB Successful accounting answer Delete Idle received record From owner-aaa-wg@merit.edu Wed Feb 27 06:32:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16635 for ; Wed, 27 Feb 2002 06:32:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5E4A7912FB; Wed, 27 Feb 2002 06:31:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23AD5912FC; Wed, 27 Feb 2002 06:31:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AE928912FB for ; Wed, 27 Feb 2002 06:31:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8FC6E5DDDC; Wed, 27 Feb 2002 06:31:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 5E9D85DDDA for ; Wed, 27 Feb 2002 06:31:31 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBVaZ00842 for ; Wed, 27 Feb 2002 13:31:36 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:31:27 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:31:26 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe019.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 13:31:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Wed, 27 Feb 2002 13:31:26 +0200 Message-ID: <8B816BAE7071AB4AB2D1BD35E017A6A806B8D1@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG+9sCsBJSD803XQZqhbDbbOyrO1AAikD1w From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 11:31:26.0595 (UTC) FILETIME=[4AE04530:01C1BF82] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16635 > -----Original Message----- > From: ext Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, February 26, 2002 8:52 PM > ... > > My problem with the D-bit is that it invites doing something in real > time that does not need to be done in real time, and puts a burden > on the sender while saving very little if anything for the receiver. > The biller is going to sort the records anyway, and finding adjacent > duplicates is trivial with or without the D-bit. > > Barney Wolff But there are cases when billing actually takes place in real time, called prepaid charging. So the usage of the D-bit would make a significant performance improvement for the receiver in these cases. - Anne From owner-aaa-wg@merit.edu Wed Feb 27 06:34:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16698 for ; Wed, 27 Feb 2002 06:34:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 4FDEA912FC; Wed, 27 Feb 2002 06:34:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21532912FD; Wed, 27 Feb 2002 06:34:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED4A6912FC for ; Wed, 27 Feb 2002 06:34:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFF505DDDC; Wed, 27 Feb 2002 06:34:32 -0500 (EST) 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 63CBA5DDDA for ; Wed, 27 Feb 2002 06:34:27 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBXr320181 for ; Wed, 27 Feb 2002 13:33:53 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:34:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:34:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Wed, 27 Feb 2002 13:34:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A66@esebe004.NOE.Nokia.com> Thread-Topic: Issue 271: comments needed Thread-Index: AcG/YHRNpqB+cEqMQ3+RHDrUvQ4dgAAHeNpgAAEQFcA= From: To: , Cc: X-OriginalArrivalTime: 27 Feb 2002 11:34:10.0735 (UTC) FILETIME=[ACB60BF0:01C1BF82] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16698 Hi Juha, > As Jari has stated: > "..in some cases we would like to stop services if we can't > provide real-time accounting, while in some other cases we would like > to continue." > > That was also in my mind when I suggested issue 272. There is > cases where the accounting records could simply be stored by > the client if the accounting server doesn't response even to > intial ACR but in some cases the services must be stopped if > ACA is not received. That was the reason I proposed new > Accounting-Record-Type values 5-8. When these values (5-8) is > sent in ACR, the service must be stopped if ACA is not received. Do you think that Jari's comments are enough for both issues (271 & 272)? Or do you have other text? John From owner-aaa-wg@merit.edu Wed Feb 27 06:36:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16742 for ; Wed, 27 Feb 2002 06:36:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id C88B8912FD; Wed, 27 Feb 2002 06:36:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A089912FE; Wed, 27 Feb 2002 06:36:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86119912FD for ; Wed, 27 Feb 2002 06:36:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6C2F15DDDC; Wed, 27 Feb 2002 06:36:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 82C7E5DDDA for ; Wed, 27 Feb 2002 06:36:30 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBacZ03724 for ; Wed, 27 Feb 2002 13:36:38 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:36:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:36:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 13:36:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A67@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG+18DDemrvf07aS/u+5R1EVNbQKwAqvS3g From: To: , X-OriginalArrivalTime: 27 Feb 2002 11:36:29.0267 (UTC) FILETIME=[FF485A30:01C1BF82] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16742 David, > So as you deal with your changes regarding how server discovery works, > keep in mind the AVPs of type DiameterIndentity which are used for message > routing and make sure their requirements are met, to wit: > > 1) A value of type DiameterIdentity must uniquely identify a > "Diameter node", which is an instance of a Diameter process running > on an IP host. > > 2) There may be more than one "Diameter node" running on the same host > and sharing the same IP address. > > 3) It must be possible to express a value of type DiameterIdentity in a > canonical form so that each "Diameter node" will only have a single > identifier in a domain. Thus the type must not contain any parameters > that are specific to a particular peer-to-peer connection. Thinking deeply about this, I have come to the conclusing that the Diameter URI, DNS discovery and DiameterIdentity are not the same thing. Therefore, while these are related, we may need to seperate these within the draft. Please comment on the text that I have sent to the list. John From owner-aaa-wg@merit.edu Wed Feb 27 06:48:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16894 for ; Wed, 27 Feb 2002 06:48:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 47150912FE; Wed, 27 Feb 2002 06:47:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 147D1912FF; Wed, 27 Feb 2002 06:47:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC5A1912FE for ; Wed, 27 Feb 2002 06:47:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id B94945DDE0; Wed, 27 Feb 2002 06:47:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CDB4E5DDE4 for ; Wed, 27 Feb 2002 06:47:11 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RBlKZ13289 for ; Wed, 27 Feb 2002 13:47:20 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:47:10 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 13:47:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Date: Wed, 27 Feb 2002 13:47:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A6A@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Thread-Index: AcG/g9o2LOrDnKRvQnq5oUhd+VoeHwAAJT0w From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 11:47:10.0549 (UTC) FILETIME=[7D843850:01C1BF84] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA16894 Hi Jari, > > I can add the text to secion 4.6, though the change: > > > > Move the last paragraph of 3.1 to the end of 2.0, where I > > think it would be easier to find. > > > > seem to be unclear / unnescessary. > > > Sure, I don't care really that much where it is. As long > as it is explicitly referenced from the base 4.6. Preferrably > also very visible on the CMS document, but what is very visible > is of course debatable... very good, that closes that issue, then. John From owner-aaa-wg@merit.edu Wed Feb 27 07:01:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17227 for ; Wed, 27 Feb 2002 07:01:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8AB2D912FF; Wed, 27 Feb 2002 07:01:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09B8391300; Wed, 27 Feb 2002 07:01:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63306912FF for ; Wed, 27 Feb 2002 07:01:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 423805DDE0; Wed, 27 Feb 2002 07:01:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id AFFDD5DDDF for ; Wed, 27 Feb 2002 07:01:05 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RC1EZ24220 for ; Wed, 27 Feb 2002 14:01:14 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 14:01:04 +0200 Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 14:01:04 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 14:01:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Wed, 27 Feb 2002 14:01:04 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF27184211FEE@trebe002.NOE.Nokia.com> Thread-Topic: Issue 271: comments needed Thread-Index: AcG/YHRNpqB+cEqMQ3+RHDrUvQ4dgAAHeNpgAAEQFcAAAJPtgA== From: To: , Cc: X-OriginalArrivalTime: 27 Feb 2002 12:01:04.0620 (UTC) FILETIME=[6EA95AC0:01C1BF86] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA17227 Hi, Well what I wonder here is if this 9.8.x. Accounting-Realtime-Required AVP is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost... The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments. br, JPK -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 27. February 2002 13:34 To: Koskinen Juha-Pekka (NET/Tampere); 'aaa-wg@merit.edu' Cc: 'jari@arkko.com' Subject: RE: [AAA-WG]: Issue 271: comments needed Hi Juha, > As Jari has stated: > "..in some cases we would like to stop services if we can't > provide real-time accounting, while in some other cases we would like > to continue." > > That was also in my mind when I suggested issue 272. There is > cases where the accounting records could simply be stored by > the client if the accounting server doesn't response even to > intial ACR but in some cases the services must be stopped if > ACA is not received. That was the reason I proposed new > Accounting-Record-Type values 5-8. When these values (5-8) is > sent in ACR, the service must be stopped if ACA is not received. Do you think that Jari's comments are enough for both issues (271 & 272)? Or do you have other text? John From owner-aaa-wg@merit.edu Wed Feb 27 08:28:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21151 for ; Wed, 27 Feb 2002 08:28:42 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE35F91302; Wed, 27 Feb 2002 08:28:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C191291303; Wed, 27 Feb 2002 08:28:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5B7691302 for ; Wed, 27 Feb 2002 08:28:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E0375DDD2; Wed, 27 Feb 2002 08:28:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 8DC9D5DDCA for ; Wed, 27 Feb 2002 08:28:25 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RDSXZ24603 for ; Wed, 27 Feb 2002 15:28:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 15:28:25 +0200 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 15:28:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 15:28:23 +0200 Message-ID: <9E3407CE45911B4097632389B77B2023AC7422@esebe014.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQDrFsiAAATIwQA= From: To: , , X-OriginalArrivalTime: 27 Feb 2002 13:28:23.0526 (UTC) FILETIME=[A14AF860:01C1BF92] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA21151 Hi, I am a bit confused here as according to the proposed specification aaa[ transport-security ]://abc.com is a valid DiameterIdentity as [transport-security] is placed within quoted string. aaa-token fqdn [ port ] [ transport ] [ protocol ] aaa-token = aaa | aaa-security aaa = "aaa://" ; No transport security aaa-security = "aaas://" ; Transport security used I feel that the above change keeping the remaining part as proposed by John will be more clear. Regards, Kishore -----Original Message----- From: Loughney John (NRC/Helsinki) Sent: 27. February 2002 13:08 To: DSpence@Interlinknetworks.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Hi All, > The problem is that the URI format is currently defined in > only one place (sec. 4.4 under the "DiameterIdentity" type) and makes no > distinction between its use for the two different purposes > described above. I propose the following resolution for defining the aaa URI ==> clarification, is this a AAA URI or Diameter URI or ..? <== 2.9 Diameter URI The Diameter URI MUST follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below: "aaa[ transport-security ]://" fqdn [ port ] [ transport ] [ protocol ] transport-security = ( "" | "s" ) ; If absent, the default, no transport security ; is assumed. fqdn = Fully Qualified Host Name port = ":" 1*DIGIT ; One of the ports used to listen for ; incoming connections. ; If absent, ; the default Diameter port (TBD) is ; assumed. transport = ";transport=" transport-protocol ; One of the transports used to listen ; for incoming connections. If absent, ; the default SCTP [SCTP] protocol is ; assumed. UDP MUST NOT be used when ; the aaa-protocol field is set to ; diameter. transport-protocol = ( "tcp" | "sctp" | "udp" ) protocol = ";protocol=" aaa-protocol ; If absent, the default AAA protocol ; is diameter. aaa-protocol = ( "diameter" | "radius" | "tacacs+" ) The following are examples of valid Diameter host identities: aaa://host.abc.com;transport=tcp aaa://host.abc.com:6666;transport=tcp aaa://host.abc.com;protocol=diameter aaa://host.abc.com:6666;protocol=diameter aaa://host.abc.com:6666;transport=tcp;protocol=diameter aaa://host.abc.com:1813;transport=udp;protocol=radius aaas://host.abc.com;transport=tcp aaas://host.abc.com;protocol=diameter John From owner-aaa-wg@merit.edu Wed Feb 27 08:58:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22628 for ; Wed, 27 Feb 2002 08:58:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 685E991227; Wed, 27 Feb 2002 08:58:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E5D29122A; Wed, 27 Feb 2002 08:58:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 21D5491227 for ; Wed, 27 Feb 2002 08:58:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAA845DDE4; Wed, 27 Feb 2002 08:58:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id A29C55DDCA for ; Wed, 27 Feb 2002 08:57:58 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1RDvOe20396 for ; Wed, 27 Feb 2002 13:57:24 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 27 Feb 2002 13:52:30 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA31809; Wed, 27 Feb 2002 13:57:21 GMT Message-ID: <3C7CE5C2.1EFCD80E@baltimore.ie> Date: Wed, 27 Feb 2002 13:57:22 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: Jari Arkko , IETF AAA List Subject: Re: [AAA-WG]: Additional cms issues References: <3C7BBEDA.264DF3A0@baltimore.ie> <007601c1bee8$ae16bb60$8a1b6e0a@arenanet.fi> <3C7BF9F8.3678C21@Interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David is right. You include many AVPs when necessary rather than one AVP. Stephen. David Spence wrote: > > Jari Arkko wrote: > >... > > > s/OctetString/Grouped/g > > > > Yes. > >... > > No! > > For reasons I explained privately to Stephen, Octet String is correct; > Grouped is incorrect. > > >From original message: > >... > > Submitter name: Stephen Farrell > > Submitter email address: stephen.farrell@baltimore.ie > > Date first submitted: 2002-02-26 > > Reference: > > Document: cms > > Comment type: T > > Priority: S > > Section: 6.0, 6.2 > > > > Rationale/Explanation of issue: > > > > CMS-Encrypted-Data can be multivalued, so OctetString is > > the wrong type for this AVP. > > > > Requested changes: > > > > s/OctetString/Grouped/g > >... -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Feb 27 09:03:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22890 for ; Wed, 27 Feb 2002 09:03:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EC58391303; Wed, 27 Feb 2002 09:03:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B9B9D9122A; Wed, 27 Feb 2002 09:03:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6F9891303 for ; Wed, 27 Feb 2002 09:02:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 853B65DDAB; Wed, 27 Feb 2002 09:02:54 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C274B5DDCA for ; Wed, 27 Feb 2002 09:02:53 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RE32Z21254 for ; Wed, 27 Feb 2002 16:03:02 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 27 Feb 2002 16:02:52 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 16:02:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 16:02:52 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A79@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG70mzhUjsKlhp5QP+bYPBzTjQfoQDrFsiAAATIwQAAAV1OcA== From: To: , X-OriginalArrivalTime: 27 Feb 2002 14:02:52.0478 (UTC) FILETIME=[727BFDE0:01C1BF97] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22890 Hi Kishore, > I am a bit confused here as according to the proposed specification > aaa[ transport-security ]://abc.com > is a valid DiameterIdentity as [transport-security] is placed > within quoted string. > > aaa-token fqdn [ port ] [ transport ] [ protocol ] > > aaa-token = aaa | aaa-security > aaa = "aaa://" > ; No transport security > aaa-security = "aaas://" > ; Transport security used > > I feel that the above change keeping the remaining part as > proposed by John will be more clear. If that notation is more clear, then I am all for it. John From owner-aaa-wg@merit.edu Wed Feb 27 09:05:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22974 for ; Wed, 27 Feb 2002 09:04:59 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B85EA9122A; Wed, 27 Feb 2002 09:04:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8237091304; Wed, 27 Feb 2002 09:04:44 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67E1A9122A for ; Wed, 27 Feb 2002 09:04:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 388EC5DDCA; Wed, 27 Feb 2002 09:04:43 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id E2BD35DDAB for ; Wed, 27 Feb 2002 09:04:42 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at 223lan160.iprolink.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@193.189.223.160) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 14:01:39 -0000 Message-Id: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 14:59:09 +0100 To: From: Jacques Caron Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Cc: , In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A67@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, Indeed, the URI (used in config files and in redirects to find another diameter server, possibly via DNS NAPTR, SRV etc.) and the Identity (used to uniquely identify a host for loop and duplicate connection detection) are two entirely different things. You may want to look at the issue I filed a long time ago, which proposes the separation of the two, with a proposed DiameterIdentity format: http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html Of course, some of the text changes are not in sync with the current text anymore :-( Jacques. At 12:36 27/02/2002, john.loughney@nokia.com wrote: >David, > > > So as you deal with your changes regarding how server discovery works, > > keep in mind the AVPs of type DiameterIndentity which are used for message > > routing and make sure their requirements are met, to wit: > > > > 1) A value of type DiameterIdentity must uniquely identify a > > "Diameter node", which is an instance of a Diameter process running > > on an IP host. > > > > 2) There may be more than one "Diameter node" running on the same host > > and sharing the same IP address. > > > > 3) It must be possible to express a value of type DiameterIdentity in a > > canonical form so that each "Diameter node" will only have a single > > identifier in a domain. Thus the type must not contain any parameters > > that are specific to a particular peer-to-peer connection. > >Thinking deeply about this, I have come to the conclusing that the Diameter >URI, DNS discovery and DiameterIdentity are not the same thing. Therefore, >while these are related, we may need to seperate these within the draft. > >Please comment on the text that I have sent to the list. > >John _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 09:20:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23583 for ; Wed, 27 Feb 2002 09:20:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 232E291309; Wed, 27 Feb 2002 09:19:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C218E91308; Wed, 27 Feb 2002 09:19:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E6BE91306 for ; Wed, 27 Feb 2002 09:19:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C2015DDCA; Wed, 27 Feb 2002 09:19:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 307905DDAB for ; Wed, 27 Feb 2002 09:19:38 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1REHr801249; Wed, 27 Feb 2002 09:17:53 -0500 Message-ID: <3C7CEA90.6534E124@interlinknetworks.com> Date: Wed, 27 Feb 2002 09:17:52 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 256: TLS Usage Issues References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A4E@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id JAA23583 Hi John, Here's the suggested modified text. Don Z. Proposed change: Add: A Diameter node that initiates a connection to another Diameter node acts as a TLS client according to [RFC2246], and a Diameter node that accepts a connection acts as a TLS server. Diameter nodes implementing TLS for security MUST mutually authenticate as part of TLS session establishment. In order to ensure mutual authentication, the Diameter node acting as TLS server must request a certificate from the Diameter node acting as TLS client, and the Diameter node acting as TLS client MUST be prepared to supply a certificate on request. john.loughney@nokia.com wrote: > Hi Don, > > Can you suggest modified text? > > John > > > -----Original Message----- > > From: ext Don Zick [mailto:dzick@interlinknetworks.com] > > Sent: 26 February, 2002 23:16 > > To: Loughney John (NRC/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: Issue 256: TLS Usage Issues > > > > > > The proposed text states that Diameter Clients act as TLS > > clients and that > > Diameter Servers act as TLS servers. I don't think this is > > quite right. I > > think the connection initiator acts as the TLS client and the > > connection > > acceptor acts as the TLS server. When two Diameter servers > > connect, the > > Diameter server that initiates the connection acts as the TLS > > client. If a > > Diameter client accepts a connetion from a Diameter server > > then I think the > > Diameter client should act as the TLS server. > > > > I think the connection initiator should be responsible for > > initiating TLS > > negotiations just as it is responsible for sending the > > initial CER message. > > > > Don Z. > > > > john.loughney@nokia.com wrote: > > > > > Hi all, > > > > > > The proposed text seems sensible. Unless there are objections, I > > > shall add this. > > > > > > John > > > > > > Issue 256: TLS Usage Issues > > > Submitter name: Bernard Aboba aboba@internaut.com > > > Submitter email address: aboba@internaut.com > > > Date first submitted: 28-Dec-01 > > > Reference: > > > Document: base 08 > > > Comment type: Technical > > > Priority: S > > > Section: 2.2 > > > Rationale/Explanation of issue: > > > There is no discussion of how TLS authentication is used with > > > Diameter. For example: > > > > > > a. Are both peers required to support certificates? > > > b. If not, how is it decided which peer authenticates to who? > > > > > > Proposed change: > > > > > > Add: > > > > > > "Diameter clients act as TLS clients according to > > [RFC2246], and Diameter > > > servers act as TLS servers. Diameter clients and servers > > implementing > > > TLS for security MUST mutually authenticate as part of TLS session > > > establishment. In order to ensure mutual authentication, > > Diameter servers > > > MUST request certificates from Diameter clients, and the > > client MUST be > > > prepared to supply a certificate on request." > > From owner-aaa-wg@merit.edu Wed Feb 27 09:29:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24031 for ; Wed, 27 Feb 2002 09:29:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC01C91308; Wed, 27 Feb 2002 09:28:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 894679130A; Wed, 27 Feb 2002 09:28:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4962091308 for ; Wed, 27 Feb 2002 09:28:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D8EE5DDD2; Wed, 27 Feb 2002 09:28:46 -0500 (EST) 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 C652D5DDDF for ; Wed, 27 Feb 2002 09:28:40 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RES7301729 for ; Wed, 27 Feb 2002 16:28:07 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 16:28:25 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 16:28:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 16:28:25 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A7E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/moe9U2eAmQIZRbWKa+vo4YfsEwAAG9hg From: To: Cc: , X-OriginalArrivalTime: 27 Feb 2002 14:28:25.0294 (UTC) FILETIME=[041D26E0:01C1BF9B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA24031 Hi Jacques, Can you comment on what I have proposed? Is my seperation OK? John > -----Original Message----- > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Sent: 27 February, 2002 15:59 > To: Loughney John (NRC/Helsinki) > Cc: DSpence@Interlinknetworks.com; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded > > > Hi John, > > Indeed, the URI (used in config files and in redirects to > find another > diameter server, possibly via DNS NAPTR, SRV etc.) and the > Identity (used > to uniquely identify a host for loop and duplicate connection > detection) > are two entirely different things. > > You may want to look at the issue I filed a long time ago, > which proposes > the separation of the two, with a proposed DiameterIdentity format: > > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html > > Of course, some of the text changes are not in sync with the > current text > anymore :-( > > Jacques. > > At 12:36 27/02/2002, john.loughney@nokia.com wrote: > >David, > > > > > So as you deal with your changes regarding how server > discovery works, > > > keep in mind the AVPs of type DiameterIndentity which are > used for message > > > routing and make sure their requirements are met, to wit: > > > > > > 1) A value of type DiameterIdentity must uniquely identify a > > > "Diameter node", which is an instance of a Diameter > process running > > > on an IP host. > > > > > > 2) There may be more than one "Diameter node" running on > the same host > > > and sharing the same IP address. > > > > > > 3) It must be possible to express a value of type > DiameterIdentity in a > > > canonical form so that each "Diameter node" will only > have a single > > > identifier in a domain. Thus the type must not > contain any parameters > > > that are specific to a particular peer-to-peer connection. > > > >Thinking deeply about this, I have come to the conclusing > that the Diameter > >URI, DNS discovery and DiameterIdentity are not the same > thing. Therefore, > >while these are related, we may need to seperate these > within the draft. > > > >Please comment on the text that I have sent to the list. > > > >John > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > From owner-aaa-wg@merit.edu Wed Feb 27 09:56:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25566 for ; Wed, 27 Feb 2002 09:56:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EE64E9130E; Wed, 27 Feb 2002 09:56:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B99949130F; Wed, 27 Feb 2002 09:56:07 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C23DB9130E for ; Wed, 27 Feb 2002 09:56:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1AC75DDE4; Wed, 27 Feb 2002 09:56:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by segue.merit.edu (Postfix) with ESMTP id D403C5DDDF for ; Wed, 27 Feb 2002 09:56:05 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g1REthB00885; Wed, 27 Feb 2002 15:55:43 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g1REtgmK000958; Wed, 27 Feb 2002 16:55:42 +0200 (EET) Message-ID: <3C7CF36E.BF88098A@lmf.ericsson.se> Date: Wed, 27 Feb 2002 16:55:42 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: anne.narhi@nokia.com Cc: barney@databus.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 References: <8B816BAE7071AB4AB2D1BD35E017A6A806B8D1@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit anne.narhi@nokia.com wrote: > > My problem with the D-bit is that it invites doing something in real > > time that does not need to be done in real time, and puts a burden > > on the sender while saving very little if anything for the receiver. > > The biller is going to sort the records anyway, and finding adjacent > > duplicates is trivial with or without the D-bit. > > > > Barney Wolff > > But there are cases when billing actually takes place in > real time, called prepaid charging. So the usage of the > D-bit would make a significant performance improvement > for the receiver in these cases. The prepaid case is a valid one. So D-bit is useful when the following condition is fulfilled: RealTimeBilling AND PoolLookUpFasterThanSessionIdLookUp AND PoolLookUpFasterThanUserNameLookUp Since the D-bit method also requires SessionId look-ups in certain cases, we always need a reasonably fast look-up anyway i.e. linear list of all records is not acceptable for D-bit either. So this really boils down to the question of whether the pool lookup (small and likely in RAM) is faster than a real record lookup (likely on disk but index likely in RAM). Jari From owner-aaa-wg@merit.edu Wed Feb 27 10:05:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26024 for ; Wed, 27 Feb 2002 10:05:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C13F91317; Wed, 27 Feb 2002 10:00:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E62691312; Wed, 27 Feb 2002 10:00:54 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D297B91313 for ; Wed, 27 Feb 2002 10:00:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id B8E335DDCA; Wed, 27 Feb 2002 10:00:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A367A5DD9D for ; Wed, 27 Feb 2002 10:00:36 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id A8AA97A; Wed, 27 Feb 2002 10:00:33 -0500 (EST) From: "Bob Kopacz" To: Cc: Subject: [AAA-WG]: RE: [issue] Minor corrections to draft-base-08 Date: Wed, 27 Feb 2002 09:59:40 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D3F@esebe004.NOE.Nokia.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > > > > In Section 4.5.1 "Example AVP with a Grouped Data type" > > > > > The Example AVP (AVP Code 999999) is of type Grouped and > > is used to > > > clarify how Grouped AVP values work. The Grouped Data > > field has the > > > following ABNF grammar: > > > > > > Example-AVP ::= < AVP Header: 999999 > > > > { Origin-Host } > > > 1*{ Session-Id } > > > *[ AVP ] > > > > > > An Example AVP with Grouped Data follows. > > > > > > The Origin-Host AVP is required. In this case: > > > > > > Origin-Host = "example.com". > > > > This example is just for illustrative purposes, but it might be better > > if the Origin-Host value followed the syntax for DiameterIdentity > > [whatever that is these days :) ]. > > Is something like this OK? > > Origin-Host = "aaa://host.abc.com;transport=tcp" > Oh, sure. Even something shorter, "aaa://host.abc.com", is plenty good for the example. Bob K. From owner-aaa-wg@merit.edu Wed Feb 27 10:06:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26108 for ; Wed, 27 Feb 2002 10:06:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id CE03591336; Wed, 27 Feb 2002 10:05:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CB2091335; Wed, 27 Feb 2002 10:05:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14EA39132F for ; Wed, 27 Feb 2002 10:05:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id E7DDB5DDCA; Wed, 27 Feb 2002 10:05:29 -0500 (EST) 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 B2ED95DD9D for ; Wed, 27 Feb 2002 10:05:29 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DAB136A901; Wed, 27 Feb 2002 17:05:28 +0200 (EET) Message-ID: <3C7CF604.10008@kolumbus.fi> Date: Wed, 27 Feb 2002 17:06:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, juha-pekka.koskinen@nokia.com Subject: Re: [AAA-WG]: Issue #272 - Separation of the prepaid and postpaid accounting sessions References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A51@esebe004.NOE.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 john.loughney@nokia.com wrote: > The consensus on this issue seemed to indicate that this change should not > be made in the base spec, but could be addressed in an application document, > so I considering this as a reject. I basically agree with the issue, but disagree about the way it has been provided in the proposed text. I would rather have had a single new AVP that simply lists the 'priority' of the accounting data. We could invent two, or maybe even more priority classes. This would then not e.g. have an impact state machines etc. Then it is an another matter whether this change should be in the base, a new generic AVP definition, or an application. My view is actually that this can *not* be a part of an application, because then app-unaware proxies will not be able to take in account the priority! However, it might still be possible to define this as a single new Diameter AVP not associated with any specific application. Can we do that? If not, my suggestion is to include that in the base now. I can provide text if necessary. Jari From owner-aaa-wg@merit.edu Wed Feb 27 10:16:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26683 for ; Wed, 27 Feb 2002 10:16:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6CA0D91310; Wed, 27 Feb 2002 10:15:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31CD291312; Wed, 27 Feb 2002 10:15:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 17F0991310 for ; Wed, 27 Feb 2002 10:15:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id F0A6A5DDCA; Wed, 27 Feb 2002 10:15:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id A5CFD5DD9D for ; Wed, 27 Feb 2002 10:15:47 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SDBT>; Wed, 27 Feb 2002 07:15:44 -0800 Message-ID: From: "Pat R. Calhoun" To: "'anne.narhi@nokia.com'" , barney@databus.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Wed, 27 Feb 2002 07:15:43 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFA1.A0111B00" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BFA1.A0111B00 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ... > > My problem with the D-bit is that it invites doing something in > real time that does not need to be done in real time, and puts a > burden on the sender while saving very little if anything for the > receiver. The biller is going to sort the records anyway, and > finding adjacent > duplicates is trivial with or without the D-bit. > > Barney Wolff But there are cases when billing actually takes place in real time, called prepaid charging. So the usage of the D-bit would make a significant performance improvement for the receiver in these cases. I seriously don't understand the insistence on using User-Name for the lookup. Not only is there a Session-Id, which is unique, but there is also an accounting record number. Those two items are guaranteed to be unique, and therefore are a great way of checking for dups. I don't understand the mechanism by which records are put in a "temporary" buffer, as opposed on written on disk. You need to write ALL records in this "temporary" buffer (if it even exists) in order to check for duplicates. What really confuses me here is how the checks are done. Using a single bit 'D' isn't really useful for a lookup. Some additional data is required, and whether the 'D' bit is set or not, the message must be cached for duplicate check (to handle out of order packets). Confused, PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPHz4IDN1fXKoxmisEQKSUgCgtMddxGqrdIcr2VbkULi5SmtwMR8AoPjG OSYyu0mQbbTX4SEyKq7oMu0H =jiCK -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BFA1.A0111B00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

...
>
> My problem with the D-bit is that it invites = doing something in
> real  time that does not need to be done = in real time, and puts a
> burden on  the sender while saving very = little if anything for the
> receiver. The  biller is going to sort the = records anyway, and
> finding adjacent
> duplicates is trivial with or without the = D-bit.
>
> Barney Wolff

But there are cases when billing actually takes place = in real time,
called prepaid charging. So the usage of the D-bit = would make a
significant performance improvement for the receiver = in these cases.

<PRC> I seriously don't understand the = insistence on using User-Name
for the lookup. Not only is there a Session-Id, = which is unique, but
there is also an accounting record number. Those two = items are
guaranteed to be unique, and therefore are a great = way of checking
for dups. I don't understand the mechanism by which = records are put
in a "temporary" buffer, as opposed on = written on disk. You need to
write ALL records in this "temporary" = buffer (if it even exists) in
order to check for duplicates.

What really confuses me here is how the checks are = done. Using a
single bit 'D' isn't really useful for a lookup. = Some additional data
is required, and whether the 'D' bit is set or not, = the message must
be cached for duplicate check (to handle out of = order packets).

Confused,

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPHz4IDN1fXKoxmisEQKSUgCgtMddxGqrdIcr2VbkULi5SmtwMR8AoPj= G
OSYyu0mQbbTX4SEyKq7oMu0H
=3DjiCK
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BFA1.A0111B00-- From owner-aaa-wg@merit.edu Wed Feb 27 10:18:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26757 for ; Wed, 27 Feb 2002 10:18:16 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9CC491321; Wed, 27 Feb 2002 10:17:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6A7C091320; Wed, 27 Feb 2002 10:17:10 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F24F91318 for ; Wed, 27 Feb 2002 10:17:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB2D25DDE0; Wed, 27 Feb 2002 10:17:07 -0500 (EST) 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 B82985DD9D for ; Wed, 27 Feb 2002 10:17:07 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2345F6A901; Wed, 27 Feb 2002 17:17:03 +0200 (EET) Message-ID: <3C7CF8BB.1040903@kolumbus.fi> Date: Wed, 27 Feb 2002 17:18:19 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed References: <0AA9E01B31168E42A308714A6EF27184211FEE@trebe002.NOE.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 Ah, now I see that 272 is also discussed under this thread. Sorry for the confusion. Anyway, to answer Juha-Pekka first: The new AVP design was actually that it would be sent from the auth server to the NAS. Additionally, we could allow also it come from the acct server in the responses. In any case, if you are not using authentication and didn't get any response from the acct server, then there's theoretically no way to figure out what to do with the service, unless local configuration knows. So, it would seem to me that providing both auth server and acct server responses with this new AVP where needed would satisfy all needs. However, my proposal for realtime-required avp was actually a bit different than what I understood issue 272 to want to have. Basically, there are two things: - Whether you want to give service if you can't send in acct data - Priority order between queued records at an accounting server or proxy The realtime-required AVP deals with the first issue. The new AVP I was talking about in issue 272 deals with the second issue. If you think we're fine with just the first service then we could just agree on 271 and reject 272. If not, we need to do something also for 272. I believe 271 needs to be done in any case, because the current spec is inconsistent. Jari juha-pekka.koskinen@nokia.com wrote: > Hi, > > Well what I wonder here is if this > > 9.8.x. Accounting-Realtime-Required AVP > > is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost... > > The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments. > > br, > JPK > > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 27. February 2002 13:34 > To: Koskinen Juha-Pekka (NET/Tampere); 'aaa-wg@merit.edu' > Cc: 'jari@arkko.com' > Subject: RE: [AAA-WG]: Issue 271: comments needed > > > Hi Juha, > > >>As Jari has stated: >>"..in some cases we would like to stop services if we can't >>provide real-time accounting, while in some other cases we would like >>to continue." >> >>That was also in my mind when I suggested issue 272. There is >>cases where the accounting records could simply be stored by >>the client if the accounting server doesn't response even to >>intial ACR but in some cases the services must be stopped if >>ACA is not received. That was the reason I proposed new >>Accounting-Record-Type values 5-8. When these values (5-8) is >>sent in ACR, the service must be stopped if ACA is not received. >> > > Do you think that Jari's comments are enough for both issues (271 & 272)? > Or do you have other text? > > John > > From owner-aaa-wg@merit.edu Wed Feb 27 10:24:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27136 for ; Wed, 27 Feb 2002 10:24:03 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3160691331; Wed, 27 Feb 2002 10:19:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECABD91334; Wed, 27 Feb 2002 10:19:23 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AEC591331 for ; Wed, 27 Feb 2002 10:19:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3AD55DDE0; Wed, 27 Feb 2002 10:19:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 9BF2F5DDCA for ; Wed, 27 Feb 2002 10:19:19 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at 223lan160.iprolink.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@193.189.223.160) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 15:14:36 -0000 Message-Id: <5.1.0.14.0.20020227154125.03974c98@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 16:14:30 +0100 To: From: Jacques Caron Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Cc: , In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A7E@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi John, I think the separation is good (though it must probably be clarified where each one is used), but I think the definition of the DiameterIdentity is not clear enough. The two important points are that: - it must be unique for any diameter process - it must be constant for any diameter process These two points must be stated very clearly. This implies: - the format itself is not necessarily relevant, what is important is that its format makes it unique - I don't think we need the aaa:// prefix at all (this would only introduce confusion with DiameterURIs) - I'm not sure FQDNs are unique enough (one FQDN can point to multiple IPs and vice versa), but it should work as long as the value picked is unique for a given server, and kept constant for that server - same remark for port numbers: if the process listens on multiple ports, it can use the value for any one of those ports, as long as it keeps that value as long as the server is running. - port numbers are not unique enough, the protocol (TCP or SCTP) should be added (even though I doubt anyone would be running two servers, one using TCP and the other SCTP, both listening on the same IP and port, this could happen) One other point is that DiameterIdentity values are used quite a lot in all exchanges (for loop detection, routing, etc.) and hence the shorter it is, the better. Which is why I proposed using a binary format including protocol, port and IP address (8 bytes in the best case, 36 in the worst case), which has less ambiguity and is a lot shorter, but that's really open. One issue I don't remember if it was solved, though, is that diameter servers might be subject to DoS attacks: A could connect to B pretending to be C. C would then be unable to connect to B (which would think it's already connected), and B would send messages for C to A. I guess some certificate checking might be needed, in which case the DiameterIdentity format used would need to be able to be matched to that certificate (and no, I don't know where the certificate would come from -- I guess it should be easy with TLS, but over IPsec I think a mechanism to present a certificate and prove that a server has the associated secret key would need to be included in the CER/CEA packets). Is there a "recent" version of the draft available somewhere? I haven't followed all the changes over the recent months... It might be a good idea to make it available via cvs :-) Jacques. At 15:28 27/02/2002, john.loughney@nokia.com wrote: >Hi Jacques, > >Can you comment on what I have proposed? Is my seperation OK? > >John > > > -----Original Message----- > > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > Sent: 27 February, 2002 15:59 > > To: Loughney John (NRC/Helsinki) > > Cc: DSpence@Interlinknetworks.com; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded > > > > > > Hi John, > > > > Indeed, the URI (used in config files and in redirects to > > find another > > diameter server, possibly via DNS NAPTR, SRV etc.) and the > > Identity (used > > to uniquely identify a host for loop and duplicate connection > > detection) > > are two entirely different things. > > > > You may want to look at the issue I filed a long time ago, > > which proposes > > the separation of the two, with a proposed DiameterIdentity format: > > > > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html > > > > Of course, some of the text changes are not in sync with the > > current text > > anymore :-( > > > > Jacques. > > > > At 12:36 27/02/2002, john.loughney@nokia.com wrote: > > >David, > > > > > > > So as you deal with your changes regarding how server > > discovery works, > > > > keep in mind the AVPs of type DiameterIndentity which are > > used for message > > > > routing and make sure their requirements are met, to wit: > > > > > > > > 1) A value of type DiameterIdentity must uniquely identify a > > > > "Diameter node", which is an instance of a Diameter > > process running > > > > on an IP host. > > > > > > > > 2) There may be more than one "Diameter node" running on > > the same host > > > > and sharing the same IP address. > > > > > > > > 3) It must be possible to express a value of type > > DiameterIdentity in a > > > > canonical form so that each "Diameter node" will only > > have a single > > > > identifier in a domain. Thus the type must not > > contain any parameters > > > > that are specific to a particular peer-to-peer connection. > > > > > >Thinking deeply about this, I have come to the conclusing > > that the Diameter > > >URI, DNS discovery and DiameterIdentity are not the same > > thing. Therefore, > > >while these are related, we may need to seperate these > > within the draft. > > > > > >Please comment on the text that I have sent to the list. > > > > > >John > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 10:41:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27984 for ; Wed, 27 Feb 2002 10:41:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5242691318; Wed, 27 Feb 2002 10:39:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 218D09131D; Wed, 27 Feb 2002 10:39:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD3A991318 for ; Wed, 27 Feb 2002 10:39:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8895E5DDDF; Wed, 27 Feb 2002 10:39:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 73A725DDD2 for ; Wed, 27 Feb 2002 10:39:38 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 319437A; Wed, 27 Feb 2002 10:39:38 -0500 (EST) Message-ID: <3C7CFDC0.E984341@Interlinknetworks.com> Date: Wed, 27 Feb 2002 10:39:44 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu, mankin@isi.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D44@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------32ADCE20EEA3CC15C4561ECC" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------32ADCE20EEA3CC15C4561ECC Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, this would work for a definition of the DiameterIdentity type. john.loughney@nokia.com wrote: > > Hi David, > > Would the changes suggest inline be sufficiengt: > > > Requested change: > > > > Define the format of the URI somewhere other than section 4.4. In > > the definition of the DiameterIdentity type in section 4.4, specify > > that only the prefix, fqdn, and port number portions of the URI are > > included in AVP value fields of this type. The sentences cited above > > may now be left in section 4.4 because they no longer cause a > > problem. > > DiameterIdentity = "aaa://" fqdn [ port ] > > fqdn = Fully Qualified Host Name > > port = ":" 1*DIGIT > ; One of the ports used to listen for > ; incoming connections. > ; If absent, > ; the default Diameter port (TBD) is > ; assumed. > ; A single port number MUST be used > ; in all AVPs of type DiameterIdentity. > > > If the URI prefix may either be aaa: or aaas: depending on transport > > security, then text should be added to section 6 stating that when > > matching URIs for routing purposes, the "s" in aaas: should be > > dropped before the compare is made. > > My feeling is that for DiameterIdentity, we do not need to discriminate aaa > vs. aaas. > > John --------------32ADCE20EEA3CC15C4561ECC Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------32ADCE20EEA3CC15C4561ECC-- From owner-aaa-wg@merit.edu Wed Feb 27 10:45:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28231 for ; Wed, 27 Feb 2002 10:45:04 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 578E791315; Wed, 27 Feb 2002 10:44:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AE2591319; Wed, 27 Feb 2002 10:44:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 45D8091315 for ; Wed, 27 Feb 2002 10:44:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20E1F5DDDF; Wed, 27 Feb 2002 10:44:42 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 0B8545DDD2 for ; Wed, 27 Feb 2002 10:44:42 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id CF1C07A; Wed, 27 Feb 2002 10:44:41 -0500 (EST) Message-ID: <3C7CFEF0.746AC4ED@Interlinknetworks.com> Date: Wed, 27 Feb 2002 10:44:48 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A67@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------5B49C2C1CCF86545761872CB" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------5B49C2C1CCF86545761872CB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, as I said before, the current draft combines two different things into one: 1) Peer discovery and peer connection establishment 2) Message forwarding There is no reason that they should be related, however they do share one need -- the identity of the Diameter process. In both cases, the combination of fqdn and a port that the process listens on is sufficient. So the two needs could use the same process identity, but the peer-to-peer need requires additional information. john.loughney@nokia.com wrote: > > David, > > > So as you deal with your changes regarding how server discovery works, > > keep in mind the AVPs of type DiameterIndentity which are used for message > > routing and make sure their requirements are met, to wit: > > > > 1) A value of type DiameterIdentity must uniquely identify a > > "Diameter node", which is an instance of a Diameter process running > > on an IP host. > > > > 2) There may be more than one "Diameter node" running on the same host > > and sharing the same IP address. > > > > 3) It must be possible to express a value of type DiameterIdentity in a > > canonical form so that each "Diameter node" will only have a single > > identifier in a domain. Thus the type must not contain any parameters > > that are specific to a particular peer-to-peer connection. > > Thinking deeply about this, I have come to the conclusing that the Diameter > URI, DNS discovery and DiameterIdentity are not the same thing. Therefore, > while these are related, we may need to seperate these within the draft. > > Please comment on the text that I have sent to the list. > > John --------------5B49C2C1CCF86545761872CB Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------5B49C2C1CCF86545761872CB-- From owner-aaa-wg@merit.edu Wed Feb 27 10:54:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28709 for ; Wed, 27 Feb 2002 10:54:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3526E91319; Wed, 27 Feb 2002 10:54:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 005EE9131A; Wed, 27 Feb 2002 10:54:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F305191319 for ; Wed, 27 Feb 2002 10:54:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id D51915DDDC; Wed, 27 Feb 2002 10:54:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by segue.merit.edu (Postfix) with ESMTP id 662685DD9D for ; Wed, 27 Feb 2002 10:54:39 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42261) id <0GS700A0185VPV@firewall.wcom.com> for aaa-wg@merit.edu; Wed, 27 Feb 2002 15:53:56 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42261) with ESMTP id <0GS700ABC85V0Z@firewall.wcom.com>; Wed, 27 Feb 2002 15:53:55 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GS700E0185Q3K@dgismtp01.wcomnet.com>; Wed, 27 Feb 2002 15:53:54 +0000 (GMT) Received: from blhalllt ([166.34.147.53]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GS700E0485J12@dgismtp01.wcomnet.com>; Wed, 27 Feb 2002 15:53:43 +0000 (GMT) Date: Wed, 27 Feb 2002 08:53:24 -0700 From: Barbara L Hall Subject: Re: [AAA-WG]: Request for closure on issue 235 To: anne.narhi@nokia.com, barney@databus.com Cc: aaa-wg@merit.edu Message-id: <002101c1bfa6$e3c32d20$359322a6@wcomnet.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Priority: 3 X-MSMail-priority: Normal References: <8B816BAE7071AB4AB2D1BD35E017A6A806B8D1@trebe002.NOE.Nokia.com> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Real-time usage data is a requirement. The customer wants current status of an account. The high value provider will quantify that usage in time, in counts and in dollars (or whatever monetary translation applies). No one refutes that 'billing' will continue to occur offline after considerable sifting. But Nokia points out what this standard must provide to be adopted: measurable, identifiable, reliable event creation. Resolving duplicates is the issue. We may be getting off the mark by settling for batch and post-processing as an easy or natural resolve. The market expectations are considerably higher. If the discussion here is expediancy then accept the D-bit and note the intent to improve the solution in the next standard release. That prepares the coders to isolate the solution. [J2EE version 1.3.1 is an adjustment. But an easy adjustment, compared to the invaluable standards that never baseline, only get closer and closer to infinity.] ----- Original Message ----- From: To: Cc: Sent: Wednesday, February 27, 2002 4:31 AM Subject: RE: [AAA-WG]: Request for closure on issue 235 > -----Original Message----- > From: ext Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, February 26, 2002 8:52 PM > ... > > My problem with the D-bit is that it invites doing something in real > time that does not need to be done in real time, and puts a burden > on the sender while saving very little if anything for the receiver. > The biller is going to sort the records anyway, and finding adjacent > duplicates is trivial with or without the D-bit. > > Barney Wolff But there are cases when billing actually takes place in real time, called prepaid charging. So the usage of the D-bit would make a significant performance improvement for the receiver in these cases. - Anne From owner-aaa-wg@merit.edu Wed Feb 27 10:58:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28869 for ; Wed, 27 Feb 2002 10:58:39 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EFAB59131C; Wed, 27 Feb 2002 10:58:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2FD59131B; Wed, 27 Feb 2002 10:58:27 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 699659131C for ; Wed, 27 Feb 2002 10:58:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 049975DDEA; Wed, 27 Feb 2002 10:58:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A0F8F5DDF0 for ; Wed, 27 Feb 2002 10:58:21 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 58CFD7A; Wed, 27 Feb 2002 10:58:21 -0500 (EST) Message-ID: <3C7D0223.28C21CFC@Interlinknetworks.com> Date: Wed, 27 Feb 2002 10:58:27 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jacques Caron Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------4C8864AB20A005A81371D694" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------4C8864AB20A005A81371D694 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes, this issue is about the same thing. If this issue had been resolved as you proposed, we wouldn't be dealing with it again now. I do have one question about your DiameterIdentity proposal. You included a field for transport protocol. I think you would have to require that the same identity is used in all Diameter messages even if the Diameter node had multiple peers using multiple transport protocols. But with that requirment, it would be o.k. I don't have time just now to research what the resolution to your issue was, but I do think that had the issue been accepted, we wouldn't need to be discussing it now. Jacques Caron wrote: > > Hi John, > > Indeed, the URI (used in config files and in redirects to find another > diameter server, possibly via DNS NAPTR, SRV etc.) and the Identity (used > to uniquely identify a host for loop and duplicate connection detection) > are two entirely different things. > > You may want to look at the issue I filed a long time ago, which proposes > the separation of the two, with a proposed DiameterIdentity format: > > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html > > Of course, some of the text changes are not in sync with the current text > anymore :-( > > Jacques. > > At 12:36 27/02/2002, john.loughney@nokia.com wrote: > >David, > > > > > So as you deal with your changes regarding how server discovery works, > > > keep in mind the AVPs of type DiameterIndentity which are used for message > > > routing and make sure their requirements are met, to wit: > > > > > > 1) A value of type DiameterIdentity must uniquely identify a > > > "Diameter node", which is an instance of a Diameter process running > > > on an IP host. > > > > > > 2) There may be more than one "Diameter node" running on the same host > > > and sharing the same IP address. > > > > > > 3) It must be possible to express a value of type DiameterIdentity in a > > > canonical form so that each "Diameter node" will only have a single > > > identifier in a domain. Thus the type must not contain any parameters > > > that are specific to a particular peer-to-peer connection. > > > >Thinking deeply about this, I have come to the conclusing that the Diameter > >URI, DNS discovery and DiameterIdentity are not the same thing. Therefore, > >while these are related, we may need to seperate these within the draft. > > > >Please comment on the text that I have sent to the list. > > > >John > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com --------------4C8864AB20A005A81371D694 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------4C8864AB20A005A81371D694-- From owner-aaa-wg@merit.edu Wed Feb 27 11:01:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29154 for ; Wed, 27 Feb 2002 11:01:43 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 39D3A9131E; Wed, 27 Feb 2002 11:01:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F324A91324; Wed, 27 Feb 2002 11:01:06 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6BED9131E for ; Wed, 27 Feb 2002 11:01:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9676E5DDCA; Wed, 27 Feb 2002 11:01:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 80CD25DD9D for ; Wed, 27 Feb 2002 11:01:05 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 376DA7A; Wed, 27 Feb 2002 11:01:05 -0500 (EST) Message-ID: <3C7D02C7.7A9D1427@Interlinknetworks.com> Date: Wed, 27 Feb 2002 11:01:11 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jacques Caron Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <5.1.0.14.0.20020227154125.03974c98@pop.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------5557EB45187B5A7FC95AAD40" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------5557EB45187B5A7FC95AAD40 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes! I completely agree with everything you say here. Jacques Caron wrote: > > Hi John, > > I think the separation is good (though it must probably be clarified where > each one is used), but I think the definition of the DiameterIdentity is > not clear enough. > > The two important points are that: > - it must be unique for any diameter process > - it must be constant for any diameter process > These two points must be stated very clearly. > > This implies: > - the format itself is not necessarily relevant, what is important is that > its format makes it unique > - I don't think we need the aaa:// prefix at all (this would only introduce > confusion with DiameterURIs) > - I'm not sure FQDNs are unique enough (one FQDN can point to multiple IPs > and vice versa), but it should work as long as the value picked is unique > for a given server, and kept constant for that server > - same remark for port numbers: if the process listens on multiple ports, > it can use the value for any one of those ports, as long as it keeps that > value as long as the server is running. > - port numbers are not unique enough, the protocol (TCP or SCTP) should be > added (even though I doubt anyone would be running two servers, one using > TCP and the other SCTP, both listening on the same IP and port, this could > happen) > > One other point is that DiameterIdentity values are used quite a lot in all > exchanges (for loop detection, routing, etc.) and hence the shorter it is, > the better. Which is why I proposed using a binary format including > protocol, port and IP address (8 bytes in the best case, 36 in the worst > case), which has less ambiguity and is a lot shorter, but that's really open. > > One issue I don't remember if it was solved, though, is that diameter > servers might be subject to DoS attacks: A could connect to B pretending to > be C. C would then be unable to connect to B (which would think it's > already connected), and B would send messages for C to A. I guess some > certificate checking might be needed, in which case the DiameterIdentity > format used would need to be able to be matched to that certificate (and > no, I don't know where the certificate would come from -- I guess it should > be easy with TLS, but over IPsec I think a mechanism to present a > certificate and prove that a server has the associated secret key would > need to be included in the CER/CEA packets). > > Is there a "recent" version of the draft available somewhere? I haven't > followed all the changes over the recent months... It might be a good idea > to make it available via cvs :-) > > Jacques. > > At 15:28 27/02/2002, john.loughney@nokia.com wrote: > >Hi Jacques, > > > >Can you comment on what I have proposed? Is my seperation OK? > > > >John > > > > > -----Original Message----- > > > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > > Sent: 27 February, 2002 15:59 > > > To: Loughney John (NRC/Helsinki) > > > Cc: DSpence@Interlinknetworks.com; aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded > > > > > > > > > Hi John, > > > > > > Indeed, the URI (used in config files and in redirects to > > > find another > > > diameter server, possibly via DNS NAPTR, SRV etc.) and the > > > Identity (used > > > to uniquely identify a host for loop and duplicate connection > > > detection) > > > are two entirely different things. > > > > > > You may want to look at the issue I filed a long time ago, > > > which proposes > > > the separation of the two, with a proposed DiameterIdentity format: > > > > > > http://www.merit.edu/mail.archives/aaa-wg/2001-08/msg00033.html > > > > > > Of course, some of the text changes are not in sync with the > > > current text > > > anymore :-( > > > > > > Jacques. > > > > > > At 12:36 27/02/2002, john.loughney@nokia.com wrote: > > > >David, > > > > > > > > > So as you deal with your changes regarding how server > > > discovery works, > > > > > keep in mind the AVPs of type DiameterIndentity which are > > > used for message > > > > > routing and make sure their requirements are met, to wit: > > > > > > > > > > 1) A value of type DiameterIdentity must uniquely identify a > > > > > "Diameter node", which is an instance of a Diameter > > > process running > > > > > on an IP host. > > > > > > > > > > 2) There may be more than one "Diameter node" running on > > > the same host > > > > > and sharing the same IP address. > > > > > > > > > > 3) It must be possible to express a value of type > > > DiameterIdentity in a > > > > > canonical form so that each "Diameter node" will only > > > have a single > > > > > identifier in a domain. Thus the type must not > > > contain any parameters > > > > > that are specific to a particular peer-to-peer connection. > > > > > > > >Thinking deeply about this, I have come to the conclusing > > > that the Diameter > > > >URI, DNS discovery and DiameterIdentity are not the same > > > thing. Therefore, > > > >while these are related, we may need to seperate these > > > within the draft. > > > > > > > >Please comment on the text that I have sent to the list. > > > > > > > >John > > > > > > > > > > > > _________________________________________________________ > > > > > > Do You Yahoo!? > > > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com --------------5557EB45187B5A7FC95AAD40 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------5557EB45187B5A7FC95AAD40-- From owner-aaa-wg@merit.edu Wed Feb 27 11:04:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29286 for ; Wed, 27 Feb 2002 11:04:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 19CFB9131A; Wed, 27 Feb 2002 11:04:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BAC419131B; Wed, 27 Feb 2002 11:04:21 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C56A89131A for ; Wed, 27 Feb 2002 11:04:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id A79275DDCA; Wed, 27 Feb 2002 11:04:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 91F475DD9D for ; Wed, 27 Feb 2002 11:04:20 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 31A967A; Wed, 27 Feb 2002 11:04:20 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Handling of Accounting-Multi-Session-Id AVP (draft-mobileip-08) Date: Wed, 27 Feb 2002 11:03:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Handling of Accounting-Multi-Session-Id AVP Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-27-2002 Reference: Document: draft-mobileip-08 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: Changes to generation & handling of the Accounting-Multi-Session-Id AVP. The following lines prefixed with "*" are extracted from draft-mobileip-08. The lines are numbered to make them referencable in the discussion. *01 1.2 Inter-Realm Mobile IP *02 *03 [...] *04 *05 For new sessions, the AAAH MUST create an accounting session *06 identifier, which is added to the Accounting-Multi-Session-Id AVP in *07 the HAR message sent to the home agent. *08 *09 During the creation of the HAR, the AAAH MUST use a different session *10 identifier than the one used in the AMR/AMA (see figure 2). Of *11 course, an AAAH MUST use the same session identifier for all HARs *12 initiated on behalf of a given mobile node's session. [...] *13 (1) According to the Introduction, an AAAH may be session-stateless. I don't think a session-stateless AAAH can differentiate a new session from a handoff of an existing session. Therefore a session-stateless AAAH couldn't send the same session-id for handoffs, as stated in line *11. *14 [...] *15 *16 Upon receipt of the HAR, the Home Agent first processes the Diameter *17 message. [...] The Accounting-Multi-Session-Id AVP in *18 the HAR MUST be included in the HAA, which is then forwarded to the *19 AAAH. *20 (2) The last sentence is not quite right. While the HA does send an Accounting-Multi-Session-Id AVP in the HAA, it may be a different one than was received in the HAR. (see lines *44-*46). *25 1.3 Support for Mobile IP Handoffs *26 *27 [...] *28 *29 Since the new AAAH in the home network MAY not have access to the *30 session identifier that was used by the old AAAH, it is necessary for *31 the resulting HAR received by the HA to be identified as a *32 continuation of an existing session. If the HA receives an HAR for a *33 mobile node, with a new session identifier, and the HA can guarantee *34 that this request is to extend service for an existing service, then *35 the HA MUST be able to modify its internal session state information *36 to reflect the new AAAH and session identifier. The HA MUST also *37 issue an STR message with the old session identifier to the AAAH it *38 was communicating with when using the old session identifier. *39 *40 It is necessary for accounting records to have some commonality *41 across handoffs in order for correlation to occur. Therefore, in the *42 event that a home agent receives an HAR with a different Accounting- *43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the *44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP *45 that was received by the AAAH in the first HAR for the mobile's *46 session. This modified Accounting-Multi-Session-Id AVP will be *47 returned to the foreign agent by the AAAH in the AMA. Both the *48 foreign and home agents MUST include the Accounting-Multi-Session-Id *49 in the accounting messages. *50 (3) Since the AAAH must be prepared to have the AAAH-generated Accounting-Multi-Session-Id overridden by the HA, the protocol should change to just have the HA always specify the Accounting-Multi-Session-Id. The thinking is that the HA is constant over the MN's session, while the AAAHs and AAAFs and FAs change. So the HA is in a position to specify a constant Accounting-Multi-Session-Id, eliminating the extra complications of a switcheroo. The proposal is that the AAAH will not send a Accounting-Multi-Session-Id in the HAR. The HA MUST send a Accounting-Multi-Session-Id in the HAA. All of the messages for a MN's session will have the same value for the Accounting-Multi-Session-Id AVP. (4) Since the AAAH may be session-stateless, the HA would send the STR to the AAAH, as indicated in lines *36-*38, if and only if the AAAH has changed. Requested change: In Section 1.2 Inter-Realm Mobile IP Replace: "For new sessions, the AAAH MUST create an accounting session identifier, which is added to the Accounting-Multi-Session-Id AVP in the HAR message sent to the home agent. "During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA (see figure 2). Of course, an AAAH MUST use the same session identifier for all HARs initiated on behalf of a given mobile node's session. [...] With: "During the creation of the HAR, the AAAH MUST use a different session identifier than the one used in the AMR/AMA. "If the AAAH is session-stateful, it should send the same session identifier for all HARs initiated on behalf of a given mobile node's session. "If the AAAH is not session-stateful, it will manufacture a unique session-id for every HAR. (Note--This will not cause a problem for the HA, who must be able to recognize a handoff even if the AAAH thinks the session is new; an AAAH may incorrectly view a session as new when the handoff AMR goes to a different AAAH than the previous AMR). - - - - In Section 1.2 Inter-Realm Mobile IP Replace the last sentence of the following paragraph: Upon receipt of the HAR, the Home Agent first processes the Diameter message. [...] The Accounting-Multi-Session-Id AVP in the HAR MUST be included in the HAA, which is then forwarded to the AAAH. With: The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA returned to the AAAH. - - - - In section 1.3 Support for Mobile IP Handoffs Replace: Since the new AAAH in the home network MAY not have access to the session identifier that was used by the old AAAH, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the new AAAH and session identifier. The HA MUST also issue an STR message with the old session identifier to the AAAH it was communicating with when using the old session identifier. It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, in the event that a home agent receives an HAR with a different Accounting- Multi-Session-id AVP (and obviously a different Session-Id AVP), the home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP that was received by the AAAH in the first HAR for the mobile's session. This modified Accounting-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Accounting-Multi-Session-Id in the accounting messages. With: "Since the new AAAH in the home network MAY not have access to the session identifier that was used by the old AAAH, or since the AAAH may be session-stateless, it is necessary for the resulting HAR received by the HA to be identified as a continuation of an existing session. "If the HA receives an HAR for a mobile node, with a new session identifier, and the HA can guarantee that this request is to extend service for an existing service, then the HA MUST be able to modify its internal session state information to reflect the (possibly) new AAAH and new session identifier. "If the AAAH is new, the HA MUST also issue an STR message with the old session identifier to the AAAH it was communicating with when using the old session identifier. "It is necessary for accounting records to have some commonality across handoffs in order for correlation to occur. Therefore, the home agent MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for the mobile's session. That is, the HA generates a unique Accounting-Multi-Session-Id when receiving an HAR for a new session, and returns this same value in every HAA for the session. "This Accounting-Multi-Session-Id AVP will be returned to the foreign agent by the AAAH in the AMA. Both the foreign and home agents MUST include the Accounting-Multi-Session-Id in the accounting messages." - - - - In Section 1.5 "Co-located Mobile Node" Add the following sentence: "The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to the AAAH, as the AAAH may find this a useful piece of session-state or log entry information." - - - - In section 2.3 Home-Agent-MIP-Request Remove { Accounting-Multi-Session-Id } from the message ABNF. - - - - In section 2.4 Home-Agent-MIP-Answer Change [ Accounting-Multi-Session-Id ] to { Accounting-Multi-Session-Id } in the message ABNF. - - - - In section 8.1 Mobile IP Command AVP Table, Add an entry for the Accounting-Multi-Session-Id AVP. Attribute Name | AMR | AMA | HAR | HAA | ------------------------------|-----+-----+-----+-----+ Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 | - - - - In section 8.2 Accounting AVP Table Add an entry for the Accounting-Multi-Session-Id AVP. Attribute Name | ACR | ACA | ------------------------------|-----+-----+ Accounting-Multi-Session-Id | 1 | 0-1 | From owner-aaa-wg@merit.edu Wed Feb 27 11:06:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29403 for ; Wed, 27 Feb 2002 11:06:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AC8359131B; Wed, 27 Feb 2002 11:06:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79C6F9131D; Wed, 27 Feb 2002 11:06:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 63A229131B for ; Wed, 27 Feb 2002 11:06:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 396E25DDD2; Wed, 27 Feb 2002 11:06:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id AFAD45DD9D for ; Wed, 27 Feb 2002 11:06:46 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at 223lan160.iprolink.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@193.189.223.160) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 16:06:39 -0000 Message-Id: <5.1.0.14.0.20020227170132.03c7b5a0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 17:06:27 +0100 To: David Spence From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: <3C7D0223.28C21CFC@Interlinknetworks.com> References: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi David, At 16:58 27/02/2002, David Spence wrote: >Yes, this issue is about the same thing. If this issue had been resolved as >you proposed, we wouldn't be dealing with it again now. Indeed. It was felt at the time that "things worked OK like they were and the change was not needed". Apparently it came back to bite us :-) >I do have one question about your DiameterIdentity proposal. You included a >field for transport protocol. I think you would have to require that the >same identity is used in all Diameter messages even if the Diameter node had >multiple peers using multiple transport protocols. But with that >requirment, it would be o.k. I don't have time just now to research what >the resolution to your issue was, but I do think that had the issue been >accepted, we wouldn't need to be discussing it now. The idea (which might not have been expressed clearly in the proposed changes) is that a process should, on startup, pick one of the connections it's listening on. Anyone. For some servers the choice is easy (listening on one single IP, one single port, one single protocol). For others which listen on multiple IPs, ports, or protocols, they just pick one. Then they use that one to build their DiameterIdentity, and use it as long as the process exists to identify themselves, whatever the connection it's used on (since the goal is to identify a process, not a connection). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 11:07:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29432 for ; Wed, 27 Feb 2002 11:07:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDD9E9131D; Wed, 27 Feb 2002 11:07:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD2589131F; Wed, 27 Feb 2002 11:07:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABA319131D for ; Wed, 27 Feb 2002 11:07:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8802C5DDCA; Wed, 27 Feb 2002 11:07:16 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 06CC65DD9D for ; Wed, 27 Feb 2002 11:07:16 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RG9Fx01976 for ; Wed, 27 Feb 2002 10:09:15 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 10:07:06 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 10:06:58 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFA8.C8946264" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 10:06:58 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12853@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/oeAk4xw1YlMIQlqy9RzcXzgP5AABuBqA From: To: , , Cc: X-OriginalArrivalTime: 27 Feb 2002 16:06:58.0911 (UTC) FILETIME=[C8E77EF0:01C1BFA8] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1BFA8.C8946264 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat R. Calhoun [pcalhoun@bstormnetworks.com] wrote: =20 >>=20 >> My problem with the D-bit is that it invites doing something in=20 >> real time that does not need to be done in real time, and puts a=20 >> burden on the sender while saving very little if anything for the=20 >> receiver. The biller is going to sort the records anyway, and=20 >> finding adjacent=20 >> duplicates is trivial with or without the D-bit.=20 >>=20 >> Barney Wolff=20 > >But there are cases when billing actually takes place in real time,=20 >called prepaid charging. So the usage of the D-bit would make a=20 >significant performance improvement for the receiver in these cases.=20 > > I seriously don't understand the insistence on using User-Name=20 >for the lookup.=20 > >Not only is there a Session-Id, which is unique, but=20 >there is also an accounting record number. Those two items are=20 >guaranteed to be unique, and therefore are a great way of checking=20 >for dups. I don't understand the mechanism by which records are put=20 >in a "temporary" buffer, as opposed on written on disk. You need to=20 >write ALL records in this "temporary" buffer (if it even exists) in=20 >order to check for duplicates.=20 > >What really confuses me here is how the checks are done. Using a=20 >single bit 'D' isn't really useful for a lookup.=20 =20 It is useful. Either you believe that every record is a potential duplicate and hence do duplicate checks of every record against every other record (records within a certain duration +/- 24 hrs for eg.) or you do the check for duplicates only on records that have the "D" bit marked explicitly. So the "D" bit improves the performance by a significant enough margin. =20 >Some additional data is required, and whether the 'D' bit is set or >not, the message must be cached for duplicate check (to handle out of >order packets). =20 =20 I agree, but repeating what I have been saying, the "D" bit reduces the number of records that are checked for duplicates. =20 > >Confused,=20 =20 Let me see if I can send a more detailed explanation that would help.=20 =20 > >PatC=20 > =20 -Basavaraj ------_=_NextPart_001_01C1BFA8.C8946264 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

Pat R. Calhoun [pcalhoun@bstormnetworks.com] wrote:
 
>>
>> My problem with the D-bit is that it invites = doing=20 something in
>> real  time that does not need to be done = in real=20 time, and puts a
>> burden on  the sender while saving = very=20 little if anything for the
>> receiver. The  biller is = going to=20 sort the records anyway, and
>> finding adjacent
>>=20 duplicates is trivial with or without the D-bit.
>> =
>>=20 Barney Wolff
>
>But there are cases when billing actually = takes=20 place in real time,
>called prepaid charging. So the usage of the = D-bit=20 would make a
>significant performance improvement for the = receiver in=20 these cases.
>
><PRC> I seriously don't understand = the=20 insistence on using User-Name
>for the lookup. =
>
>Not only=20 is there a Session-Id, which is unique, but
>there is also an = accounting=20 record number. Those two items are
>guaranteed to be unique, and=20 therefore are a great way of checking
>for dups. I don't = understand the=20 mechanism by which records are put
>in a "temporary" buffer, as = opposed=20 on written on disk. You need to
>write ALL records in this = "temporary"=20 buffer (if it even exists) in
>order to check for duplicates.=20
>
>What really confuses me here is how the checks are done. = Using a=20
>single bit 'D' isn't really useful for a lookup.
 
It is useful. Either you believe that every record is a=20 potential
duplicate and hence do duplicate checks of every record = against=20 every
other record (records within a certain duration +/- 24 hrs for = eg.)=20 or
you do the check for duplicates only on records that have the "D"=20 bit
marked explicitly. So the "D" bit improves the performance by=20 a
significant enough margin.
 
>Some additional data is required, and whether the 'D' bit is = set=20 or
>not, the message must be cached for duplicate check (to handle = out=20 of
>order packets). 
 
I agree, but repeating what I have been saying, the "D" bit = reduces
the=20 number of records that are checked for duplicates.
 
>
>Confused,
 
Let me see if I can send a more detailed explanation that = would
help.=20
 
>
>PatC
>
 
-Basavaraj
------_=_NextPart_001_01C1BFA8.C8946264-- From owner-aaa-wg@merit.edu Wed Feb 27 11:13:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29696 for ; Wed, 27 Feb 2002 11:13:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E4A739131F; Wed, 27 Feb 2002 11:12:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B3F2C91320; Wed, 27 Feb 2002 11:12:58 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 89D779131F for ; Wed, 27 Feb 2002 11:12:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 72D665DDD2; Wed, 27 Feb 2002 11:12:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 263505DD9D for ; Wed, 27 Feb 2002 11:12:57 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA27561 for ; Wed, 27 Feb 2002 09:12:36 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA09459 for ; Wed, 27 Feb 2002 09:00:59 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Wed, 27 Feb 2002 10:12:35 -0600 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Tony Johansson'" , Thomas Panagiotis-PTHOMAS1 Cc: "Pat R. Calhoun" , Bob Kopacz , aaa-wg Subject: RE: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP Date: Wed, 27 Feb 2002 10:12:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk Yes -Panos > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Tuesday, February 26, 2002 11:25 PM > To: Thomas Panagiotis-PTHOMAS1 > Cc: Pat R. Calhoun; Bob Kopacz; aaa-wg > Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP > > > So, do you want me to remove the recommendation and then it is OK? > > /Tony > > Thomas Panagiotis-PTHOMAS1 wrote: > > > Tony, > > > > "The value of the MIP-Key-Lifetime AVP MUST be at least equal to > > the value in the Authorization Lifetime AVP. If the value > is greater, > > it SHOULD be a multiple of the value in the Authorization > Lifetime AVP." > > > > Recommending the MIP-Key-Lifetime to be a multiple of the MIP > > (Authorization) > > lifetime doesn't mean much when you don't want to go > through AAA upon every > > handoff - the two timers will soon get out of sync. > > > > -Panos > > > > -----Original Message----- > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > Sent: Monday, February 25, 2002 7:21 PM > > To: Pat R. Calhoun > > Cc: Bob Kopacz; aaa-wg > > Subject: Re: [AAA-WG]: Re: Pending Issue about MIP-Key-Lifetime AVP > > > > > > "Pat R. Calhoun" wrote: > > > > > But, in the AAA Registration Keys for Mobile IP, which we are > > > dependent on, you can only > tell the mobile one timer (the > > > Lifetime). The Lifetime AAA Registration Keys for Mobile IP > > > indicates the duration of time (in seconds) for which the > MN-FA and > > > MN-HA keys are valid. When the keys expires the MN must re-auth, > > > so seen from the MN the authorization lifetime and the key > > > lifetime is very much the same thing. Right? > > But there is a fundamental difference between the Lifetime field in > > the MIP header, and the lifetime fields in the individual aaa-key > > extensions. Right? > > > > Ahh, the Authorization lifetime is used for the tunnel > update and the > > MIP-Key lifetime is used for the keys.... > > So, what about to following additional text to the draft to > explain / > > clarify the usage of the MIP-Key-Lifetime AVP and > Authorization Lifetime > > AVP, see below. All, comments / objections. > > Regards, > > /Tony > > "1.6 Diameter Session Termination > > A Foreign and Home Agent following this specification MAY expect > > their respective Diameter servers to maintain session state > > information for each mobile node in their networks. In > order for the > > Diameter Server to release any resources allocated to a specific > > mobile node, the mobility agents MUST send a Session-Termination- > > Request (STR) to the Diameter server that authorized the > service. The > > Session-Termination-Request (STR) MUST be issued by the mobility > > agents if the Authorization Lifetime has expired and no > subsequent > > MIP registration request have been received. > > ........ " > > > > New section: > > > > "5.1 Authorization Lifetime vs. MIP Key Lifetime > > > > The Diameter Mobile IP application makes use of two timers the > > Authorization-Lifetime AVP [DIAMBASE] and the > MIP-Key-Lifetime AVP. > > The Authorization-Lifetime contains the number of > seconds before the > > Mobile Node must issue a subsequent MIP registration request. The > > content of Authorization-Lifetime AVP corresponds to the Lifetime > > field in the MIP header [MOBILEIP]. > > The MIP-Key-Lifetime AVP contains the number of seconds before > > session keys destined for the Home Agent and/or Foreign > Agent expire. > > A value of zero indicates infinity (no timeout). The value of the > > MIP-Key-Lifetime AVP MUST be at least equal to the value in the > > Authorization Lifetime AVP. If the value is greater, it > SHOULD be a > > multiple of the value in the Authorization Lifetime AVP." > From owner-aaa-wg@merit.edu Wed Feb 27 11:38:41 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01068 for ; Wed, 27 Feb 2002 11:38:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6313391322; Wed, 27 Feb 2002 11:33:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17F6091324; Wed, 27 Feb 2002 11:33:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC44E91322 for ; Wed, 27 Feb 2002 11:33:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8D3C65DDDA; Wed, 27 Feb 2002 11:33:20 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id 25E4F5DDE2 for ; Wed, 27 Feb 2002 11:33:20 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SD11>; Wed, 27 Feb 2002 08:33:19 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Basavaraj.Patil@nokia.com'" , anne.narhi@nokia.com, barney@databus.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Wed, 27 Feb 2002 08:33:18 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFAC.7674A2C0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BFAC.7674A2C0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >Not only is there a Session-Id, which is unique, but >there is also an accounting record number. Those two items are >guaranteed to be unique, and therefore are a great way of checking >for dups. I don't understand the mechanism by which records are put >in a "temporary" buffer, as opposed on written on disk. You need to >write ALL records in this "temporary" buffer (if it even exists) in >order to check for duplicates. > >What really confuses me here is how the checks are done. Using a >single bit 'D' isn't really useful for a lookup. It is useful. Either you believe that every record is a potential duplicate and hence do duplicate checks of every record against every other record (records within a certain duration +/- 24 hrs for eg.) or you do the check for duplicates only on records that have the "D" bit marked explicitly. So the "D" bit improves the performance by a significant enough margin. But what about packets that are received out of order (D bit is received First)? PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPH0KTzN1fXKoxmisEQJ1SgCglfnA/QO8f1SB+p9fPPNPkUtKBpkAn0bv U2OFEC5xQYFN2PFYSHH5Gw0k =aJAJ -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BFAC.7674A2C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>Not only is there a Session-Id, which is unique, = but
>there is also an accounting record number. Those = two items are
>guaranteed to be unique, and therefore are a = great way of checking
>for dups. I don't understand the mechanism by = which records are put
>in a "temporary" buffer, as opposed on = written on disk. You need to
>write ALL records in this "temporary" = buffer (if it even exists) in
>order to check for duplicates.
>
>What really confuses me here is how the checks = are done. Using a
>single bit 'D' isn't really useful for a lookup. =

It is useful. Either you believe that every record is = a potential
duplicate and hence do duplicate checks of every = record against every
other record (records within a certain duration +/- = 24 hrs for eg.)
or
you do the check for duplicates only on records that = have the "D" bit
marked explicitly. So the "D" bit improves = the performance by a
significant enough margin.

<PRC> But what about packets that are received = out of order (D bit is
received
First)?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPH0KTzN1fXKoxmisEQJ1SgCglfnA/QO8f1SB+p9fPPNPkUtKBpkAn0b= v
U2OFEC5xQYFN2PFYSHH5Gw0k
=3DaJAJ
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BFAC.7674A2C0-- From owner-aaa-wg@merit.edu Wed Feb 27 11:50:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02001 for ; Wed, 27 Feb 2002 11:50:56 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D2AA91323; Wed, 27 Feb 2002 11:50:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C7DE91324; Wed, 27 Feb 2002 11:50:46 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14A7891323 for ; Wed, 27 Feb 2002 11:50:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id E3A3A5DDDA; Wed, 27 Feb 2002 11:50:44 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 092BF5DDD2 for ; Wed, 27 Feb 2002 11:50:44 -0500 (EST) Received: from jariws1 ([62.248.152.200]) by fep02-app.kolumbus.fi with SMTP id <20020227165038.FNXP27811.fep02-app.kolumbus.fi@jariws1>; Wed, 27 Feb 2002 18:50:38 +0200 Message-ID: <00ba01c1bfae$ea4527e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Pat R. Calhoun" , , , Cc: References: Subject: Re: [AAA-WG]: Request for closure on issue 235 Date: Wed, 27 Feb 2002 18:50:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit RE: [AAA-WG]: Request for closure on issue 235> But what about packets that are received out of order > (D bit is received First)? 1. D bit record is first received, and you search all records, no match. you also search the pool, no match. you put it to a pool. 2. non-D bit record is received after that, and you search the pool (not all records) So, using the current scheme you do 2 all-records searches total. Using the d-bit method you do 1 all-records search and 2 pool searches. Worth it? If the pool searches are significantly faster. (Basavaraj, you do have to make some full searches anyway!) Jari From owner-aaa-wg@merit.edu Wed Feb 27 11:55:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02681 for ; Wed, 27 Feb 2002 11:55:09 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DA00F91324; Wed, 27 Feb 2002 11:55:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A53CF91325; Wed, 27 Feb 2002 11:55:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 957DA91324 for ; Wed, 27 Feb 2002 11:54:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7581C5DD9D; Wed, 27 Feb 2002 11:54:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 2C5355DD91 for ; Wed, 27 Feb 2002 11:54:59 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1RGme802014; Wed, 27 Feb 2002 11:48:40 -0500 Message-ID: <3C7D0DE7.B7D6728A@interlinknetworks.com> Date: Wed, 27 Feb 2002 11:48:39 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jacques Caron Cc: David Spence , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> <5.1.0.14.0.20020227170132.03c7b5a0@pop.mail.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id LAA02681 I am not in favor of advertising a DiameterIdentity over a connection if the DiameterIdentity does not reflect settings actually used on the connection. I think the DiameterIdentity used to be an FQDN. There was concern that multiple Diameter nodes on a host could not be uniquely identified, so the DiameterIdentity changed to be FQDN plus port plus protocol. More recently, transport security was added to the DiameterIdentity. I'd like to consider changing DiameterIdentity back to being an FQDN. Proposed Text: A Diameter node must be uniquely identified by its DiameterIdentity, which is an FQDN. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. End Proposed Text This solves the problem of uniquely identifying Diameter nodes running on a single host and keeps the DiameterIdentity simple. The URI syntax (or something similar) is still required for Diameter Peer Discovery, but not for the DiameterIdentity. Sorry for suggesting this at this late date, but I wonder what others think. Don Z. Jacques Caron wrote: > Hi David, > > At 16:58 27/02/2002, David Spence wrote: > >Yes, this issue is about the same thing. If this issue had been resolved as > >you proposed, we wouldn't be dealing with it again now. > > Indeed. It was felt at the time that "things worked OK like they were and > the change was not needed". Apparently it came back to bite us :-) > > >I do have one question about your DiameterIdentity proposal. You included a > >field for transport protocol. I think you would have to require that the > >same identity is used in all Diameter messages even if the Diameter node had > >multiple peers using multiple transport protocols. But with that > >requirment, it would be o.k. I don't have time just now to research what > >the resolution to your issue was, but I do think that had the issue been > >accepted, we wouldn't need to be discussing it now. > > The idea (which might not have been expressed clearly in the proposed > changes) is that a process should, on startup, pick one of the connections > it's listening on. Anyone. For some servers the choice is easy (listening > on one single IP, one single port, one single protocol). For others which > listen on multiple IPs, ports, or protocols, they just pick one. > > Then they use that one to build their DiameterIdentity, and use it as long > as the process exists to identify themselves, whatever the connection it's > used on (since the goal is to identify a process, not a connection). > > Jacques. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 11:55:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02731 for ; Wed, 27 Feb 2002 11:55:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BCF5391325; Wed, 27 Feb 2002 11:55:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 924C991326; Wed, 27 Feb 2002 11:55:35 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7871991325 for ; Wed, 27 Feb 2002 11:55:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5EFFC5DDDA; Wed, 27 Feb 2002 11:55:34 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id C1DA75DD91 for ; Wed, 27 Feb 2002 11:55:33 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1RGtLe26367 for ; Wed, 27 Feb 2002 16:55:21 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 27 Feb 2002 16:50:27 +0000 Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA03570; Wed, 27 Feb 2002 16:55:11 GMT Message-ID: <3C7D0F70.2ADDFC20@baltimore.ie> Date: Wed, 27 Feb 2002 16:55:12 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A6A@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit After some off-list discussion it appears that the following is the correct interpretation of the "MAY encr" column: "For the originator of a Diameter message, "MAY encr" means that if a message containing that AVP is to be sent via a proxy/agent then the message MUST NOT be sent unless there is a DSA between the originator and the recipient OR the originator has locally trusted configuration that indicates that CMS need not be used." I'll put this into CMS, but would also recommend it go somewhere in the base. On a related issue, the CMS draft is currently overly restrictive in instructing proxies to prevent DSA establishment. The suggestion is to change this to the following: "Proxys that modify AVPs MAY prevent the establishment of DSAs based on local configuration." With these two changes, I think this (and the pre-historic issue 221) can both be closed. Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Feb 27 11:58:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02904 for ; Wed, 27 Feb 2002 11:58:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1D70A9132A; Wed, 27 Feb 2002 11:58:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA8B191329; Wed, 27 Feb 2002 11:58:29 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A277E91326 for ; Wed, 27 Feb 2002 11:58:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 886115DD9D; Wed, 27 Feb 2002 11:58:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (adsl-66-137-237-97.dsl.rcsntx.swbell.net [66.137.237.97]) by segue.merit.edu (Postfix) with SMTP id D62875DD91 for ; Wed, 27 Feb 2002 11:58:27 -0500 (EST) Received: (qmail 20676 invoked by uid 500); 27 Feb 2002 16:58:15 -0000 Date: Wed, 27 Feb 2002 10:58:15 -0600 From: David Frascone To: Don Zick Cc: Jacques Caron , David Spence , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Message-ID: <20020227165815.GI13242@newman.frascone.com> Mail-Followup-To: Don Zick , Jacques Caron , David Spence , john.loughney@nokia.com, aaa-wg@merit.edu References: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> <5.1.0.14.0.20020227170132.03c7b5a0@pop.mail.yahoo.com> <3C7D0DE7.B7D6728A@interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C7D0DE7.B7D6728A@interlinknetworks.com> User-Agent: Mutt/1.3.25i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk I like this. Much simpler. On Wednesday, 27 Feb 2002, Don Zick wrote: > I am not in favor of advertising a DiameterIdentity over a connection if the > DiameterIdentity does not reflect settings actually used on the connection. > > I think the DiameterIdentity used to be an FQDN. There was concern that > multiple Diameter nodes on a host could not be uniquely identified, so the > DiameterIdentity changed to be FQDN plus port plus protocol. More recently, > transport security was added to the DiameterIdentity. > > I'd like to consider changing DiameterIdentity back to being an FQDN. > > Proposed Text: > > A Diameter node must be uniquely identified by its DiameterIdentity, which is an > FQDN. If multiple Diameter nodes run on the same host, each Diameter node > MUST be assigned a unique DiameterIdentity. > > End Proposed Text > > This solves the problem of uniquely identifying Diameter nodes running on a > single host and keeps the DiameterIdentity simple. > > The URI syntax (or something similar) is still required for Diameter Peer > Discovery, but not for the DiameterIdentity. > > Sorry for suggesting this at this late date, but I wonder what others think. > > Don Z. > > > Jacques Caron wrote: > > > Hi David, > > > > At 16:58 27/02/2002, David Spence wrote: > > >Yes, this issue is about the same thing. If this issue had been resolved as > > >you proposed, we wouldn't be dealing with it again now. > > > > Indeed. It was felt at the time that "things worked OK like they were and > > the change was not needed". Apparently it came back to bite us :-) > > > > >I do have one question about your DiameterIdentity proposal. You included a > > >field for transport protocol. I think you would have to require that the > > >same identity is used in all Diameter messages even if the Diameter node had > > >multiple peers using multiple transport protocols. But with that > > >requirment, it would be o.k. I don't have time just now to research what > > >the resolution to your issue was, but I do think that had the issue been > > >accepted, we wouldn't need to be discussing it now. > > > > The idea (which might not have been expressed clearly in the proposed > > changes) is that a process should, on startup, pick one of the connections > > it's listening on. Anyone. For some servers the choice is easy (listening > > on one single IP, one single port, one single protocol). For others which > > listen on multiple IPs, ports, or protocols, they just pick one. > > > > Then they use that one to build their DiameterIdentity, and use it as long > > as the process exists to identify themselves, whatever the connection it's > > used on (since the goal is to identify a process, not a connection). > > > > Jacques. > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com -- David Frascone I failed attitude in school. From owner-aaa-wg@merit.edu Wed Feb 27 12:02:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03210 for ; Wed, 27 Feb 2002 12:02:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 6043191327; Wed, 27 Feb 2002 12:01:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3249F91329; Wed, 27 Feb 2002 12:01:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B4E991328 for ; Wed, 27 Feb 2002 12:01:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 61E045DDDC; Wed, 27 Feb 2002 12:01:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F14585DDDA for ; Wed, 27 Feb 2002 12:01:34 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1RGL7X11553 for ; Wed, 27 Feb 2002 08:21:08 -0800 Date: Wed, 27 Feb 2002 08:21:07 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Missed issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk It is been brought to our attention that some issues have been raised and may not have made it onto the issues list. If you have raised an issue prior to last week, and it has not made it to the issues list in some form, PLEASE file the issue again. http://www.drizzle.com/~aboba/AAA/issues.html http://www.drizzle.com/~aboba/AAA/newissues.txt From owner-aaa-wg@merit.edu Wed Feb 27 12:09:49 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03705 for ; Wed, 27 Feb 2002 12:09:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2971B91342; Wed, 27 Feb 2002 12:06:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0C3791328; Wed, 27 Feb 2002 12:06:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1586C91342 for ; Wed, 27 Feb 2002 12:05:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA5355DD9D; Wed, 27 Feb 2002 12:05:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id 6B4C15DD91 for ; Wed, 27 Feb 2002 12:05:38 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at 223lan160.iprolink.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@193.189.223.160) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 17:05:33 -0000 Message-Id: <5.1.0.14.0.20020227175828.03c93178@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 18:04:37 +0100 To: Don Zick From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: David Spence , john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: <3C7D0DE7.B7D6728A@interlinknetworks.com> References: <5.1.0.14.0.20020227145318.03883b60@pop.mail.yahoo.com> <5.1.0.14.0.20020227170132.03c7b5a0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 17:48 27/02/2002, Don Zick wrote: >I am not in favor of advertising a DiameterIdentity over a connection if the >DiameterIdentity does not reflect settings actually used on the connection. Other than the issue of checking the "validity" of the identity received, I think the DiameterIdentity should really be considered as an opaque unique identifier. The exact contents are totally irrelevant, as long as: - the identity is unique - the identity is constant for a given process Anything that matches this is OK. Really, it might just be a random number selected at startup, if that provided enough uniqueness. And the more "opaque" it looks, the less chances somebody will try to use it for what it isn't, but that's really cosmetic. >I'd like to consider changing DiameterIdentity back to being an FQDN. > >Proposed Text: > >A Diameter node must be uniquely identified by its DiameterIdentity, which >is an >FQDN. If multiple Diameter nodes run on the same host, each Diameter node >MUST be assigned a unique DiameterIdentity. > >End Proposed Text This does indeed meet the requirements. Note that the identity should in my opinion really be just the FQDN, without any "aaa://" prefix to avoid confusion. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 12:09:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03717 for ; Wed, 27 Feb 2002 12:09:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AB8BF91328; Wed, 27 Feb 2002 12:07:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70D3F9134B; Wed, 27 Feb 2002 12:07:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6EBD491328 for ; Wed, 27 Feb 2002 12:07:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4A4145DDDA; Wed, 27 Feb 2002 12:07:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id BD51F5DD91 for ; Wed, 27 Feb 2002 12:07:46 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RH7pG24762 for ; Wed, 27 Feb 2002 11:07:51 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 11:07:35 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 11:07:35 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 11:07:35 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A1285A@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/nzlqhvurP/cVRtObTu9ocpODoAAEfwfw From: To: , Cc: , X-OriginalArrivalTime: 27 Feb 2002 17:07:35.0801 (UTC) FILETIME=[40A8DE90:01C1BFB1] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA03717 Jari Arkko [Jari.Arkko@lmf.ericsson.se] wrote: >The prepaid case is a valid one. So D-bit is useful when >the following condition is fulfilled: > >RealTimeBilling AND PoolLookUpFasterThanSessionIdLookUp AND >PoolLookUpFasterThanUserNameLookUp > >Since the D-bit method also requires SessionId look-ups in >certain cases, we always need a reasonably fast look-up >anyway i.e. linear list of all records is not acceptable for >D-bit either. So this really boils down to the question of >whether the pool lookup (small and likely in RAM) is faster >than a real record lookup (likely on disk but index likely >in RAM). In certain cases, the pool lookup (in RAM) would be preferred and hence the need to have the "D" bit. I agree with your assesment of when the "D" bit is applicable. > >Jari -Basavaraj From owner-aaa-wg@merit.edu Wed Feb 27 12:20:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04335 for ; Wed, 27 Feb 2002 12:20:20 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 353DB9132D; Wed, 27 Feb 2002 12:20:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE54D9132B; Wed, 27 Feb 2002 12:20:02 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0870D9132E for ; Wed, 27 Feb 2002 12:20:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id C02015DDDA; Wed, 27 Feb 2002 12:20:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 357EF5DD91 for ; Wed, 27 Feb 2002 12:20:00 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1RHJwe27181 for ; Wed, 27 Feb 2002 17:19:58 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 27 Feb 2002 17:15:04 +0000 Received: from baltimore.ie (wks149-6.ie.baltimore.com [10.153.6.149]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA04059; Wed, 27 Feb 2002 17:19:55 GMT Message-ID: <3C7D153B.207D710B@baltimore.ie> Date: Wed, 27 Feb 2002 17:19:55 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: [issue] Remove references to CMS-Cert in cms-sec-03 References: <3C7BF606.D063BEDF@Interlinknetworks.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Done. Stephen. David Spence wrote: > > Subject: [issue] Remove references to CMS-Cert in cms-sec-03 > > Submitter name: David Spence > Submitter email address: DSpence@Interlinknetworks.com > Date first submitted: February 26, 2002 > Reference: > Document: cms-sec > Comment type: E > Priority: S > Section: many > Rationale/Explanation of issue: > > Cms-sec-02 defined an AVP called CMS-Cert. This AVP was removed in > cms-sec-03, however many references to it remain. > > Requested change: > > Remove all references to the CMS-Cert AVP. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Feb 27 12:28:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04731 for ; Wed, 27 Feb 2002 12:28:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E9B5891206; Wed, 27 Feb 2002 12:28:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BBBB791329; Wed, 27 Feb 2002 12:28:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFDB491206 for ; Wed, 27 Feb 2002 12:28:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id B33CC5DDDA; Wed, 27 Feb 2002 12:28:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4FC115DD91 for ; Wed, 27 Feb 2002 12:28:41 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g1RGmk813140 for ; Wed, 27 Feb 2002 08:48:47 -0800 Date: Wed, 27 Feb 2002 08:48:46 -0800 (PST) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Spec for the Originating-Line-Info AVP? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The IANA RADIUS allocation page: http://www.iana.org/assignments/radius-types discloses allocation of attribute #94 to Originating-Line-Info, with Nenad Trifunovic as author. Is anyone aware of a spec for this? We are looking to support all the existing RADIUS attributes in Diameter NASREQ. From owner-aaa-wg@merit.edu Wed Feb 27 12:31:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04961 for ; Wed, 27 Feb 2002 12:31:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id DDC9A91329; Wed, 27 Feb 2002 12:30:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A923D9132F; Wed, 27 Feb 2002 12:30:28 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4F4691329 for ; Wed, 27 Feb 2002 12:30:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id CA8435DDDA; Wed, 27 Feb 2002 12:30:26 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by segue.merit.edu (Postfix) with ESMTP id 3C6235DD91 for ; Wed, 27 Feb 2002 12:30:26 -0500 (EST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g1RHUPe27534 for ; Wed, 27 Feb 2002 17:30:25 GMT Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 27 Feb 2002 17:25:31 +0000 Received: from baltimore.ie (wks149-6.ie.baltimore.com [10.153.6.149]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA04300; Wed, 27 Feb 2002 17:30:20 GMT Message-ID: <3C7D17AC.4EB648F5@baltimore.ie> Date: Wed, 27 Feb 2002 17:30:20 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: anny5@etri.re.kr Cc: jari.arkko@kolumbus.fi, aaa-wg@merit.edu Subject: Re: [AAA-WG]: =?iso-8859-1?Q?=5B=C0=FC=C3=BC=C8=B8=BD=C5=5D?= Re: [AAA-WG]: CMS Question References: <8470181DABD5D511B3E700D0B7A8AC4A69E2BE@cms3.etri.re.kr> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > anny5@etri.re.kr wrote: > > I think DSA/DSAA message contain several AAA-Node-Cert AVP . AAA-Node-Cert AVP contains > certificates of > > AAA hosts in same realm. > > if the size of one certificate is 700k and there is 5 hosts in same realm, does DSAR/DSAA( contain 700k!!! X.509 has been accused of bloat, but never that much bloat! Certificates are usually <2k. > > 3500k certificate - 5 AAA-Node-Cert AVPs ) message have to transport? > > also, if one realm and antoher realm(one host and one host) has a DSA, don't other hosts at these > > realm need to establish DSA? Without DSA establish step, the communocation is possible? That depends on how many of the hosts have access to the private key concerned. One option is that all the hosts use the same key pair (put all their names in the relevant certificate). Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-wg@merit.edu Wed Feb 27 14:33:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12595 for ; Wed, 27 Feb 2002 14:33:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A30D2912D8; Wed, 27 Feb 2002 14:33:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A23F9132E; Wed, 27 Feb 2002 14:32:45 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BFC70912D8 for ; Wed, 27 Feb 2002 14:32:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F0825DDDA; Wed, 27 Feb 2002 14:32:40 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 114A35DD91 for ; Wed, 27 Feb 2002 14:32:40 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJWtG04094 for ; Wed, 27 Feb 2002 13:32:55 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:32:38 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 13:32:17 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Clarifications on the "D" bit (Issue 235) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 13:32:17 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12864@daebe007.NOE.Nokia.com> Thread-Topic: Clarifications on the "D" bit (Issue 235) Thread-Index: AcG/xXbEnORMeCu0EdaxowAAhj/HZA== From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 19:32:17.0198 (UTC) FILETIME=[772CECE0:01C1BFC5] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA12595 Some clarifications regarding the "D" bit (Issue 235) : The "D" bit would be marked by the sender to indicate that it this is a potential duplicate. Receiving nodes (such as accounting servers) would use this information to check the duplicate marked records against other records in the cache. An advantage of the D-bit usage is that it is needed only in extremely rare cases (eg. when link totally fails and normal retries do not help within their timer expiry and retry counter ranges). In the absence of the "D" bit the pool searches would require the checking of every record against every other record all the time. In the normal case (which is probably >90% or even more) with the D-bit method the sender does absolutely no work in regards to the duplicate checking support. Only in the very rare case of a total link/recipient node failure, the failover procedures are invoked. And the sender does only the smallest imaginable effort: Setting of the Diameter header bit 4 of octet 5, to the possibly few yet unacknowledged messages that were sent just before link failure. So the sender does minimal work and that too as a rare occurence. On the receiving node it would also do minimal uniqueness support work: The receiver would normally only check for duplicates if the Diameter header bit 4 of octet 5 is set. In the very rare case a comparison of the D-bit marked record's Session-ID & Accounting-Record-Number AVP pair, against the recent/soon to be received accounting records using the ordinary Session-ID & Accounting-Record-Number would be performed. (And even that check could be made in an optimized way but that does not change the relative efficiency advantage of using the D-bit as the first-checked indicator.) Processing ========== 1) When ANY record is received, it is kept in a buffer for a configured amount of time (eg. 24h). Additionally: 2a) If the received record is D bit marked, it is compared to the previous near past (e.g. last 12h) received D-/non-D-marked records by the already defined 2 AVPs for uniqueness. Even if there is no match, the D-marked record is ALSO compared to all the future records (e.g. next 12h) which takes care of messages arriving out-of-order (or duplicates arriving after the node has received the D bit marked record). or 2b) If the received record is non-D-marked, it is compared to the near past(e.g. last 12h) received D-marked records by the already defined 2 AVPs for uniqueness. Even if there is no match, the non-D-marked record is ALSO compared to the near future D-marked records (e.g. next 12h), to avoid the message reordering problem. 3) If a match (duplicate) is found the _first_ received record of the duplicated pair is deleted, and the more recent one of the duplicated pair stays in the pool as long as the pool timer permits. -Basavaraj From owner-aaa-wg@merit.edu Wed Feb 27 14:42:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13280 for ; Wed, 27 Feb 2002 14:42:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2EFC9132E; Wed, 27 Feb 2002 14:42:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 823B99132F; Wed, 27 Feb 2002 14:42:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 466439132E for ; Wed, 27 Feb 2002 14:42:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 271FF5DDE0; Wed, 27 Feb 2002 14:42:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1335D5DD91 for ; Wed, 27 Feb 2002 14:42:36 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A8E507A; Wed, 27 Feb 2002 14:42:35 -0500 (EST) Message-ID: <3C7D36B1.AE3DAD03@Interlinknetworks.com> Date: Wed, 27 Feb 2002 14:42:41 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: johanj@ipunplugged.com, BKopacz@Interlinknetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [Issue] Routing of session messages defined in base References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A44@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------FCC91BFFDC9645BADEAAAD5B" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------FCC91BFFDC9645BADEAAAD5B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > > Hi all, > > Please give exact text for this issue to be added / modified to the > base spec. >... The Requested change section of Bob Kopacz' issue: Proxiable messages MUST contain Axxx-Application-Id AVP reads as follows: Requested change: 1. Require an Auth-Application-Id AVP in Session-Terminate-Request, Abort-Session-Request, and Re-Auth-Request messages. 2. Update occurrence rule tables for the "Auth-Application-Id AVP" row, from "0" to "1", for STR and ASR and RAR. For item 1, the STR syntax currently reads: ::= < Diameter Header: 275, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Termination-Cause } [ User-Name ] [ Destination-Host ] * [ Class ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] You need to add "{ Auth-Application-Id }": ::= < Diameter Header: 275, REQ, PXY > < Session-Id > { Origin-Host } { Origin-Realm } { Destination-Realm } { Auth-Application-Id } { Termination-Cause } [ User-Name ] [ Destination-Host ] * [ Class ] [ Origin-State-Id ] * [ AVP ] * [ Proxy-Info ] * [ Route-Record ] Do the same for ASR and RAR. For item 2, the table in base-08 section 10.1 currently begins: +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Change it to: +-----------------------------------------------+ | Command-Code | |---+---+---+---+---+---+---+---+---+---+---+---+ Attribute Name |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| --------------------|---+---+---+---+---+---+---+---+---+---+---+---| Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 |0 |0 | Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 |1 |0 | Additionally, Bob Kopacz recommends adding text to sections 6.1 and 6.1.1. The first sentence of the fourth paragraph of sec. 6.1 reads: The Destination-Realm AVP MUST be present if the message is routable. Replace with: The Destination-Realm AVP MUST be present if the message is proxiable. Proxiable request messages MUST also contain either an Acct-Application-Id AVP or an Auth-Application-Id AVP. Note that the term proxiable is defined in the draft. The term routable is not. So I changed routable to proxiable. Also note that the draft is inconsistent with respect to the spelling of proxiable, sometimes spelling it proxyable. It should be spelled consistently. Section 6.1.1 currently reads: When creating a request, in addition to any other procedures described in the application definition for that specific request, the following procedures MUST be followed: - the Command-Code should be set to the appropriate value - the 'R' bit should be set - the End-to-End Identifier should be set to a locally unique value - the Origin-Host and Origin-Realm AVPs MUST be set to the appropriate values, used to identify the source of the message - the Destination-Host and Destination-Realm AVPs MUST be set to the appropriate values as described in section 6.1. Add an additional bullet: - either an Acct-Application-Id AVP or an Auth-Application-Id AVP must be included if the request is proxiable. --------------FCC91BFFDC9645BADEAAAD5B Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------FCC91BFFDC9645BADEAAAD5B-- From owner-aaa-wg@merit.edu Wed Feb 27 14:45:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13424 for ; Wed, 27 Feb 2002 14:45:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B8F8691330; Wed, 27 Feb 2002 14:45:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BE87691334; Wed, 27 Feb 2002 14:45:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D11B9132F for ; Wed, 27 Feb 2002 14:44:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id E762D5DDE0; Wed, 27 Feb 2002 14:44:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 0F9CB5DD91 for ; Wed, 27 Feb 2002 14:44:57 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJj5Z15295 for ; Wed, 27 Feb 2002 21:45:05 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 21:44:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 21:44:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Wed, 27 Feb 2002 21:44:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/r38b7ImR4O98STOlqqZDe5BCSgAEKIWQ From: To: , Cc: , X-OriginalArrivalTime: 27 Feb 2002 19:44:55.0883 (UTC) FILETIME=[3B6311B0:01C1BFC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13424 Hi Don, > I am not in favor of advertising a DiameterIdentity over a > connection if the > DiameterIdentity does not reflect settings actually used on > the connection. > > I think the DiameterIdentity used to be an FQDN. There was > concern that > multiple Diameter nodes on a host could not be uniquely > identified, so the > DiameterIdentity changed to be FQDN plus port plus protocol. > More recently, > transport security was added to the DiameterIdentity. > > I'd like to consider changing DiameterIdentity back to being an FQDN. > > Proposed Text: > > A Diameter node must be uniquely identified by its > DiameterIdentity, which is an > FQDN. If multiple Diameter nodes run on the same host, each > Diameter node > MUST be assigned a unique DiameterIdentity. > > End Proposed Text > What I have added is the following: DiameterIdentity The DiameterIdentity format is derived from the OctetString AVP Base Format. It uses the UTF-8 encoding and has the same requirements as the UTF8String. In addition, it must follow the Uniform Resource Identifiers (URI) syntax [URI] rules specified below: DiameterIdentity = fqdn A Diameter node must be uniquely identified by its DiameterIdentity, which is an FQDN. If multiple Diameter nodes run on the same host, each Diameter node MUST be assigned a unique DiameterIdentity. Does this work? John From owner-aaa-wg@merit.edu Wed Feb 27 14:46:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13457 for ; Wed, 27 Feb 2002 14:46:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 91E429132F; Wed, 27 Feb 2002 14:45:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06A6291335; Wed, 27 Feb 2002 14:45:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 325CD91330 for ; Wed, 27 Feb 2002 14:44:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F7C25DDE0; Wed, 27 Feb 2002 14:44:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 54CAB5DD91 for ; Wed, 27 Feb 2002 14:44:58 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJj6Z15306 for ; Wed, 27 Feb 2002 21:45:06 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 21:44:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 21:44:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: RE: [issue] Minor corrections to draft-base-08 Date: Wed, 27 Feb 2002 21:44:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF5@esebe004.NOE.Nokia.com> Thread-Topic: [issue] Minor corrections to draft-base-08 Thread-Index: AcG/n4LIBOYwWT21QA2RejC2JSENbQAIdIeg From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 19:44:57.0205 (UTC) FILETIME=[3C2CCA50:01C1BFC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13457 Hi Bob, > Oh, sure. Even something shorter, "aaa://host.abc.com", > is plenty good for the example. Due the changes in the DiameterIdentity, the above is no longer valid. John From owner-aaa-wg@merit.edu Wed Feb 27 14:46:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13500 for ; Wed, 27 Feb 2002 14:46:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7A8DE91334; Wed, 27 Feb 2002 14:45:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3EED691338; Wed, 27 Feb 2002 14:45:04 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 80ED491332 for ; Wed, 27 Feb 2002 14:45:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3D0D55DDE0; Wed, 27 Feb 2002 14:45:00 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 69E935DD91 for ; Wed, 27 Feb 2002 14:44:59 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJjXi10500 for ; Wed, 27 Feb 2002 21:45:33 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 21:44:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 21:44:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 256: TLS Usage Issues - CLOSED Date: Wed, 27 Feb 2002 21:44:58 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF6@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 256: TLS Usage Issues Thread-Index: AcG/oqv30T6mEynMRpqF4JKlSiW6tQAHunaw From: To: Cc: X-OriginalArrivalTime: 27 Feb 2002 19:44:58.0424 (UTC) FILETIME=[3CE6CB80:01C1BFC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13500 Hi Don, > A Diameter node that initiates a connection to another Diameter node acts > as a TLS client according to [RFC2246], and a Diameter node that accepts > a connection acts as a TLS server. Diameter nodes implementing TLS for > security MUST mutually authenticate as part of TLS session > establishment. > > In order to ensure mutual authentication, the Diameter node acting as > TLS server must request a certificate from the Diameter node acting as > TLS client, and the Diameter node acting as TLS client MUST > be prepared to supply a certificate on request. Text Added, issue closed. John From owner-aaa-wg@merit.edu Wed Feb 27 14:47:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13541 for ; Wed, 27 Feb 2002 14:47:32 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BC57A91335; Wed, 27 Feb 2002 14:45:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85FAE91332; Wed, 27 Feb 2002 14:45:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D72EC91337 for ; Wed, 27 Feb 2002 14:45:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D9575DDE0; Wed, 27 Feb 2002 14:45:02 -0500 (EST) 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 461705DD91 for ; Wed, 27 Feb 2002 14:45:01 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJiR312901 for ; Wed, 27 Feb 2002 21:44:27 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 21:45:00 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 27 Feb 2002 21:44:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Date: Wed, 27 Feb 2002 21:44:59 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF7@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 279: Base does not sufficiently explain what 'MAY encrypt means - CLOSED for BASE Thread-Index: AcG/r40hkJ3oEkYxThmA0xDq6b+07wAEt8/Q From: To: Cc: , X-OriginalArrivalTime: 27 Feb 2002 19:44:59.0930 (UTC) FILETIME=[3DCC97A0:01C1BFC7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13541 Hi Stephen, > After some off-list discussion it appears that the following > is the correct interpretation of the "MAY encr" column: > > "For the originator of a Diameter message, "MAY encr" means > that if a message containing that AVP is to be sent via a > proxy/agent then the message MUST NOT be sent unless there > is a DSA between the originator and the recipient OR the > originator has locally trusted configuration that indicates > that CMS need not be used." > > I'll put this into CMS, but would also recommend it go > somewhere in the base. I'll make this change ORIGINAL TEXT 4.6 Diameter Base Protocol AVPs The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. If an AVP MAY be encrypted, section 2.0 of the Diameter CMS security extension [CMS] defines in which situations the encryption is actually employed. NEW TEXT: 4.6 Diameter Base Protocol AVPs The following table describes the Diameter AVPs defined in the base protocol, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. For the originator of a Diameter message, "MAY Encr" means that if a message containing that AVP is to be sent via a proxy/agent then the message MUST NOT be sent unless there is a DSA between the originator and the recipient OR the originator has locally trusted configuration that indicates that CMS need not be used. John From owner-aaa-wg@merit.edu Wed Feb 27 14:55:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13999 for ; Wed, 27 Feb 2002 14:55:13 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 54EA791231; Wed, 27 Feb 2002 14:55:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1ABA291332; Wed, 27 Feb 2002 14:55:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24C5191231 for ; Wed, 27 Feb 2002 14:55:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 070BE5DDE0; Wed, 27 Feb 2002 14:55:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 765855DD91 for ; Wed, 27 Feb 2002 14:55:01 -0500 (EST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RJkxx25733 for ; Wed, 27 Feb 2002 13:46:59 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 27 Feb 2002 13:44:19 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 13:43:10 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 13:43:10 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12867@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/ru/n0Uvg4A7vRcSIr2P4OoJphAAF/jvA From: To: , , , Cc: X-OriginalArrivalTime: 27 Feb 2002 19:43:10.0499 (UTC) FILETIME=[FC92BF30:01C1BFC6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA13999 Jari Arkko [jari.arkko@kolumbus.fi] wrote: >>RE: [AAA-WG]: Request for closure on issue 235> But what about >>packets that are received out of order (D bit is received First)? > >1. D bit record is first received, and you search all records, no >match. you also search the pool, no match. you put it to a pool. > >2. non-D bit record is received after that, and you search the pool >(not all records) > >So, using the current scheme you do 2 all-records searches >total. Using the d-bit method you do 1 all-records search and 2 >pool searches. Worth it? If the pool searches are significantly faster. >(Basavaraj, you do have to make some full searches anyway!) > Yes. But it is always preferable to do these checks for duplicates on a small set of "D" marked records as opposed to checking every received record against every other record all the time. >Jari -Basavaraj From owner-aaa-wg@merit.edu Wed Feb 27 15:01:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14422 for ; Wed, 27 Feb 2002 15:01:38 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 64A4C91338; Wed, 27 Feb 2002 15:00:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35F7091339; Wed, 27 Feb 2002 15:00:30 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0DE3891338 for ; Wed, 27 Feb 2002 15:00:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id DED255DDD2; Wed, 27 Feb 2002 15:00:28 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from dzick.interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by segue.merit.edu (Postfix) with ESMTP id 95EF65DD91 for ; Wed, 27 Feb 2002 15:00:28 -0500 (EST) Received: from interlinknetworks.com (localhost.localdomain [127.0.0.1]) by dzick.interlinknetworks.com (8.11.0/8.11.0) with ESMTP id g1RJma815496; Wed, 27 Feb 2002 14:48:36 -0500 Message-ID: <3C7D3813.BE893A2@interlinknetworks.com> Date: Wed, 27 Feb 2002 14:48:35 -0500 From: Don Zick Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.2.16-22 i686) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: jacques_m_caron@yahoo.com, DSpence@interlinknetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=iso-8859-1 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ietf.org id PAA14422 Hi John, Yes, sounds perfect to me! Thanks, Don john.loughney@nokia.com wrote: > Hi Don, > > > I am not in favor of advertising a DiameterIdentity over a > > connection if the > > DiameterIdentity does not reflect settings actually used on > > the connection. > > > > I think the DiameterIdentity used to be an FQDN. There was > > concern that > > multiple Diameter nodes on a host could not be uniquely > > identified, so the > > DiameterIdentity changed to be FQDN plus port plus protocol. > > More recently, > > transport security was added to the DiameterIdentity. > > > > I'd like to consider changing DiameterIdentity back to being an FQDN. > > > > Proposed Text: > > > > A Diameter node must be uniquely identified by its > > DiameterIdentity, which is an > > FQDN. If multiple Diameter nodes run on the same host, each > > Diameter node > > MUST be assigned a unique DiameterIdentity. > > > > End Proposed Text > > > > What I have added is the following: > > DiameterIdentity > > The DiameterIdentity format is derived from the OctetString AVP Base Format. > It uses the UTF-8 encoding and has the same requirements as the UTF8String. > In addition, it must follow the Uniform Resource Identifiers (URI) syntax > [URI] rules specified below: > > DiameterIdentity = fqdn > > A Diameter node must be uniquely identified by its DiameterIdentity, which > is an FQDN. If multiple Diameter nodes run on the same host, each Diameter > node MUST be assigned a unique DiameterIdentity. > > Does this work? > > John From owner-aaa-wg@merit.edu Wed Feb 27 16:59:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21125 for ; Wed, 27 Feb 2002 16:59:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 56E6891233; Wed, 27 Feb 2002 16:58:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2AF4A9125A; Wed, 27 Feb 2002 16:58:57 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26BEF91233 for ; Wed, 27 Feb 2002 16:58:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E91E5DDDA; Wed, 27 Feb 2002 16:58:56 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id EECEC5DD91 for ; Wed, 27 Feb 2002 16:58:55 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 94D0B7B; Wed, 27 Feb 2002 16:58:55 -0500 (EST) Message-ID: <3C7D56A5.87462FE8@Interlinknetworks.com> Date: Wed, 27 Feb 2002 16:59:01 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: dzick@Interlinknetworks.com, jacques_m_caron@yahoo.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------96D2EACBB9664F08376EA5BA" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------96D2EACBB9664F08376EA5BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit One question: Does it make any difference whether there is an A record for the fqdn in the DNS, i.e., does the fqdn actually need to be registered? I think not. And if it doesn't, that makes it easier for administrators. Suppose I run two Diameter servers on srv.interlinknetworks.com. Then I could configure one to call itself diam1.srv.interlinknetworks.com, and I could configue the other to call itself diam2.srv.interlinknetworks.com. Voila! I have guaranteed uniqueness without having to register a domain name. If this is agreeable, it might be worth stating in the draft that the term fqdn does not imply that the name be registered, only that it be unique. john.loughney@nokia.com wrote: > > Hi Don, > > > I am not in favor of advertising a DiameterIdentity over a > > connection if the > > DiameterIdentity does not reflect settings actually used on > > the connection. > > > > I think the DiameterIdentity used to be an FQDN. There was > > concern that > > multiple Diameter nodes on a host could not be uniquely > > identified, so the > > DiameterIdentity changed to be FQDN plus port plus protocol. > > More recently, > > transport security was added to the DiameterIdentity. > > > > I'd like to consider changing DiameterIdentity back to being an FQDN. > > > > Proposed Text: > > > > A Diameter node must be uniquely identified by its > > DiameterIdentity, which is an > > FQDN. If multiple Diameter nodes run on the same host, each > > Diameter node > > MUST be assigned a unique DiameterIdentity. > > > > End Proposed Text > > > > What I have added is the following: > > DiameterIdentity > > The DiameterIdentity format is derived from the OctetString AVP Base Format. > It uses the UTF-8 encoding and has the same requirements as the UTF8String. > In addition, it must follow the Uniform Resource Identifiers (URI) syntax > [URI] rules specified below: > > DiameterIdentity = fqdn > > A Diameter node must be uniquely identified by its DiameterIdentity, which > is an FQDN. If multiple Diameter nodes run on the same host, each Diameter > node MUST be assigned a unique DiameterIdentity. > > Does this work? > > John --------------96D2EACBB9664F08376EA5BA Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------96D2EACBB9664F08376EA5BA-- From owner-aaa-wg@merit.edu Wed Feb 27 17:21:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22147 for ; Wed, 27 Feb 2002 17:21:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1EC5B912DC; Wed, 27 Feb 2002 17:21:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D82E0912DB; Wed, 27 Feb 2002 17:21:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5AC9912DC for ; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id BB8235DDE4; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 3FEC35DDDA for ; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at client62-2-83-195.hispeed.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@62.2.83.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 22:21:10 -0000 Message-Id: <5.1.0.14.0.20020227231609.048cb998@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 23:19:07 +0100 To: David Spence From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: john.loughney@nokia.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu In-Reply-To: <3C7D56A5.87462FE8@Interlinknetworks.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Even though the full name need not necessarily be in the DNS (though this might have other consequences?), it is necessary that it is based on a domain name that is registered and owned by the administrator of the server. Otherwise we'll end up with a bunch of "diameter.example.com" all over which are definitely not unique :-( I think it's easier if the fqdn is really registered, just for the purposes of ensuring uniqueness. Jacques. At 22:59 27/02/2002, David Spence wrote: >One question: Does it make any difference whether there is an A record for >the fqdn in the DNS, i.e., does the fqdn actually need to be registered? I >think not. And if it doesn't, that makes it easier for administrators. >Suppose I run two Diameter servers on srv.interlinknetworks.com. Then I >could configure one to call itself diam1.srv.interlinknetworks.com, and I >could configue the other to call itself diam2.srv.interlinknetworks.com. >Voila! I have guaranteed uniqueness without having to register a domain >name. If this is agreeable, it might be worth stating in the draft that the >term fqdn does not imply that the name be registered, only that it be >unique. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 17:21:52 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22158 for ; Wed, 27 Feb 2002 17:21:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 70844912DD; Wed, 27 Feb 2002 17:21:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 20DF091339; Wed, 27 Feb 2002 17:21:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB7EE912DB for ; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E3465DDE6; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 40E7C5DDE4 for ; Wed, 27 Feb 2002 17:21:15 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at client62-2-83-195.hispeed.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@62.2.83.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Feb 2002 22:21:07 -0000 Message-Id: <5.1.0.14.0.20020227231035.039e6b40@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 27 Feb 2002 23:15:59 +0100 To: From: Jacques Caron Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Cc: , , In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 20:44 27/02/2002, john.loughney@nokia.com wrote: > The DiameterIdentity format is derived from the OctetString AVP Base > Format. > It uses the UTF-8 encoding and has the same requirements as the > UTF8String. > In addition, it must follow the Uniform Resource Identifiers (URI) syntax > [URI] rules specified below: What is the URI stuff doing here? It's not a URI, just a FQDN all by itself. If you need the reference to [URI] just for the definition of "fqdn" I think it's really ambiguous. > DiameterIdentity = fqdn > > A Diameter node must be uniquely identified by its DiameterIdentity, which > is an FQDN. If multiple Diameter nodes run on the same host, each > Diameter > node MUST be assigned a unique DiameterIdentity. Also one thing I forgot to point out earlier: it would be good to state that the DiameterIdentity must be constant for the process, whatever the interface it is used on. Something like: "If a Diameter node can be identified by several FQDNs, one single FQDN should be picked at startup, and used as the only DiameterIdentity for that node, whatever the connection it is sent on." It might not be a bad idea to add a sentence to explain what it's used for, such as: "The DiameterIdentity value is used to uniquely identify a Diameter node for purposes of duplicate connection and routing loop detection". Additionally, some text all along the draft needs to be modified to reference the right AVP type (DiameterURI vs DiameterIdentity) depending on the context, of course. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 18:18:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23837 for ; Wed, 27 Feb 2002 18:18:07 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 0E59C912DE; Wed, 27 Feb 2002 18:16:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A770912DF; Wed, 27 Feb 2002 18:16:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D683912DE for ; Wed, 27 Feb 2002 18:16:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 62BE05DDCA; Wed, 27 Feb 2002 18:16:29 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 4E8175DD91 for ; Wed, 27 Feb 2002 18:16:29 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id C76A679; Wed, 27 Feb 2002 18:16:28 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: "aaa-wg" Subject: [AAA-WG]: [issue] Handling of Home-Agent-In-Foreign-Network flag Date: Wed, 27 Feb 2002 18:15:35 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue : Handling of Home-Agent-In-Foreign-Network flag Submitter name: Bob Kopacz Submitter email address: BKopacz@InterlinkNetworks.com Date first submitted: 02-27-2002 Reference: Document: draft-mobileip-08 Comment type: Technical Priority: 1 Section: Rationale/Explanation of issue: (1) It is difficult for the originating AAAF to correctly set the Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a "real" HA IP address (not all zeroes or all ones). The AAAF only sees an IP address. The AAAF doesn't know just from the HA's IP address whether that represents an HA in the home network, or an HA in another foreign network. And maybe doesn't even know if the IP address is in his own network. The AAAF would have to call upon the DNS or other external resources to make this "home-agent-is-in-a-foreign-network" determination. This introduces unnecessary delay into the call setup by duplicating work which the AAAH has to do anyway upon receiving the AMR. That is, when the AAAH receives the AMR with a specified HA IP address, the AAAH has to map this IP address into the HA's realm and HA's DiameterIdentity, which will be used as the Destination-Realm and Destination-Host of the HAR. Furthermore, the AAAH may be able to make this determination more quickly than the AAAF, as a session-stateful AAAH may well have this information at hand as part of his session state. (2) The proposal here is to make the Home-Agent-In-Foreign-Network flag one which is not set by the originating-AAAF, but is instead set by the AAAH. This information will be returned to the originating-AAAF and FA when the updated feature vector is returned in the AMA. (3) It may be that the originating AAAF wants to disallow a foreign HA, or allow a foreign HA but only if the foreign HA is in the originating AAAF's domain. If this capability is desired, then two new flags, settable by the originating AAAF, can be added to the MIP-Feature-Vector: Foreign-HA-Allowed-In-NonOriginating-Network Foreign-HA-Allowed-In-Originating-Network The AAAH, after examining the home agent's IP address and determining whether the HA resides in the originating network, home network, or some other foreign network, can examine the two new flags to enforce the originating AAAF's policy on foreign HAs. This way, the originating AAAF maintains the ability to place retrictions on foreign HAs before the call is authorized. (4) If (3) above is considered something an originating AAAF wouldn't care about, then these two new flags can be removed from the proposal. Requested change: In section 1.2 Inter-Realm Mobile IP Replace: If the Mobile Node was successfully authenticated, the AAAH checks if the Home Agent was located in the foreign realm, by checking the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. If the flag is enabled, then the Home Agent is located in the foreign realm then AAAH sends an HAR message to AAAF which contains a MIP- Reg-Request AVP. With: If the Mobile Node was successfully authenticated, the AAAH checks if the Home Agent is located in a foreign realm. If so, the AAAH sets the Home-Agent-In-Foreign-Network flag of the MIP-Feature-Vector AVP. Only the AAAH may set the Home-Agent-In-Foreign-Network flag. If the Home Agent is located in a foreign realm other than the originating realm, and the Foreign-HA-Allowed-In-NonOriginating-Network flag is zero, then the AAAH will return an AMA with a Result-Code of DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. If the Home Agent is located in the originating foreign realm, and the Foreign-HA-Allowed-In-Originating-Network flag is zero, then the AAAH will return an AMA with a Result-Code of DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE. Otherwise, if the Home Agent is in a foreign network, and this is allowed by both the originating AAAF and the AAAH, then the AAAH sends an HAR message to foreign HA which contains a MIP-Reg-Request AVP. - - - In section 1.4 Allocation of Home Agent in Foreign Network Remove this paragraph: In the event that the mobile node requests a home agent in the foreign network, and the AAAF authorizes its use, the AAAF MUST set the Home-Agent-In-Foreign-Network bit in the MIP-Feature-Vector AVP. This could happen when the AAA request is sent to "extend" a mobile node's current session. - - - In section 4.5 MIP-Feature-Vector AVP Replace: The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and is added with flag values set by the Foreign Agent or by the AAAF owned by the same administrative domain as the Foreign Agent. The Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR message it sends to the AAAF. With: The MIP-Feature-Vector AVP (AVP Code 337) is of type Unsigned32 and conveys flag values set by the Foreign Agent, the AAAF owned by the same administrative domain as the Foreign Agent, and the AAAH. The flags in the MIP-Feature-Vector are updated as the AMR makes it way to the AAAH, and the updated MIP-Feature-Vector is returned in the AMA. The Foreign Agent SHOULD include MIP-Feature-Vector AVP within the AMR message it sends to the AAAF. - - - In section 4.5 MIP-Feature-Vector AVP To this list of flags: Flag values currently defined include: 1 Mobile-Node-Home-Address-Requested 2 Home-Address-Allocatable-Only-in-Home-Realm 4 Home-Agent-Requested 8 Foreign-Home-Agent-Available 16 MN-HA-Key-Request 32 MN-FA-Key-Request 64 FA-HA-Key-Request 128 Home-Agent-In-Foreign-Network 256 Co-Located-Mobile-Node Add: 512 Foreign-HA-Allowed-In-NonOriginating-Network 1024 Foreign-HA-Allowed-In-Originating-Network - - - In section 4.5 MIP-Feature-Vector AVP Replace: If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign- Network bit to one. The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available, and Home-Agent-In-Foreign-Network flag to one. When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized Foreign Agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags.Only the AAAF may set the Foreign-Home-Agent-Available and Home-Agent-In-Foreign-Network flags to one. This is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, then the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH. With: If the mobile node requests a home agent in the foreign network either by setting the home address field to all ones, or by specifying a home agent in the foreign network, and the AAAF authorizes the request, the AAAF may restrict the HA to certain networks by setting the Foreign-HA-Allowed-In-NonOriginating-Network and/or the Foreign-HA-Allowed-In-Originating-Network flag. The Foreign Agent MUST NOT set the Foreign-Home-Agent-Available to one and the Foreign-HA-Allowed-In-Originating-Network flag to zero. When the AAAF receives the AMR message, it MUST first verify that the sender was an authorized Foreign Agent. The AAAF then takes any actions indicated by the settings of the MIP-Feature-Vector AVP flags. The AAAF then MAY set additional flags. Only the AAAF may set the Foreign-Home-Agent-Available, Foreign-HA-Allowed-In-Originating- Network, and Foreign-HA-Allowed-In-NonOriginating-Network flags to one. This is done according to local administrative policy. When the AAAF has finished setting additional flags according to its local policy, then the AAAF transmits the AMR with the possibly modified MIP-Feature-Vector AVP to the AAAH. - - - From owner-aaa-wg@merit.edu Wed Feb 27 18:42:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24560 for ; Wed, 27 Feb 2002 18:42:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 81CCD91209; Wed, 27 Feb 2002 18:42:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59E0891234; Wed, 27 Feb 2002 18:42:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59B4191209 for ; Wed, 27 Feb 2002 18:42:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3B3085DDE5; Wed, 27 Feb 2002 18:42:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by segue.merit.edu (Postfix) with ESMTP id 7110F5DD91 for ; Wed, 27 Feb 2002 18:42:17 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g1RNgGq01714 for aaa-wg@merit.edu; Wed, 27 Feb 2002 18:42:16 -0500 (EST) (envelope-from barney) Date: Wed, 27 Feb 2002 18:42:16 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 Message-ID: <20020227184216.B678@tp.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@bstormnetworks.com on Wed, Feb 27, 2002 at 07:15:43AM -0800 Sender: owner-aaa-wg@merit.edu Precedence: bulk I did not mean to imply that User-Name was the only key. But records will certainly be accumulated for a given user, whether because that's how they are billed or for the bill detail. So that sort (or index) is already being done. Given that, the universe of records that must be checked for duplication is really quite small, which is why I don't believe the D-bit actually saves anything noticeable. Do people believe generating the D-bit reliably is a trivial burden on the sender? If so then it does no harm, because the receiver can always ignore it. But I don't think it's that trivial. As a receiver I'd be very wary of depending on the sender to trigger the dup check. Barney On Wed, Feb 27, 2002 at 07:15:43AM -0800, Pat R. Calhoun wrote: > > > > My problem with the D-bit is that it invites doing something in > > real time that does not need to be done in real time, and puts a > > burden on the sender while saving very little if anything for the > > receiver. The biller is going to sort the records anyway, and > > finding adjacent > > duplicates is trivial with or without the D-bit. > > > > Barney Wolff > > But there are cases when billing actually takes place in real time, > called prepaid charging. So the usage of the D-bit would make a > significant performance improvement for the receiver in these cases. > > I seriously don't understand the insistence on using User-Name > for the lookup. Not only is there a Session-Id, which is unique, but > there is also an accounting record number. Those two items are > guaranteed to be unique, and therefore are a great way of checking > for dups. I don't understand the mechanism by which records are put > in a "temporary" buffer, as opposed on written on disk. You need to > write ALL records in this "temporary" buffer (if it even exists) in > order to check for duplicates. > > What really confuses me here is how the checks are done. Using a > single bit 'D' isn't really useful for a lookup. Some additional data > is required, and whether the 'D' bit is set or not, the message must > be cached for duplicate check (to handle out of order packets). > > Confused, > > PatC From owner-aaa-wg@merit.edu Wed Feb 27 18:42:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24573 for ; Wed, 27 Feb 2002 18:42:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9886912E1; Wed, 27 Feb 2002 18:42:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 740C3912E0; Wed, 27 Feb 2002 18:42:38 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8D77A91234 for ; Wed, 27 Feb 2002 18:42:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E9335DDE5; Wed, 27 Feb 2002 18:42:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 580F15DD91 for ; Wed, 27 Feb 2002 18:42:35 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 1B1B479; Wed, 27 Feb 2002 18:42:35 -0500 (EST) From: "Bob Kopacz" To: Cc: "aaa-wg" Subject: [AAA-WG]: RE: [issue] Minor corrections to draft-base-08 Date: Wed, 27 Feb 2002 18:41:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF5@esebe004.NOE.Nokia.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi John, > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, February 27, 2002 2:45 PM > To: BKopacz@interlinknetworks.com > Cc: aaa-wg@merit.edu > Subject: RE: [issue] Minor corrections to draft-base-08 > > > Hi Bob, > > > Oh, sure. Even something shorter, "aaa://host.abc.com", > > is plenty good for the example. > > Due the changes in the DiameterIdentity, the above is no > longer valid. Oops, sorry. I hadn't been keeping up with the DiameterIdentity du jour. Bob K. > > John > From owner-aaa-wg@merit.edu Wed Feb 27 18:56:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24884 for ; Wed, 27 Feb 2002 18:56:10 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D09DC91234; Wed, 27 Feb 2002 18:56:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A09C7912DF; Wed, 27 Feb 2002 18:56:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C6F991234 for ; Wed, 27 Feb 2002 18:55:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6915A5DDE5; Wed, 27 Feb 2002 18:55:59 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id B8EF25DD91 for ; Wed, 27 Feb 2002 18:55:58 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1RNu6Z18511 for ; Thu, 28 Feb 2002 01:56:06 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 01:55:57 +0200 Received: from daebh001.NOE.Nokia.com ([172.18.242.231]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 01:55:57 +0200 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 27 Feb 2002 17:55:52 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 27 Feb 2002 17:55:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12875@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/6HMT5yCJnikOSPmkVpjQ1G1JVQAAcvew From: To: , X-OriginalArrivalTime: 27 Feb 2002 23:55:52.0564 (UTC) FILETIME=[49DE4340:01C1BFEA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA24884 Barney Wolff [barney@databus.com] wrote: >Do people believe generating the D-bit reliably is a trivial burden on >the sender? If so then it does no harm, because the receiver can >always ignore it. But I don't think it's that trivial. Why not? I am not sure I understand what complexity you see. It is some implementation effort, no doubt, but is not extremely complex. >As a receiver >I'd be very wary of depending on the sender to trigger the dup check. > If the senders are required to mark the "D" bit if they are potential duplicates, the receiver could rely on the sender to trigger the duplicate checks. So I believe it is a matter of specification and compliance to specification w.r.t the behavior of the sender. >Barney -Basavaraj From owner-aaa-wg@merit.edu Wed Feb 27 19:08:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25141 for ; Wed, 27 Feb 2002 19:08:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 103A4912DF; Wed, 27 Feb 2002 19:08:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5CB0912E0; Wed, 27 Feb 2002 19:08:39 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E25E9912DF for ; Wed, 27 Feb 2002 19:08:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id C76105DD91; Wed, 27 Feb 2002 19:08:38 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A19CD5DDE7 for ; Wed, 27 Feb 2002 19:08:38 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5F6C479; Wed, 27 Feb 2002 19:08:38 -0500 (EST) Message-ID: <3C7D750B.7778F166@Interlinknetworks.com> Date: Wed, 27 Feb 2002 19:08:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jacques Caron Cc: john.loughney@nokia.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <5.1.0.14.0.20020227231035.039e6b40@pop.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------ED65046BEA106040703AE0E8" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------ED65046BEA106040703AE0E8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jacques Caron wrote: >... > Additionally, some text all along the draft needs to be modified to > reference the right AVP type (DiameterURI vs DiameterIdentity) depending on > the context, of course. >... You know, I had thought that all AVPs were of type DiameterIdentity with the Diameter URI only used in config files and other resource location protocols. But now that I think about it, the Redirect-Host AVP is an exception. The recipient of an answer message containing a Redirect-Host AVP is expected to form a peer-to-peer connection with the redirect host. So the full URI information is needed. Therefore we really *do* need to define two different AVP types -- DiameterURI and DiameterIdentity. The Redirect-Host AVP is of type DiameterURI. Are all the other AVPs of type DiameterIdentity? --------------ED65046BEA106040703AE0E8 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------ED65046BEA106040703AE0E8-- From owner-aaa-wg@merit.edu Wed Feb 27 19:13:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25334 for ; Wed, 27 Feb 2002 19:13:08 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 55358912E0; Wed, 27 Feb 2002 19:12:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26AED9133A; Wed, 27 Feb 2002 19:12:48 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31466912E0 for ; Wed, 27 Feb 2002 19:12:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 11DE35DDE7; Wed, 27 Feb 2002 19:12:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id F21525DD91 for ; Wed, 27 Feb 2002 19:12:46 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A47E879; Wed, 27 Feb 2002 19:12:46 -0500 (EST) Message-ID: <3C7D7604.2946B53D@Interlinknetworks.com> Date: Wed, 27 Feb 2002 19:12:52 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jacques Caron Cc: john.loughney@nokia.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> <5.1.0.14.0.20020227231609.048cb998@pop.mail.yahoo.com> Content-Type: multipart/mixed; boundary="------------2A0B425FE75185335812A618" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------2A0B425FE75185335812A618 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Actually, my idea was that the portion of the identity string following the first dot would be a real host name registered to the host on which the server was running. In my example below, both servers were running on srv.interlinknetworks.com, which is the real name of the host. diam1 and diam2 would be unregistered prefixes to a registered host name. Jacques Caron wrote: > > Even though the full name need not necessarily be in the DNS (though this > might have other consequences?), it is necessary that it is based on a > domain name that is registered and owned by the administrator of the > server. Otherwise we'll end up with a bunch of "diameter.example.com" all > over which are definitely not unique :-( > > I think it's easier if the fqdn is really registered, just for the purposes > of ensuring uniqueness. > > Jacques. > > At 22:59 27/02/2002, David Spence wrote: > >One question: Does it make any difference whether there is an A record for > >the fqdn in the DNS, i.e., does the fqdn actually need to be registered? I > >think not. And if it doesn't, that makes it easier for administrators. > >Suppose I run two Diameter servers on srv.interlinknetworks.com. Then I > >could configure one to call itself diam1.srv.interlinknetworks.com, and I > >could configue the other to call itself diam2.srv.interlinknetworks.com. > >Voila! I have guaranteed uniqueness without having to register a domain > >name. If this is agreeable, it might be worth stating in the draft that the > >term fqdn does not imply that the name be registered, only that it be > >unique. > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com --------------2A0B425FE75185335812A618 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------2A0B425FE75185335812A618-- From owner-aaa-wg@merit.edu Wed Feb 27 19:18:24 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25545 for ; Wed, 27 Feb 2002 19:18:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8D8D69122D; Wed, 27 Feb 2002 19:17:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38F979133A; Wed, 27 Feb 2002 19:17:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6051E9122D for ; Wed, 27 Feb 2002 19:17:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3092C5DDE7; Wed, 27 Feb 2002 19:17:06 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from EXCHSRV.stormventures.com (unknown [65.107.25.226]) by segue.merit.edu (Postfix) with ESMTP id DD7695DD91 for ; Wed, 27 Feb 2002 19:17:05 -0500 (EST) Received: by EXCHSRV.stormventures.com with Internet Mail Service (5.5.2653.19) id <1QP7SDZP>; Wed, 27 Feb 2002 16:17:05 -0800 Message-ID: From: "Pat R. Calhoun" To: "'Barney Wolff'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Request for closure on issue 235 Date: Wed, 27 Feb 2002 16:17:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BFED.3FE4ACF0" Sender: owner-aaa-wg@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1BFED.3FE4ACF0 Content-Type: text/plain -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Do people believe generating the D-bit reliably is a trivial burden > on the sender? If so then it does no harm, because the receiver > can always ignore it. But I don't think it's that trivial. As a > receiver I'd be very wary of depending on the sender to trigger > the dup check. Check, and if receivers aren't likely to trust the sender to inform it of a duplicate, does having this in the protocol even make sense? PatC -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPH13ADN1fXKoxmisEQLozQCgpru92LM5FoMaYpIXPfzyTJ5/EaIAnA0U 9U1WdhUXcZJn8S5YJyw060wq =e2BW -----END PGP SIGNATURE----- ------_=_NextPart_001_01C1BFED.3FE4ACF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Do people believe generating the D-bit reliably = is a trivial burden
> on the sender?  If  so then it does = no harm, because the receiver
> can always ignore it.  But I don't = think  it's that trivial.  As a
> receiver I'd be very wary of depending on the = sender to trigger
> the dup check.

Check, and if receivers aren't likely to trust the = sender to inform
it of a duplicate, does having this in the protocol = even make sense?

PatC

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use = <http://www.pgp.com>

iQA/AwUBPH13ADN1fXKoxmisEQLozQCgpru92LM5FoMaYpIXPfzyTJ5/EaIAnA0= U
9U1WdhUXcZJn8S5YJyw060wq
=3De2BW
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C1BFED.3FE4ACF0-- From owner-aaa-wg@merit.edu Wed Feb 27 19:33:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25924 for ; Wed, 27 Feb 2002 19:33:12 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 989179133B; Wed, 27 Feb 2002 19:32:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 579CA9133A; Wed, 27 Feb 2002 19:32:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CD309133B for ; Wed, 27 Feb 2002 19:32:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 523F35DDE7; Wed, 27 Feb 2002 19:32:31 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 3C7A55DD91 for ; Wed, 27 Feb 2002 19:32:31 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 028DB79; Wed, 27 Feb 2002 19:32:30 -0500 (EST) Message-ID: <3C7D7AA4.B2EB1DF0@Interlinknetworks.com> Date: Wed, 27 Feb 2002 19:32:36 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue about User-Name AVP and accounting References: <3C6699AE.3020300@kolumbus.fi> Content-Type: multipart/mixed; boundary="------------0069A22F4C190532214BEED6" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------0069A22F4C190532214BEED6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This issue is mis-stated. The section 10.2 that is in error is sec. 10.2 of the base -- not nasreq. Jari Arkko wrote: > > Submitter name: Jari Arkko (Sebastian Zander) > Submitter email address: jari@arkko.com > Date first submitted: Feb 10, 2002 > Reference: http://www.merit.edu/mail.archives/aaa-wg/msg03001.html > Document: base, nasreq > Comment type: E > Priority: 2 > Section: 9.5, 9.7.1, 9.7.2, nasreq 10.2 > Rationale/Explanation of issue: > > Section 9.5 of base-08 reads: "In all accounting records the > Session-Id and User-Name AVPs MUST be present.". However, the Diameter node > sending the accounting request may not know it. Still the target can use the various > session-ID AVPs to correlate the records. There also seems to be some inconsistency > in the draft and between base-08 and nasreq-08: In section 9.7.1 & 9.7.2 > (ACR, ACA definition) User-Name AVP is marked as optional while in > section 10.2 it is again specified as MUST. > > Proposed change: > > I suggest modifying 9.5 so that it reads. "User-Name AVP MUST be present if > it is available to the Diameter client." > > Then change the tables in 10.2 as follows: > > User-Name | 0+ | 0+ | --------------0069A22F4C190532214BEED6 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------0069A22F4C190532214BEED6-- From owner-aaa-wg@merit.edu Wed Feb 27 19:56:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26407 for ; Wed, 27 Feb 2002 19:56:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F2AC79125B; Wed, 27 Feb 2002 19:56:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C26ED9133A; Wed, 27 Feb 2002 19:56:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B449A9125B for ; Wed, 27 Feb 2002 19:56:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8EB675DDE9; Wed, 27 Feb 2002 19:56:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id 1599D5DD91 for ; Wed, 27 Feb 2002 19:56:10 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at client62-2-83-195.hispeed.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@62.2.83.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Feb 2002 00:56:08 -0000 Message-Id: <5.1.0.14.0.20020228012845.03a3df70@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 01:51:15 +0100 To: David Spence From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: john.loughney@nokia.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu In-Reply-To: <3C7D750B.7778F166@Interlinknetworks.com> References: <5.1.0.14.0.20020227231035.039e6b40@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Right. Anything that "points to" a Diameter node is an URI. Anything that identifies a node is Identity. Redirect-Host should be an URI, and actually be renamed Redirect-URI for consistency. Route-Record, Origin-Host, Destination-Host and Proxy-Host should be identities. Apparently Alternate-Host and Source-Route are no longer with us, but if they come back, the first one is an URI and the second an Identity. Jacques. At 01:08 28/02/2002, David Spence wrote: >Jacques Caron wrote: > >... > > Additionally, some text all along the draft needs to be modified to > > reference the right AVP type (DiameterURI vs DiameterIdentity) depending on > > the context, of course. > >... > >You know, I had thought that all AVPs were of type DiameterIdentity with the >Diameter URI only used in config files and other resource location >protocols. But now that I think about it, the Redirect-Host AVP is an >exception. The recipient of an answer message containing a Redirect-Host >AVP is expected to form a peer-to-peer connection with the redirect host. >So the full URI information is needed. Therefore we really *do* need to >define two different AVP types -- DiameterURI and DiameterIdentity. The >Redirect-Host AVP is of type DiameterURI. Are all the other AVPs of type >DiameterIdentity? _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 19:56:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26444 for ; Wed, 27 Feb 2002 19:56:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 470489133C; Wed, 27 Feb 2002 19:56:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E36C9133A; Wed, 27 Feb 2002 19:56:13 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29A679133C for ; Wed, 27 Feb 2002 19:56:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0657C5DDE9; Wed, 27 Feb 2002 19:56:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id B0DB45DD91 for ; Wed, 27 Feb 2002 19:56:11 -0500 (EST) Received: from jacques?m?caron (AUTH LOGIN) at client62-2-83-195.hispeed.ch (HELO ETCL001.yahoo.com) (jacques?m?caron@62.2.83.195) by smtp.mail.vip.sc5.yahoo.com with SMTP; 28 Feb 2002 00:56:10 -0000 Message-Id: <5.1.0.14.0.20020228015128.0491c008@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 28 Feb 2002 01:55:37 +0100 To: David Spence From: Jacques Caron Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded Cc: john.loughney@nokia.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu In-Reply-To: <3C7D7604.2946B53D@Interlinknetworks.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AF4@esebe004.NOE.Nokia.com> <5.1.0.14.0.20020227231609.048cb998@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Then you're really adding something to the "real" FQDN that is functionally equivalent to a port number :-) If you manage to write some text that explains that clearly and unambiguously, why not. But I think it's easier to stick to "real" FQDNs. It's never hurt anyone to register a couple of addresses in the DNS. As an alternative, if the Identity is considered fully opaque, nothing prevents us to change it to FQDN;. Where may be a PID, a port number, a configuration file path name, or any other arbitrary string. Jacques. At 01:12 28/02/2002, David Spence wrote: >Actually, my idea was that the portion of the identity string following the >first dot would be a real host name registered to the host on which the >server was running. In my example below, both servers were running on >srv.interlinknetworks.com, which is the real name of the host. diam1 and >diam2 would be unregistered prefixes to a registered host name. > >Jacques Caron wrote: > > > > Even though the full name need not necessarily be in the DNS (though this > > might have other consequences?), it is necessary that it is based on a > > domain name that is registered and owned by the administrator of the > > server. Otherwise we'll end up with a bunch of "diameter.example.com" all > > over which are definitely not unique :-( > > > > I think it's easier if the fqdn is really registered, just for the purposes > > of ensuring uniqueness. > > > > Jacques. > > > > At 22:59 27/02/2002, David Spence wrote: > > >One question: Does it make any difference whether there is an A record for > > >the fqdn in the DNS, i.e., does the fqdn actually need to be > registered? I > > >think not. And if it doesn't, that makes it easier for administrators. > > >Suppose I run two Diameter servers on srv.interlinknetworks.com. Then I > > >could configure one to call itself diam1.srv.interlinknetworks.com, and I > > >could configue the other to call itself diam2.srv.interlinknetworks.com. > > >Voila! I have guaranteed uniqueness without having to register a domain > > >name. If this is agreeable, it might be worth stating in the draft > that the > > >term fqdn does not imply that the name be registered, only that it be > > >unique. > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Feb 27 20:53:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28065 for ; Wed, 27 Feb 2002 20:53:29 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 00A12912E2; Wed, 27 Feb 2002 20:53:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA4D89133A; Wed, 27 Feb 2002 20:53:11 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D0D1C912E2 for ; Wed, 27 Feb 2002 20:53:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE09A5DDF2; Wed, 27 Feb 2002 20:53:10 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by segue.merit.edu (Postfix) with ESMTP id 07D365DD91 for ; Wed, 27 Feb 2002 20:53:09 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g1S1r9u02482 for aaa-wg@merit.edu; Wed, 27 Feb 2002 20:53:09 -0500 (EST) (envelope-from barney) Date: Wed, 27 Feb 2002 20:53:09 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 Message-ID: <20020227205309.B2240@tp.databus.com> References: <697DAA22C5004B4596E033803A7CEF44A12875@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12875@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Wed, Feb 27, 2002 at 05:55:52PM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Consider gateways from RADIUS or other AAA protocols. Consider a rebooting NAS - is it sure what it might have sent before it crashed? As a sender, what's my liability because you as receiver double charged or locked out some customer because I failed to set the D-bit and you relied on my perfection? Guess what - if it's not $0.00 I'm going to set the D-bit on *every* record. Barney On Wed, Feb 27, 2002 at 05:55:52PM -0600, Basavaraj.Patil@nokia.com wrote: > > Barney Wolff [barney@databus.com] wrote: > > >Do people believe generating the D-bit reliably is a trivial burden on > >the sender? If so then it does no harm, because the receiver can > >always ignore it. But I don't think it's that trivial. > > Why not? I am not sure I understand what complexity you see. It is > some implementation effort, no doubt, but is not extremely complex. > > >As a receiver > >I'd be very wary of depending on the sender to trigger the dup check. > > > > If the senders are required to mark the "D" bit if they are potential > duplicates, the receiver could rely on the sender to trigger the > duplicate checks. So I believe it is a matter of specification and > compliance to specification w.r.t the behavior of the sender. From owner-aaa-wg@merit.edu Wed Feb 27 23:13:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02993 for ; Wed, 27 Feb 2002 23:13:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2D05E91236; Wed, 27 Feb 2002 23:13:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 030449133A; Wed, 27 Feb 2002 23:13:18 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D07F091236 for ; Wed, 27 Feb 2002 23:13:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE6175DDD8; Wed, 27 Feb 2002 23:13:17 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 7C2635DDC6 for ; Wed, 27 Feb 2002 23:13:17 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1S4D7S10885; Wed, 27 Feb 2002 22:13:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1S4D6D29512; Wed, 27 Feb 2002 22:13:06 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id WAA28901; Wed, 27 Feb 2002 22:13:06 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id WAA28058; Wed, 27 Feb 2002 22:13:04 -0600 (CST) Message-ID: <3C7DADBE.7A30F93D@ericsson.com> Date: Wed, 27 Feb 2002 20:10:39 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: [issue] Handling of Accounting-Multi-Session-Id AVP (draft-mobileip-08) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, I agree on this change and would like to adopt it. Any comments / objections. Regards, /Tony Bob Kopacz wrote: > Issue : Handling of Accounting-Multi-Session-Id AVP > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: 02-27-2002 > Reference: > Document: draft-mobileip-08 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > Changes to generation & handling of the Accounting-Multi-Session-Id AVP. > > The following lines prefixed with "*" are extracted from > draft-mobileip-08. The lines are numbered to make them referencable > in the discussion. > > *01 1.2 Inter-Realm Mobile IP > *02 > *03 [...] > *04 > *05 For new sessions, the AAAH MUST create an accounting session > *06 identifier, which is added to the Accounting-Multi-Session-Id AVP in > *07 the HAR message sent to the home agent. > *08 > *09 During the creation of the HAR, the AAAH MUST use a different session > *10 identifier than the one used in the AMR/AMA (see figure 2). Of > *11 course, an AAAH MUST use the same session identifier for all HARs > *12 initiated on behalf of a given mobile node's session. [...] > *13 > > (1) According to the Introduction, an AAAH may be session-stateless. I > don't think a session-stateless AAAH can differentiate a new session > from a handoff of an existing session. Therefore a session-stateless > AAAH couldn't send the same session-id for handoffs, as stated in > line *11. > > *14 [...] > *15 > *16 Upon receipt of the HAR, the Home Agent first processes the Diameter > *17 message. [...] The Accounting-Multi-Session-Id AVP in > *18 the HAR MUST be included in the HAA, which is then forwarded to the > *19 AAAH. > *20 > > (2) The last sentence is not quite right. While the HA does send an > Accounting-Multi-Session-Id AVP in the HAA, it may be a different one > than was received in the HAR. (see lines *44-*46). > > *25 1.3 Support for Mobile IP Handoffs > *26 > *27 [...] > *28 > *29 Since the new AAAH in the home network MAY not have access to the > *30 session identifier that was used by the old AAAH, it is necessary for > *31 the resulting HAR received by the HA to be identified as a > *32 continuation of an existing session. If the HA receives an HAR for a > *33 mobile node, with a new session identifier, and the HA can guarantee > *34 that this request is to extend service for an existing service, then > *35 the HA MUST be able to modify its internal session state information > *36 to reflect the new AAAH and session identifier. The HA MUST also > *37 issue an STR message with the old session identifier to the AAAH it > *38 was communicating with when using the old session identifier. > *39 > *40 It is necessary for accounting records to have some commonality > *41 across handoffs in order for correlation to occur. Therefore, in the > *42 event that a home agent receives an HAR with a different Accounting- > *43 Multi-Session-id AVP (and obviously a different Session-Id AVP), the > *44 home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP > *45 that was received by the AAAH in the first HAR for the mobile's > *46 session. This modified Accounting-Multi-Session-Id AVP will be > *47 returned to the foreign agent by the AAAH in the AMA. Both the > *48 foreign and home agents MUST include the Accounting-Multi-Session-Id > *49 in the accounting messages. > *50 > > (3) Since the AAAH must be prepared to have the AAAH-generated > Accounting-Multi-Session-Id overridden by the HA, the protocol should > change to just have the HA always specify the > Accounting-Multi-Session-Id. > > The thinking is that the HA is constant over the MN's session, while the > AAAHs and AAAFs and FAs change. So the HA is in a position to specify a > constant Accounting-Multi-Session-Id, eliminating the extra > complications of a switcheroo. > > The proposal is that the AAAH will not send a > Accounting-Multi-Session-Id in the HAR. The HA MUST send a > Accounting-Multi-Session-Id in the HAA. All of the messages for a > MN's session will have the same value for the > Accounting-Multi-Session-Id AVP. > > (4) Since the AAAH may be session-stateless, the HA would send the STR > to the AAAH, as indicated in lines *36-*38, if and only if the AAAH > has changed. > > Requested change: > > In Section 1.2 Inter-Realm Mobile IP > > Replace: > > "For new sessions, the AAAH MUST create an accounting session > identifier, which is added to the Accounting-Multi-Session-Id AVP in > the HAR message sent to the home agent. > > "During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA (see figure 2). Of > course, an AAAH MUST use the same session identifier for all HARs > initiated on behalf of a given mobile node's session. [...] > > With: > > "During the creation of the HAR, the AAAH MUST use a different session > identifier than the one used in the AMR/AMA. > > "If the AAAH is session-stateful, it should send the same session > identifier for all HARs initiated on behalf of a given mobile node's > session. > > "If the AAAH is not session-stateful, it will manufacture a unique > session-id for every HAR. (Note--This will not cause a problem for > the HA, who must be able to recognize a handoff even if the AAAH > thinks the session is new; an AAAH may incorrectly view a session as > new when the handoff AMR goes to a different AAAH than the previous > AMR). > > - - - - > > In Section 1.2 Inter-Realm Mobile IP > > Replace the last sentence of the following paragraph: > > Upon receipt of the HAR, the Home Agent first processes the Diameter > message. [...] The Accounting-Multi-Session-Id AVP in > the HAR MUST be included in the HAA, which is then forwarded to the > AAAH. > > With: > > The HA MUST include an Accounting-Multi-Session-Id AVP in the HAA > returned to the AAAH. > > - - - - > > In section 1.3 Support for Mobile IP Handoffs > > Replace: > > Since the new AAAH in the home network MAY not have access to the > session identifier that was used by the old AAAH, it is necessary for > the resulting HAR received by the HA to be identified as a > continuation of an existing session. If the HA receives an HAR for a > mobile node, with a new session identifier, and the HA can guarantee > that this request is to extend service for an existing service, then > the HA MUST be able to modify its internal session state information > to reflect the new AAAH and session identifier. The HA MUST also > issue an STR message with the old session identifier to the AAAH it > was communicating with when using the old session identifier. > > It is necessary for accounting records to have some commonality > across handoffs in order for correlation to occur. Therefore, in the > event that a home agent receives an HAR with a different Accounting- > Multi-Session-id AVP (and obviously a different Session-Id AVP), the > home agent MUST send an HAA with the Accounting-Multi-Session-Id AVP > that was received by the AAAH in the first HAR for the mobile's > session. This modified Accounting-Multi-Session-Id AVP will be > returned to the foreign agent by the AAAH in the AMA. Both the > foreign and home agents MUST include the Accounting-Multi-Session-Id > in the accounting messages. > > With: > > "Since the new AAAH in the home network MAY not have access to the > session identifier that was used by the old AAAH, or since the AAAH > may be session-stateless, it is necessary for the resulting HAR > received by the HA to be identified as a continuation of an existing > session. > > "If the HA receives an HAR for a mobile node, with a new session > identifier, and the HA can guarantee that this request is to extend > service for an existing service, then the HA MUST be able to modify > its internal session state information to reflect the (possibly) new > AAAH and new session identifier. > > "If the AAAH is new, the HA MUST also issue an STR message with the old > session identifier to the AAAH it was communicating with when using > the old session identifier. > > "It is necessary for accounting records to have some commonality across > handoffs in order for correlation to occur. Therefore, the home agent > MUST send the same Accounting-Multi-Session-Id AVP value in all HAAs for > the mobile's session. That is, the HA generates a unique > Accounting-Multi-Session-Id when receiving an HAR for a new session, and > returns this same value in every HAA for the session. > > "This Accounting-Multi-Session-Id AVP will be returned to the foreign > agent by the AAAH in the AMA. Both the foreign and home agents MUST > include the Accounting-Multi-Session-Id in the accounting messages." > > - - - - > > In Section 1.5 "Co-located Mobile Node" > > Add the following sentence: > > "The HA includes the Accounting-Multi-Session-Id AVP in the AMR sent to > the AAAH, as the AAAH may find this a useful piece of session-state or > log entry information." > > - - - - > > In section 2.3 Home-Agent-MIP-Request > > Remove { Accounting-Multi-Session-Id } from the message ABNF. > > - - - - > > In section 2.4 Home-Agent-MIP-Answer > > Change [ Accounting-Multi-Session-Id ] to { Accounting-Multi-Session-Id } > in the message ABNF. > > - - - - > > In section 8.1 Mobile IP Command AVP Table, > > Add an entry for the Accounting-Multi-Session-Id AVP. > > Attribute Name | AMR | AMA | HAR | HAA | > ------------------------------|-----+-----+-----+-----+ > Accounting-Multi-Session-Id | 0-1 | 1 | 0 | 1 | > > - - - - > > In section 8.2 Accounting AVP Table > Add an entry for the Accounting-Multi-Session-Id AVP. > > Attribute Name | ACR | ACA | > ------------------------------|-----+-----+ > Accounting-Multi-Session-Id | 1 | 0-1 | From owner-aaa-wg@merit.edu Thu Feb 28 00:50:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04655 for ; Thu, 28 Feb 2002 00:50:15 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C1559121E; Thu, 28 Feb 2002 00:49:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B4159133A; Thu, 28 Feb 2002 00:49:55 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8BFF9121E for ; Thu, 28 Feb 2002 00:49:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id C409F5DE09; Thu, 28 Feb 2002 00:49:53 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by segue.merit.edu (Postfix) with ESMTP id 5734B5DE02 for ; Thu, 28 Feb 2002 00:49:53 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1S5nqS23691; Wed, 27 Feb 2002 23:49:52 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g1S5nqj28747; Wed, 27 Feb 2002 23:49:52 -0600 (CST) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id XAA06734; Wed, 27 Feb 2002 23:49:52 -0600 (CST) Received: from ericsson.com (racomin-101.exu.ericsson.se [138.85.130.101]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id XAA29312; Wed, 27 Feb 2002 23:49:50 -0600 (CST) Message-ID: <3C7DC46E.61EEAA3E@ericsson.com> Date: Wed, 27 Feb 2002 21:47:26 -0800 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bob Kopacz Cc: aaa-wg Subject: [AAA-WG]: Re: [issue] Handling of Home-Agent-In-Foreign-Network flag References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Bob, please find comments embedded.. /Tony Bob Kopacz wrote: > Issue : Handling of Home-Agent-In-Foreign-Network flag > Submitter name: Bob Kopacz > Submitter email address: BKopacz@InterlinkNetworks.com > Date first submitted: 02-27-2002 > Reference: > Document: draft-mobileip-08 > Comment type: Technical > Priority: 1 > Section: > > Rationale/Explanation of issue: > > (1) It is difficult for the originating AAAF to correctly set the > Home-Agent-In-Foreign-Network flag. That is, suppose the MN sends a > "real" HA IP address (not all zeroes or all ones). The AAAF only sees > an IP address. The AAAF doesn't know just from the HA's IP address > whether that represents an HA in the home network, or an HA in another > foreign network. And maybe doesn't even know if the IP address is in > his own network. > > > The AAAF would have to call upon the DNS or other external resources > to make this "home-agent-is-in-a-foreign-network" determination. This > introduces unnecessary delay into the call setup by duplicating work > which the AAAH has to do anyway upon receiving the AMR. I don't really see why it should be so difficult for the AAAF to find out the domain of the HA. > > That is, when > the AAAH receives the AMR with a specified HA IP address, the AAAH has > to map this IP address into the HA's realm and HA's DiameterIdentity, > which will be used as the Destination-Realm and Destination-Host of > the HAR. Furthermore, the AAAH may be able to make this determination > more quickly than the AAAF, as a session-stateful AAAH may well have > this information at hand as part of his session state. > > (2) The proposal here is to make the Home-Agent-In-Foreign-Network flag > one which is not set by the originating-AAAF, but is instead set by > the AAAH. This information will be returned to the originating-AAAF > and FA when the updated feature vector is returned in the AMA. The whole idea with the MIP-Feature-Vector is to give info to the AAAH, which the AAAH uses in its decision on how the HA allocation, etc can/shall be made. Thus, it only the FA and AAAF that sets bits in the MIP-Feature-Vector. > > > (3) It may be that the originating AAAF wants to disallow a foreign > HA, or allow a foreign HA but only if the foreign HA is in the > originating AAAF's domain. Right. So if the AAAF allows the HA to be kept, the AAAF forwards the AMR with the Home-Agent-In-Foreign-Network flag set to one. If the AAAF disallow the HA to be kept it would instead reject the request and return an AMA with negative result code. > If this capability is desired, then two > new flags, settable by the originating AAAF, can be added to the > MIP-Feature-Vector: > > Foreign-HA-Allowed-In-NonOriginating-Network > Foreign-HA-Allowed-In-Originating-Network > > The AAAH, after examining the home agent's IP address and determining > whether the HA resides in the originating network, home network, or > some other foreign network, can examine the two new flags to enforce > the originating AAAF's policy on foreign HAs. > > > This way, the originating AAAF maintains the ability to place retrictions > on foreign HAs before the call is authorized. So what about if you want to configure the AAAF to say that it is ok to keep the HA from some third party domains and not from some others? With this proposal, the AAAH could only judge on NonOriginating-Network or Originating-Network, which is very poor granularity for the originating AAAF's policy decisions on foreign HAs. Again, I would argue that the AAAF should handle its own policy decisions as we have stated it today and I don't see why that is so difficult. Regards, /Tony From owner-aaa-wg@merit.edu Thu Feb 28 01:53:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05241 for ; Thu, 28 Feb 2002 01:53:21 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 40BAF91237; Thu, 28 Feb 2002 01:53:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 10B8E9133A; Thu, 28 Feb 2002 01:53:05 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E238291237 for ; Thu, 28 Feb 2002 01:53:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id B31645DE06; Thu, 28 Feb 2002 01:53:04 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id C930F5DDC7 for ; Thu, 28 Feb 2002 01:53:03 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1S6rBZ08360 for ; Thu, 28 Feb 2002 08:53:11 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 08:53:01 +0200 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 08:52:59 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 08:52:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Thu, 28 Feb 2002 08:52:58 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF27184211FF0@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 271: comments needed Thread-Index: AcG/odASYDEyh+oQRACDtbtsxzoGHgAgCrSA From: To: Cc: , X-OriginalArrivalTime: 28 Feb 2002 06:52:58.0868 (UTC) FILETIME=[8EB53340:01C1C024] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA05241 Hi, The 272 includes also one item which has not been discussed yet. Among the new Accounting-Record-Type(s) introduced in 272 there is also value for record which could be used when spontaneous updating (from client to server) of ongoing acc session is needed. I think this is also needed even in basic acc sessions. How/should this be included in base? Anyway, I think that basic idea of 271 and this updating_possibility_from _client_to_server are both needed. br, JPK -------- inc. -------------------- >UPDATE_PREPAID 7 > An Accounting Update Prepaid record is used to indicate > that a prepaid service will need more credit to continue. It is > also used when service (client) need to update itself tariff of > the ongoing accounting session. This record contains all > information that is relevant to determine cost of the service and > granted threshold. -------- inc. --------------------- -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 27. February 2002 17:18 To: Koskinen Juha-Pekka (NET/Tampere) Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed Ah, now I see that 272 is also discussed under this thread. Sorry for the confusion. Anyway, to answer Juha-Pekka first: The new AVP design was actually that it would be sent from the auth server to the NAS. Additionally, we could allow also it come from the acct server in the responses. In any case, if you are not using authentication and didn't get any response from the acct server, then there's theoretically no way to figure out what to do with the service, unless local configuration knows. So, it would seem to me that providing both auth server and acct server responses with this new AVP where needed would satisfy all needs. However, my proposal for realtime-required avp was actually a bit different than what I understood issue 272 to want to have. Basically, there are two things: - Whether you want to give service if you can't send in acct data - Priority order between queued records at an accounting server or proxy The realtime-required AVP deals with the first issue. The new AVP I was talking about in issue 272 deals with the second issue. If you think we're fine with just the first service then we could just agree on 271 and reject 272. If not, we need to do something also for 272. I believe 271 needs to be done in any case, because the current spec is inconsistent. Jari juha-pekka.koskinen@nokia.com wrote: > Hi, > > Well what I wonder here is if this > > 9.8.x. Accounting-Realtime-Required AVP > > is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost... > > The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments. > > br, > JPK > > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 27. February 2002 13:34 > To: Koskinen Juha-Pekka (NET/Tampere); 'aaa-wg@merit.edu' > Cc: 'jari@arkko.com' > Subject: RE: [AAA-WG]: Issue 271: comments needed > > > Hi Juha, > > >>As Jari has stated: >>"..in some cases we would like to stop services if we can't >>provide real-time accounting, while in some other cases we would like >>to continue." >> >>That was also in my mind when I suggested issue 272. There is >>cases where the accounting records could simply be stored by >>the client if the accounting server doesn't response even to >>intial ACR but in some cases the services must be stopped if >>ACA is not received. That was the reason I proposed new >>Accounting-Record-Type values 5-8. When these values (5-8) is >>sent in ACR, the service must be stopped if ACA is not received. >> > > Do you think that Jari's comments are enough for both issues (271 & 272)? > Or do you have other text? > > John > > From owner-aaa-wg@merit.edu Thu Feb 28 02:46:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13867 for ; Thu, 28 Feb 2002 02:46:06 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5D49B9133A; Thu, 28 Feb 2002 02:45:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB409133D; Thu, 28 Feb 2002 02:45:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED8EB9133A for ; Thu, 28 Feb 2002 02:45:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id A16805DE0B; Thu, 28 Feb 2002 02:45:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id 291E65DDD4 for ; Thu, 28 Feb 2002 02:45:12 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1S7j6Zc023350 for ; Thu, 28 Feb 2002 08:45:06 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Feb 28 08:44:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 08:43:05 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F94747@efijont102> From: "Harri Hakala (LMF)" To: "'juha-pekka.koskinen@nokia.com'" , jari.arkko@kolumbus.fi Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Thu, 28 Feb 2002 08:44:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I agree with Jukka-Pekka that the spontaneous updating (from client to server) would be helpful. There are events in the client side that needs to be reported before the Accounting-Interim-Interval expires. These events might contain information which affects the current rating of the service. In my opinion this is really needed to be able to fulfill the statement in section 9.1 "real-time transfer of accounting records is a requirement, such as the need to perform credit limit check and fraud detection". What do you mean by 'granted threshold' and how do you define it ? Is it time ? data volume ? number of events ? Monetary unit ? Regards.......Harri -----Original Message----- From: juha-pekka.koskinen@nokia.com [mailto:juha-pekka.koskinen@nokia.com] Sent: 28. helmikuuta 2002 8:53 To: jari.arkko@kolumbus.fi Cc: john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 271: comments needed Hi, The 272 includes also one item which has not been discussed yet. Among the new Accounting-Record-Type(s) introduced in 272 there is also value for record which could be used when spontaneous updating (from client to server) of ongoing acc session is needed. I think this is also needed even in basic acc sessions. How/should this be included in base? Anyway, I think that basic idea of 271 and this updating_possibility_from _client_to_server are both needed. br, JPK -------- inc. -------------------- >UPDATE_PREPAID 7 > An Accounting Update Prepaid record is used to indicate > that a prepaid service will need more credit to continue. It is > also used when service (client) need to update itself tariff of > the ongoing accounting session. This record contains all > information that is relevant to determine cost of the service and > granted threshold. -------- inc. --------------------- -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 27. February 2002 17:18 To: Koskinen Juha-Pekka (NET/Tampere) Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed Ah, now I see that 272 is also discussed under this thread. Sorry for the confusion. Anyway, to answer Juha-Pekka first: The new AVP design was actually that it would be sent from the auth server to the NAS. Additionally, we could allow also it come from the acct server in the responses. In any case, if you are not using authentication and didn't get any response from the acct server, then there's theoretically no way to figure out what to do with the service, unless local configuration knows. So, it would seem to me that providing both auth server and acct server responses with this new AVP where needed would satisfy all needs. However, my proposal for realtime-required avp was actually a bit different than what I understood issue 272 to want to have. Basically, there are two things: - Whether you want to give service if you can't send in acct data - Priority order between queued records at an accounting server or proxy The realtime-required AVP deals with the first issue. The new AVP I was talking about in issue 272 deals with the second issue. If you think we're fine with just the first service then we could just agree on 271 and reject 272. If not, we need to do something also for 272. I believe 271 needs to be done in any case, because the current spec is inconsistent. Jari juha-pekka.koskinen@nokia.com wrote: > Hi, > > Well what I wonder here is if this > > 9.8.x. Accounting-Realtime-Required AVP > > is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost... > > The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments. > > br, > JPK > > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 27. February 2002 13:34 > To: Koskinen Juha-Pekka (NET/Tampere); 'aaa-wg@merit.edu' > Cc: 'jari@arkko.com' > Subject: RE: [AAA-WG]: Issue 271: comments needed > > > Hi Juha, > > >>As Jari has stated: >>"..in some cases we would like to stop services if we can't >>provide real-time accounting, while in some other cases we would like >>to continue." >> >>That was also in my mind when I suggested issue 272. There is >>cases where the accounting records could simply be stored by >>the client if the accounting server doesn't response even to >>intial ACR but in some cases the services must be stopped if >>ACA is not received. That was the reason I proposed new >>Accounting-Record-Type values 5-8. When these values (5-8) is >>sent in ACR, the service must be stopped if ACA is not received. >> > > Do you think that Jari's comments are enough for both issues (271 & 272)? > Or do you have other text? > > John > > From owner-aaa-wg@merit.edu Thu Feb 28 04:06:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14899 for ; Thu, 28 Feb 2002 04:06:53 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7C4949133E; Thu, 28 Feb 2002 04:06:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 498D391340; Thu, 28 Feb 2002 04:06:40 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 299C09133E for ; Thu, 28 Feb 2002 04:06:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0306E5DE0B; Thu, 28 Feb 2002 04:06:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 46EA35DDDB for ; Thu, 28 Feb 2002 04:06:38 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1S96iZ14615 for ; Thu, 28 Feb 2002 11:06:44 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 11:06:36 +0200 Received: from esebe008.NOE.Nokia.com ([172.21.138.48]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 11:06:35 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe008.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 11:06:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Date: Thu, 28 Feb 2002 11:06:35 +0200 Message-ID: <8B816BAE7071AB4AB2D1BD35E017A6A806B8D2@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Thread-Index: AcG/bxW59lbgjyO/RJaBGYdUIHYK0AAx4CJg From: To: , , X-OriginalArrivalTime: 28 Feb 2002 09:06:35.0533 (UTC) FILETIME=[390333D0:01C1C037] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA14899 Hi, I fully agree with Paco. The proposed two new scenarios seem very important especially in the new world with 3rd party service providers. So why limit the focus already in this phase? The proposed solution to cover these items is very simple. -Anne > -----Original Message----- > From: ext fmaring@airtel.es [mailto:fmaring@airtel.es] > Sent: Wednesday, February 27, 2002 8:10 AM > To: Harri Hakala (LMF); 'aaa-wg@merit.edu' > Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios > > > > Hi Harri, > > I'll try to explain my point again, > > >Hi Paco, > > >I see your point and I agree with you that the > >explained scenarios are important to cover from a charging > >perspective. But I think that you can use the existing mechanism > >provided by credit control draft to solve your problem > >(check the balance). > > Yes, to check the balance could be used the several > interrogations CCA (session control). However, > if what we want is only to check the balance. Why to use > several interrogations to get it? Why don't > give to the application flexibility enough to ease the > ability of checking the balance in an only > interrogation? I understand this flexibility could be > compatible with the current especified version > in the draft. > > >The focus of the draft is to provide network > operator/service provider > >with means to check that the end user has credit before rendering the > >service in order to prevent credit loss. It does not focus account > >update/promotion functions or account enquiry functions. > > Ok, Harri. Nothing to comment if the focus of your draft is > strictly closed. However my idea was to > take advantage of the described mecanisms without adding much > complexity to endow the application > with enhanced capabilities to solve the problem of the > increment of credit. Traditionaly, in the > network operators, discount and increment of credit were > treated in different ways. For the network > operator was critic the fraud produced when a service is > provided to a user that has no credit. To > refund the credit incorrectly discounted, other means could > be applied. However when the third > parties appear in the scenario of the telecomunications world > the rules could be different. A third > party could give to a network operator user a number of > services for free, or simply give free > credit to the user (due to, as commented, the access to > advertisement pages as an example), this > extra credit could be charged in real time to the third party > by the network operator, however the > third party could demand to the network operator to increase > the credit of this user in real time as > well. On the other hand, the market image of the operator > could demand for several network operator > services to be able to accomplish the increments in the user > account in real time as well. In the > future, to be able to accomplish these features could be as > important as the ability of decrement > credit in real time. Credit is credit, this application acts > on the user credit, an increment is > only a negative decrement, we have the tools and we have a > reason to do it. Maybe I'm in a mistake > or I'm confussed but, Why don't make it flexible enough? > > It could be summarized in the question: Why don't open a bit > more the focus of the draft to include > these abilities? These ones could be of interest from the > point of network operators. > > > > Thanks for your attention. > > Regards, > > Paco. > > > > > > > > > > "Harri Hakala (LMF)" con fecha > 25/02/2002 14:21:08 > Asunto: RE: [AAA-WG]: Diameter CCNA protocol: uncovered scenarios > > Hi Paco, > > I see your point and I agree with you that the > explained scenarios are important to cover from a charging > perspective. But I think that you can use the existing mechanism > provided by credit control draft to solve your problem > (check the balance). > > In your scenario when the network operator (credit control client) > receives the SM from the third party, it can start accounting session > and try to make credit-reservation. If granted-service-unit is > returned by the credit control server, the network operator > can acknowledge > the SM delivery to the third party. If the end user is out of coverage > (no acknowledgement), the network operator can stop the > accounting session > and indicate that the used-service-unit is zero. I assume > that the network > operator will get indication when the end user is attached > again, so it can > re-start accounting session and SM delivery to the end-user > and there is no > need to keep the accounting session open several days. > > The focus of the draft is to provide network operator/service provider > with means to check that the end user has credit before rendering the > service in order to prevent credit loss. It does not focus account > update/promotion functions or account enquiry functions. > > Regards.............Harri > > > -----Original Message----- > From: fmaring@airtel.es [mailto:fmaring@airtel.es] > Sent: 19. helmikuuta 2002 8:41 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Diameter CCNA protocol: uncovered scenariosu > > > Issue : Possible modification to the Diameter Cost Control > Application protocol > Submitter name: Paco Marin > Submitter email address: fmaring@airtel.es > Date first submitted: 02-18-2002 > Reference: > Document: draft-hakala-diameter-credit-control-01.txt > Comment type: Technical > > > > Hi all, > > I've been taking look to the last version of the draft > 'Diameter Credit Control Application' > (draft-hakala-diameter-credit-control-01.txt). I've been > thinking about common services an operator > like my company needs to offer and the possibility of > applying DIAMETER CCA to the charging part. > Sorry if some of the following issues are obvious, but I > think despite of the most of the scenarios > being covered with the described protocol, however I did'nt > find the way to use this protocol to > cover two possible scenarios. The referred scenarios are the > following: > > 1.- Check of balance. > Sometimes is necessary to check if there is enough > balance to grant a service to a subscriber. > Imagine a subscriber of a mobile comunications operator wants > to download a melody or a 'logo' from > the Internet on his mobile phone (using the Short Message > Service of GSM). In this scenario, there > are three parts: the subscriber, the network operator and a > third party which is the service > provider. The third party will charge the sent melody (or > logo) to the network operator just when > the network operator receives it, so it could be interesting > to acknowledge the Short Message > delivery from the third party only when the subscriber has > enough credit. This way the operator > avoids to pay for a message that will never be delivered > because the final user (the subscriber) has > no credit enough. I've been thinking about the possibility of > using 'session based credit control'. > However is hardly ineficient, the SM must be acknowledged > immediately and the short message could > wait several days to be delivered to the final user (the user > could be out of coverage), it implies > to keep the session opened until the SM is finally delivered. > > 2.- Increment of Credit > In some scenarios could be useful to add to the protocol > the posibility to increase the balance > instead of decrementing it. As an example, could be a way to > motivate the user access to > advertisement information in the internet or to receive > adversiting Short Messages from a third > party. In these scenarios could be interesting to be able to > increment the credit directly from the > client, as an example increase money on the user account or > allow 1 free short message every 5 > advertisement Short Message received. > > I think there is no way to make it with the current version > of the draft (please, please, please > correct me if I am wrong or confused). > > The solution to these two scenarios should not be fundamental > for the overall working of the > Diameter CCA, however it would apply flexibility enough to > ease the use of the protocol to the > legacy architectures of the current network operators. > > > > In my humble opinion a possible solution for both > scenarios should be to include a new AVP. > > > PROPOSAL OF SOLUTION > > > A new AVP to indicate an operation on the balance is going to > be accomplished could be added to the > proposed AVPs of the Diameter CCA protocol. This AVP could > indicate if the action to be carried out > is a decrement, check of balance or an increment. If this new > AVP is not included in the request, > the server should consider that the value of this one is '0', > it will mean the behaviour of the > protocol will be the one described up to now. The new AVP could be: > > 'Balance-Management-Indicator', it should be of tipe > Unsigned32 and its values could be: > > '0': Decrement, the request and answer work as up to > now. The 'Requested-Service-Unit' AVP > contains the unit to decrement, the 'Granted-Service-Unit' > AVP contains the service units granted. > This units will be decremented in that moment from the user account. > > '1':Check of balance, the 'Requested-Service-Unit' AVP > could contains the service unit to check > if it is allowed to be carried out, the > 'Granted-Service-Unit' AVP contains the service units > allowed to be carried out. This units will NOT be decremented > from the user account. > > '2': Increment, the request and answer work in a similar > way as described for the value '0'. > The 'Requested-Service-Unit' AVP contains the unit to > increment, the 'Granted-Service-Unit' AVP > contains the service units incremented. This units will be > incremented in that moment in the user > account. > > > > > The accounted AVP table should be modified as follows: > > +----------+ > | Command | > | code | > +----+-----+ > Attribute Name |ACR | ACA | > ------------------------------+----+-----+ > Balance-Management-Indicator |0-1 | 0 | > ------------------------------+----+-----+ > > > > > Maybe I'm confused..... correct me in that case. > > > Thanks a lot. > > Paco. > > > > > > > > > From owner-aaa-wg@merit.edu Thu Feb 28 04:55:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15670 for ; Thu, 28 Feb 2002 04:55:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E306291340; Thu, 28 Feb 2002 04:55:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DCC591341; Thu, 28 Feb 2002 04:55:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A41D91340 for ; Thu, 28 Feb 2002 04:55:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6483E5DE0D; Thu, 28 Feb 2002 04:55:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id A2B5F5DDDB for ; Thu, 28 Feb 2002 04:55:34 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1S9u8i22426 for ; Thu, 28 Feb 2002 11:56:08 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 11:55:33 +0200 Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 11:55:33 +0200 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 11:55:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Thu, 28 Feb 2002 11:55:32 +0200 Message-ID: <0AA9E01B31168E42A308714A6EF27184211FF1@trebe002.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 271: comments needed Thread-Index: AcHAK9scVzEyksPPQzmNpPhRsnSbLwAEIgSg From: To: , Cc: , X-OriginalArrivalTime: 28 Feb 2002 09:55:33.0135 (UTC) FILETIME=[0FF5B1F0:01C1C03E] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA15670 Hi, Harri wrote: >What do you mean by 'granted threshold' and >how do you define it ? >Is it time ? data volume ? number of events ? Monetary unit ? I simply mean that threshold is some value (e.g. Interim-Interval in seconds in basic cases) which client can decrease before the new ACR must be sent. The type of the threshold could be anything as long as it is measurable and understanable to client (and server). br, JPK -----Original Message----- From: ext Harri Hakala (LMF) [mailto:Harri.Hakala@lmf.ericsson.se] Sent: 28. February 2002 9:44 To: Koskinen Juha-Pekka (NET/Tampere); jari.arkko@kolumbus.fi Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 271: comments needed Hi, I agree with Jukka-Pekka that the spontaneous updating (from client to server) would be helpful. There are events in the client side that needs to be reported before the Accounting-Interim-Interval expires. These events might contain information which affects the current rating of the service. In my opinion this is really needed to be able to fulfill the statement in section 9.1 "real-time transfer of accounting records is a requirement, such as the need to perform credit limit check and fraud detection". What do you mean by 'granted threshold' and how do you define it ? Is it time ? data volume ? number of events ? Monetary unit ? Regards.......Harri -----Original Message----- From: juha-pekka.koskinen@nokia.com [mailto:juha-pekka.koskinen@nokia.com] Sent: 28. helmikuuta 2002 8:53 To: jari.arkko@kolumbus.fi Cc: john.loughney@nokia.com; aaa-wg@merit.edu Subject: RE: [AAA-WG]: Issue 271: comments needed Hi, The 272 includes also one item which has not been discussed yet. Among the new Accounting-Record-Type(s) introduced in 272 there is also value for record which could be used when spontaneous updating (from client to server) of ongoing acc session is needed. I think this is also needed even in basic acc sessions. How/should this be included in base? Anyway, I think that basic idea of 271 and this updating_possibility_from _client_to_server are both needed. br, JPK -------- inc. -------------------- >UPDATE_PREPAID 7 > An Accounting Update Prepaid record is used to indicate > that a prepaid service will need more credit to continue. It is > also used when service (client) need to update itself tariff of > the ongoing accounting session. This record contains all > information that is relevant to determine cost of the service and > granted threshold. -------- inc. --------------------- -----Original Message----- From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 27. February 2002 17:18 To: Koskinen Juha-Pekka (NET/Tampere) Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed Ah, now I see that 272 is also discussed under this thread. Sorry for the confusion. Anyway, to answer Juha-Pekka first: The new AVP design was actually that it would be sent from the auth server to the NAS. Additionally, we could allow also it come from the acct server in the responses. In any case, if you are not using authentication and didn't get any response from the acct server, then there's theoretically no way to figure out what to do with the service, unless local configuration knows. So, it would seem to me that providing both auth server and acct server responses with this new AVP where needed would satisfy all needs. However, my proposal for realtime-required avp was actually a bit different than what I understood issue 272 to want to have. Basically, there are two things: - Whether you want to give service if you can't send in acct data - Priority order between queued records at an accounting server or proxy The realtime-required AVP deals with the first issue. The new AVP I was talking about in issue 272 deals with the second issue. If you think we're fine with just the first service then we could just agree on 271 and reject 272. If not, we need to do something also for 272. I believe 271 needs to be done in any case, because the current spec is inconsistent. Jari juha-pekka.koskinen@nokia.com wrote: > Hi, > > Well what I wonder here is if this > > 9.8.x. Accounting-Realtime-Required AVP > > is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost... > > The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments. > > br, > JPK > > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 27. February 2002 13:34 > To: Koskinen Juha-Pekka (NET/Tampere); 'aaa-wg@merit.edu' > Cc: 'jari@arkko.com' > Subject: RE: [AAA-WG]: Issue 271: comments needed > > > Hi Juha, > > >>As Jari has stated: >>"..in some cases we would like to stop services if we can't >>provide real-time accounting, while in some other cases we would like >>to continue." >> >>That was also in my mind when I suggested issue 272. There is >>cases where the accounting records could simply be stored by >>the client if the accounting server doesn't response even to >>intial ACR but in some cases the services must be stopped if >>ACA is not received. That was the reason I proposed new >>Accounting-Record-Type values 5-8. When these values (5-8) is >>sent in ACR, the service must be stopped if ACA is not received. >> > > Do you think that Jari's comments are enough for both issues (271 & 272)? > Or do you have other text? > > John > > From owner-aaa-wg@merit.edu Thu Feb 28 07:19:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18867 for ; Thu, 28 Feb 2002 07:19:44 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 86FAF91347; Thu, 28 Feb 2002 07:19:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4F04291348; Thu, 28 Feb 2002 07:19:24 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59E7C91347 for ; Thu, 28 Feb 2002 07:19:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3FA0E5DDFC; Thu, 28 Feb 2002 07:19:23 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by segue.merit.edu (Postfix) with ESMTP id BFFBB5DDC7 for ; Thu, 28 Feb 2002 07:19:22 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g1SCJLZc005717 for ; Thu, 28 Feb 2002 13:19:21 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Feb 28 13:19:07 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Feb 2002 13:09:25 +0100 Message-ID: <0154633DAF7BD4119C360002A513AA0301F9474C@efijont102> From: "Harri Hakala (LMF)" To: "'anne.narhi@nokia.com'" , "'fmaring@airtel.es'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Date: Thu, 28 Feb 2002 13:18:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, So you would like to have the check balance method to be as one time event, not session based (several interrogations) and it verifies that subscriber has enough credit (on/off). It only checks the account balance, but doesn't do any credit-reservation. Note that this doesn't guarantee that there is still credit left when the client afterwards contacts the server to reserve/deduct units from the account. I think also that the increment and decrement method must be mutually exclusive within the session, that is either we just add units to the account or deduct units from the account. Otherwise the service interactions are rather complex from the server point of view. Regards......Harri From owner-aaa-wg@merit.edu Thu Feb 28 08:14:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21198 for ; Thu, 28 Feb 2002 08:14:58 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 563D59134C; Thu, 28 Feb 2002 08:14:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 254FC9134D; Thu, 28 Feb 2002 08:14:49 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E3089134C for ; Thu, 28 Feb 2002 08:14:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C1C65DDDB; Thu, 28 Feb 2002 08:14:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E993E5DDC7 for ; Thu, 28 Feb 2002 08:14:47 -0500 (EST) Received: from phoenix (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B264579; Thu, 28 Feb 2002 08:14:47 -0500 (EST) From: "Bob Kopacz" To: "Tony Johansson" Cc: Subject: RE: [AAA-WG]: ISSUE 266: ready for closure? Date: Thu, 28 Feb 2002 08:13:53 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <3C7C4F07.F46B482@ericsson.com> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tony, > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Tuesday, February 26, 2002 10:14 PM > To: Bob Kopacz > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: ISSUE 266: ready for closure? > > Bob Kopacz wrote: > > > > > > > Well, we must still make it possible encrypt the FA-HA Key between the > > > two AAAFs involved, since there is only a SHOULD for Diameter clients > > > to support DSA. > > > > > > /Tony > > > > Your note that clients are not required to support CMS is a good one, > > so I'm back on track with you. Forget my "One thought". > > Good, so do we agree on the solution for issue #266 (with the editorial > changes you sent earlier)? Yes. I do think that at some point we need another (separate) issue, to indicate that the AAAH solves his key-hiding in a similar way, i.e. setting up a DSA with the AAAF rather than the FA or HA. Bob K. From owner-aaa-wg@merit.edu Thu Feb 28 11:01:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00166 for ; Thu, 28 Feb 2002 11:01:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id E37509125A; Thu, 28 Feb 2002 11:00:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 411119134D; Thu, 28 Feb 2002 11:00:25 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0E4EC9125A for ; Thu, 28 Feb 2002 11:00:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id DB1185DE10; Thu, 28 Feb 2002 11:00:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 5AD275DDFC for ; Thu, 28 Feb 2002 11:00:19 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SG0YG06178 for ; Thu, 28 Feb 2002 10:00:34 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 10:00:18 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 09:59:38 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 28 Feb 2002 09:59:37 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12882@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/+rr01IE0x3ALSqm2B3+Oc9cC7gAdhvvg From: To: , X-OriginalArrivalTime: 28 Feb 2002 15:59:38.0115 (UTC) FILETIME=[EC951D30:01C1C070] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00166 Barney Wolff [barney@databus.com] wrote: >Consider gateways from RADIUS or other AAA protocols. Consider a rebooting >NAS - is it sure what it might have sent before it crashed? > >As a sender, what's my liability because you as receiver double >charged or locked out some customer because I failed to set the >D-bit and you relied on my perfection? Guess what - if it's not >$0.00 I'm going to set the D-bit on *every* record. Hopefully there are no lawyers snooping on the communication lines :) but for the sender there is no obligation other than complying to the specification. So the liability is absolutely $0.00, at least when one does what is specified to be the proper behavior in a failover case by the specification. After a link/node failover, the Diameter node that is sending accounting records, may have in a buffer "sent-but-not-yet-acknowledged" accounting records a few records remaining. If (and when) the node decides to send them after failover procedures, then it should mark them with the D-bit as possible duplicates (for safety). That is all it needs to do. The sender has no other responsibility here, and even that "task" is to be performed for eg. one record for every billion or even less often, the actual ratio depends on how many packets on an average are sent between a link/node crashes. > >Barney -Basavaraj From owner-aaa-wg@merit.edu Thu Feb 28 11:06:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00422 for ; Thu, 28 Feb 2002 11:06:57 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BFBBB91301; Thu, 28 Feb 2002 11:06:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7CC179134D; Thu, 28 Feb 2002 11:06:43 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0A3091301 for ; Thu, 28 Feb 2002 11:06:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF12C5DDFC; Thu, 28 Feb 2002 11:06:41 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 4832A5DDF7 for ; Thu, 28 Feb 2002 11:06:41 -0500 (EST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SG6uG06685 for ; Thu, 28 Feb 2002 10:06:56 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 10:06:39 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 10:06:30 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C071.E1FA389C" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 28 Feb 2002 10:06:29 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12884@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcG/7WaMC5e+v4UXSXKZ84m1sRxqJgAhGnYg From: To: , , X-OriginalArrivalTime: 28 Feb 2002 16:06:30.0133 (UTC) FILETIME=[E22A1250:01C1C071] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1C071.E1FA389C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pat R. Calhoun [pcalhoun@bstormnetworks.com] wrote: =20 >> Do people believe generating the D-bit reliably is a trivial burden=20 >> on the sender? If so then it does no harm, because the receiver=20 >> can always ignore it. But I don't think it's that trivial. As a=20 >> receiver I'd be very wary of depending on the sender to trigger=20 >> the dup check.=20 > >Check, and if receivers aren't likely to trust the sender to inform=20 >it of a duplicate, does having this in the protocol even make sense?=20 > =20 Receivers could trust the sender if the specification mandates that the sender mark potential duplicates with the "D" bit. =20 Of course the D-bit is not intended to be set in every record, as it would remove the uniqueness checking performance benefit. And if the accounting systems have to be absolutely certain they could take the post-processing aproach to resolve duplicates. But there are accounting systems that need to do this check much more rapidly and cannot wait for post-processing.=20 =20 >PatC=20 =20 -Basavaraj =20 > ------_=_NextPart_001_01C1C071.E1FA389C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Request for closure on issue 235

Pat R. Calhoun [pcalhoun@bstormnetworks.com] wrote:
 
>> Do people believe generating the D-bit reliably is a = trivial=20 burden
>> on the sender?  If  so then it does no = harm,=20 because the receiver
>> can always ignore it.  But I = don't=20 think  it's that trivial.  As a
>> receiver I'd be = very wary=20 of depending on the sender to trigger
>> the dup check.=20
>
>Check, and if receivers aren't likely to trust the = sender to=20 inform
>it of a duplicate, does having this in the protocol even = make=20 sense?
>
 
Receivers could trust the sender if the specification mandates = that
the=20 sender mark potential duplicates with the "D" bit.
 
Of course the D-bit is not intended to be set in every record, as=20 it
would remove the uniqueness checking performance benefit. = And
if the=20 accounting systems have to be absolutely certain they could
take the=20 post-processing aproach to resolve duplicates. But there = are
accounting=20 systems that need to do this check much more rapidly and
cannot wait = for=20 post-processing.
 
>PatC
 
-Basavaraj
 
>
------_=_NextPart_001_01C1C071.E1FA389C-- From owner-aaa-wg@merit.edu Thu Feb 28 13:57:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12680 for ; Thu, 28 Feb 2002 13:57:00 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5C23B91352; Thu, 28 Feb 2002 13:56:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2B39E91353; Thu, 28 Feb 2002 13:56:17 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E02E91352 for ; Thu, 28 Feb 2002 13:56:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 118765DDD6; Thu, 28 Feb 2002 13:56:16 -0500 (EST) 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 CBD025DDA0 for ; Thu, 28 Feb 2002 13:56:15 -0500 (EST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A6F8E6A906; Thu, 28 Feb 2002 20:56:14 +0200 (EET) Message-ID: <3C7E7D9A.9010507@kolumbus.fi> Date: Thu, 28 Feb 2002 20:57:30 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: john.loughney@nokia.com, Basavaraj.Patil@nokia.com, "Pat R. Calhoun" , barney@databus.com Subject: [AAA-WG]: Issue 235 and another potential fast duplicate check method 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 (sorry for the resend if you get this twice...) Another method to do a fast duplicate check at an accounting server. This method doesn't need any protocol modifications, has a very high likelihood of never needing *any* record searches unless duplicates are indeed around, is reliable even if there are sender implementation problems or reboots, and requires O(constant) amount of work per received record. Or at least I think so -- you are welcome to shoot this down! I may well missed something and I'm writing this while participating in a boring teleconference [;-)] Approach: Use a hash table to find out if an equivalent session id has been seen earlier (or collision in the hash values).If the hash table indicates nothing has been seen, no record search is performed. If it does indicate something has been seen, then a full search will be done. The hash table is updated as new records come in, and as the duplicate window (e.g. a day) moves further. Data structures: 1) A fixed size table with counters as elements. Size of table can be chosen freely. 2) A database of all records, with two cursors pointing to the beginning of the duplicate window (a day old record) and to the most recent record. Initialization: The table is initialized with all zeroes. Database is empty. Duplicate check: Take the session id from the received record and produce a hash value H=hash(sessionId) from it. If table[H] == 0, there is no need to do any record searches. If table[H] > 0, do a search for the session id from the data base. Unless a duplicate is found in this search, put the new record to the database. Then increase the counter related to this session id hash by table[H]++. Advancing the duplicate window: Move the duplicate window cursor ahead by one, and produce a hash value H=hash(sessionId). Then decrement the relevant counter by table[H]--. Jari From owner-aaa-wg@merit.edu Thu Feb 28 14:17:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14026 for ; Thu, 28 Feb 2002 14:17:37 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 343F491353; Thu, 28 Feb 2002 14:17:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F38F191355; Thu, 28 Feb 2002 14:17:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 955DE91353 for ; Thu, 28 Feb 2002 14:17:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67BFC5DDD6; Thu, 28 Feb 2002 14:17:05 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from m2-pasarela3.airtel.es (unknown [212.166.209.12]) by segue.merit.edu (Postfix) with ESMTP id D917D5DDA0 for ; Thu, 28 Feb 2002 14:17:02 -0500 (EST) Subject: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios To: "Harri Hakala (LMF)" Cc: "'anne.narhi@nokia.com'" , "'aaa-wg@merit.edu'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: fmaring@airtel.es Date: Thu, 28 Feb 2002 20:15:42 +0100 X-MIMETrack: Serialize by Router on M2-SMTP3/AIRTEL(Release 5.0.5 |September 22, 2000) at 02/28/2002 08:17:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Harri, ... (and Anne) the following is an explanation of my point....I'll try to make my best.... >Hi, >So you would like to have the check balance method to be >as one time event, not session based (several interrogations) >and it verifies that subscriber has enough credit (on/off). >It only checks the account balance, but doesn't do any >credit-reservation. Note that this doesn't guarantee that >there is still credit left when the client afterwards contacts >the server to reserve/deduct units from the account. Certain, Harri, if we use 'one time event balance method' and afterwards another one time event method is used to charge a service, we will have a fraud window..... maybe the user had no credit when we try to charge the service because it could have been consumed in the while between both requests. However, it does not mean this method could be useless. When an operator has legacy networks sometimes is difficult to apply a specific method because the network itself does not fit all the requirements to be applied this specific method in a specific scenario. To make flexible the protocol could ease the implementation for the network operator. The real services sometimes are not as perfect as could appear in a power point presentation, as an example it could be refered my e-mail sent last February the 19th: "... so it could be interesting to acknowledge the Short Message delivery from the third party only when the subscriber has enough credit. This way the operator avoids to pay for a message that will never be delivered because the final user (the subscriber) has no credit enough. I've been thinking about the possibility of using 'session based credit control'. However is hardly ineficient, the SM must be acknowledged immediately and the short message could wait several days to be delivered to the final user (the user could be out of coverage), it implies to keep the session opened until the SM is finally delivered. " Harri, you wrote in a later mail the following: "In your scenario when the network operator (credit control client) receives the SM from the third party, it can start accounting session and try to make credit-reservation. If granted-service-unit is returned by the credit control server, the network operator can acknowledge the SM delivery to the third party. If the end user is out of coverage (no acknowledgement), the network operator can stop the accounting session and indicate that the used-service-unit is zero. I assume that the network operator will get indication when the end user is attached again, so it can re-start accounting session and SM delivery to the end-user and there is no need to keep the accounting session open several days." However not always is possible (or easy) neither to inform the charging system that the user is atached again nor to add to each node the implementation of the Diameter client (normally, real networks are multivendor networks and not always is easy to ask for the vendor to implement a specific standard). In this example, the network operator must pay to the third party for the received SMS, but must do it just in the moment that it is received..... the third party will not wait until the network operator be sure the SMS is delivered to the destination. In this situation the network operator must check whether the user has credit available, maybe the session control mechanism could be used, however if the session is kept opened until the message is delivered it would be inefficient. The network operator must, then, use two separate requests (event charging requests), one prior to allow the SMS be received from the third party (and paied for it) and another one when the SMS is delivered to the final user. This way the network operator could decide: 1.- To charge always to the destination user and refund the credit to him if the SMS is finally not delivered (two separate requests, not using 'session control charging'). 2.- To check whether the destination user has credit available and charge when the SMS is delivered (two separate requests, not using 'session control charging'). 3.- Not to check nothing when the SMS is received from the third party and try to charge the SMS when is correctly delivered. 4.-... The third option implies that will be fraud: all the messages from the third party will be allowed (and paied for them), however a part of the SMS will not be charged to the final destination because the user have no credit or because the SMS failed to be delivered. The first and second options are possible solutions, in the second one a window of fraud exists. In the first solution no fraud exists but we have to be able to refund the credit to the user if the SMS was not delivered successfully..... The decision to take depends on the marketing objectives of the company but it also depends on the technical solution is possible to have. For the network operators the final solution could be easier if the Diameter Cost Control Application were more flexible. These options (first and second), could only be implemented if the check of balance and increment of credit can be used. This is the kind of flexibility that could be desirable from the point of a network operator. On the other hand, I think (please, correct me if I'm loosing something) the check of balance, the increment and decrement could be mutually exclusive being completely compatible with the current draft: If a new AVP is included (called as an example 'Balance-Management-Indicator')... the information about what to do in the server could be indicated in this AVP: If the value is '0' or SIMPLY THIS AVP DOES NOT EXISTS.... the server will decrement the credit indicated in the service units of the AVP 'Requested-Service-Units'. The 'Granted-Service-Units' will contain the service units granted. If the value is '1', the server will check the balance. The 'Requested-Service-Units' AVP will have the service units to ask for. The 'Granted-Service-Units' AVP will contain the granted service units BUT THESE UNITS WILL BE NEITHER RESERVED NOR DISCOUNTED from the user account. If the value is '2', the server will increment the credit. The 'Requested-Service-Units' AVP will have the service units to increment. The 'Granted-Service-Units' AVP will contain the incremented service units in the user account. Optionally the 'Cost-Information' AVP could contain the cost of the units incremented. As can you see, you can do only one of them: a decrement, a check of balance or an increment... to do one of these options implies exclude the other ones (the value of the same indicator identifies the treatment). Why don't make it more flexible? Best regards....... Paco. "Harri Hakala (LMF)" con fecha 28/02/2002 13:18:59 Asunto: RE: [AAA-WG]: Diameter CCA protocol: uncovered scenarios Hi, So you would like to have the check balance method to be as one time event, not session based (several interrogations) and it verifies that subscriber has enough credit (on/off). It only checks the account balance, but doesn't do any credit-reservation. Note that this doesn't guarantee that there is still credit left when the client afterwards contacts the server to reserve/deduct units from the account. I think also that the increment and decrement method must be mutually exclusive within the session, that is either we just add units to the account or deduct units from the account. Otherwise the service interactions are rather complex from the server point of view. Regards......Harri From owner-aaa-wg@merit.edu Thu Feb 28 14:26:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14553 for ; Thu, 28 Feb 2002 14:26:49 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 1019F91355; Thu, 28 Feb 2002 14:26:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C51DD91356; Thu, 28 Feb 2002 14:26:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A564091355 for ; Thu, 28 Feb 2002 14:26:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82C185DDD6; Thu, 28 Feb 2002 14:26:33 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id CB3265DDA0 for ; Thu, 28 Feb 2002 14:26:32 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SJQeZ03365 for ; Thu, 28 Feb 2002 21:26:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 21:26:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 21:26:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Thu, 28 Feb 2002 21:26:31 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B5F@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/8rhOB0ICWzyFS4+KHlj6+tX7OgAOcCCQ From: To: , Cc: , X-OriginalArrivalTime: 28 Feb 2002 19:26:31.0563 (UTC) FILETIME=[D392F5B0:01C1C08D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14553 Hi Jacques & David, I agree with Jacques. David, if you can carefully craft text that fits your exact meaning, please do so. Otherwise lets leave the text as fqdn & if needed, provide additional details in a BCP doc or something, as we are getting into operation details. John > -----Original Message----- > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Sent: 28 February, 2002 02:56 > To: David Spence > Cc: Loughney John (NRC/Helsinki); dzick@Interlinknetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded > > > Then you're really adding something to the "real" FQDN that > is functionally > equivalent to a port number :-) > > If you manage to write some text that explains that clearly and > unambiguously, why not. But I think it's easier to stick to > "real" FQDNs. > It's never hurt anyone to register a couple of addresses in the DNS. > > As an alternative, if the Identity is considered fully > opaque, nothing > prevents us to change it to FQDN;. Where > may be a PID, a port number, a > configuration > file path name, or any other arbitrary string. > > Jacques. > > At 01:12 28/02/2002, David Spence wrote: > >Actually, my idea was that the portion of the identity > string following the > >first dot would be a real host name registered to the host > on which the > >server was running. In my example below, both servers were > running on > >srv.interlinknetworks.com, which is the real name of the > host. diam1 and > >diam2 would be unregistered prefixes to a registered host name. > > > >Jacques Caron wrote: > > > > > > Even though the full name need not necessarily be in the > DNS (though this > > > might have other consequences?), it is necessary that it > is based on a > > > domain name that is registered and owned by the > administrator of the > > > server. Otherwise we'll end up with a bunch of > "diameter.example.com" all > > > over which are definitely not unique :-( > > > > > > I think it's easier if the fqdn is really registered, > just for the purposes > > > of ensuring uniqueness. > > > > > > Jacques. > > > > > > At 22:59 27/02/2002, David Spence wrote: > > > >One question: Does it make any difference whether there > is an A record for > > > >the fqdn in the DNS, i.e., does the fqdn actually need to be > > registered? I > > > >think not. And if it doesn't, that makes it easier for > administrators. > > > >Suppose I run two Diameter servers on > srv.interlinknetworks.com. Then I > > > >could configure one to call itself > diam1.srv.interlinknetworks.com, and I > > > >could configue the other to call itself > diam2.srv.interlinknetworks.com. > > > >Voila! I have guaranteed uniqueness without having to > register a domain > > > >name. If this is agreeable, it might be worth stating > in the draft > > that the > > > >term fqdn does not imply that the name be registered, > only that it be > > > >unique. > > > > > > _________________________________________________________ > > > Do You Yahoo!? > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > From owner-aaa-wg@merit.edu Thu Feb 28 14:27:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14658 for ; Thu, 28 Feb 2002 14:27:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 7893C91357; Thu, 28 Feb 2002 14:26:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1964F91356; Thu, 28 Feb 2002 14:26:36 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6765691357 for ; Thu, 28 Feb 2002 14:26:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 490235DDD6; Thu, 28 Feb 2002 14:26:35 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 62FEE5DDA0 for ; Thu, 28 Feb 2002 14:26:34 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SJQgZ03384 for ; Thu, 28 Feb 2002 21:26:42 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 21:26:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 21:26:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Thu, 28 Feb 2002 21:26:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B60@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/3Q9rELiJcwbSRlK9VLBQVak3+AAT68Tg From: To: Cc: , , X-OriginalArrivalTime: 28 Feb 2002 19:26:33.0110 (UTC) FILETIME=[D47F0360:01C1C08D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14658 Hi Jacques, > What is the URI stuff doing here? It's not a URI, just a FQDN all by > itself. If you need the reference to [URI] just for the definition of > "fqdn" I think it's really ambiguous. I'll remove the URI stuff then. John From owner-aaa-wg@merit.edu Thu Feb 28 14:27:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14684 for ; Thu, 28 Feb 2002 14:27:41 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8FB3D9135D; Thu, 28 Feb 2002 14:26:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F38A391358; Thu, 28 Feb 2002 14:26:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 90F3591359 for ; Thu, 28 Feb 2002 14:26:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B3055DDD6; Thu, 28 Feb 2002 14:26:37 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id AD0F25DDA0 for ; Thu, 28 Feb 2002 14:26:36 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SJQiZ03420 for ; Thu, 28 Feb 2002 21:26:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 21:26:36 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 21:26:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Thu, 28 Feb 2002 21:26:35 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B62@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/8rc5dwzeQHd2S6ix1XbA6MW9xwAO0A3A From: To: , Cc: , X-OriginalArrivalTime: 28 Feb 2002 19:26:35.0407 (UTC) FILETIME=[D5DD81F0:01C1C08D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14684 Hi Jacques, > Right. Anything that "points to" a Diameter node is an URI. > Anything that identifies a node is Identity. Good point. > Redirect-Host should be an URI, and actually be renamed > Redirect-URI for consistency. I've changed the Redirect-host to be of type DiameterURI. I'm leaving this name as Redirect-Host - at this point, I think it is unnescessary to change the name & all associated names, and probably will be more confusing. > Route-Record, Origin-Host, Destination-Host and Proxy-Host should be > identities. Agreed. > Apparently Alternate-Host and Source-Route are no longer with > us, but if they come back, the first one is an URI and the second > an Identity. Hopefully not. John From owner-aaa-wg@merit.edu Thu Feb 28 14:27:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14700 for ; Thu, 28 Feb 2002 14:27:45 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3C7A391359; Thu, 28 Feb 2002 14:26:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 877959135C; Thu, 28 Feb 2002 14:26:42 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 66CD491358 for ; Thu, 28 Feb 2002 14:26:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 41ABA5DDD6; Thu, 28 Feb 2002 14:26:36 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 827D15DDA0 for ; Thu, 28 Feb 2002 14:26:35 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SJR9i18962 for ; Thu, 28 Feb 2002 21:27:09 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 21:26:34 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 21:26:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Thu, 28 Feb 2002 21:26:34 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B61@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcG/3Q9rELiJcwbSRlK9VLBQVak3+AAUCKew From: To: Cc: , , X-OriginalArrivalTime: 28 Feb 2002 19:26:34.0440 (UTC) FILETIME=[D549F480:01C1C08D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14700 Hi Jacques, > "If a Diameter node can be identified by several FQDNs, one > single FQDN > should be picked at startup, and used as the only > DiameterIdentity for that > node, whatever the connection it is sent on." > > It might not be a bad idea to add a sentence to explain what > it's used for, such as: > "The DiameterIdentity value is used to uniquely identify a > Diameter node > for purposes of duplicate connection and routing loop detection". I've added the text. John From owner-aaa-wg@merit.edu Thu Feb 28 14:27:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14719 for ; Thu, 28 Feb 2002 14:27:54 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 9A82A91358; Thu, 28 Feb 2002 14:26:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67C0691361; Thu, 28 Feb 2002 14:26:53 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DC25191358 for ; Thu, 28 Feb 2002 14:26:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id C079C5DDA0; Thu, 28 Feb 2002 14:26:48 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id 0C3AD5DDD6 for ; Thu, 28 Feb 2002 14:26:48 -0500 (EST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SJRMi19031 for ; Thu, 28 Feb 2002 21:27:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 21:26:46 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 21:26:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [Issue] Routing of session messages defined in base Date: Thu, 28 Feb 2002 21:26:46 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B66@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [Issue] Routing of session messages defined in base Thread-Index: AcG/xulzQNu1fCRIRW+sV81qwzwuYwAatbzw From: To: Cc: , , X-OriginalArrivalTime: 28 Feb 2002 19:26:46.0873 (UTC) FILETIME=[DCB31490:01C1C08D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA14719 Hi Dave & Bob, I've added the suggested text. John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 27 February, 2002 21:43 > To: Loughney John (NRC/Helsinki) > Cc: johanj@ipunplugged.com; BKopacz@Interlinknetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [Issue] Routing of session messages defined in > base > > > john.loughney@nokia.com wrote: > > > > Hi all, > > > > Please give exact text for this issue to be added / modified to the > > base spec. > >... > > The Requested change section of Bob Kopacz' issue: > > Proxiable messages MUST contain Axxx-Application-Id AVP > > reads as follows: > > Requested change: > > 1. Require an Auth-Application-Id AVP in > Session-Terminate-Request, > Abort-Session-Request, and Re-Auth-Request messages. > > 2. Update occurrence rule tables for the > "Auth-Application-Id AVP" > row, from "0" to "1", for STR and ASR and RAR. > > For item 1, the STR syntax currently reads: > > ::= < Diameter Header: 275, REQ, PXY > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Termination-Cause } > [ User-Name ] > [ Destination-Host ] > * [ Class ] > [ Origin-State-Id ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > You need to add "{ Auth-Application-Id }": > > ::= < Diameter Header: 275, REQ, PXY > > < Session-Id > > { Origin-Host } > { Origin-Realm } > { Destination-Realm } > { Auth-Application-Id } > { Termination-Cause } > [ User-Name ] > [ Destination-Host ] > * [ Class ] > [ Origin-State-Id ] > * [ AVP ] > * [ Proxy-Info ] > * [ Route-Record ] > > Do the same for ASR and RAR. > > For item 2, the table in base-08 section 10.1 currently begins: > > > +-----------------------------------------------+ > | Command-Code > | > > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name > |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 > |0 |0 | > Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 > |0 |0 | > > Change it to: > > > +-----------------------------------------------+ > | Command-Code > | > > |---+---+---+---+---+---+---+---+---+---+---+---+ > Attribute Name > |CER|CEA|DPR|DPA|DWR|DWA|RAR|RAA|ASR|ASA|STR|STA| > > --------------------|---+---+---+---+---+---+---+---+---+---+---+---| > Acct-Application-Id |0+ |0+ |0 |0 |0 |0 |0 |0 |0 |0 > |0 |0 | > Auth-Application-Id |0+ |0+ |0 |0 |0 |0 |1 |0 |1 |0 > |1 |0 | > > > Additionally, Bob Kopacz recommends adding text to sections > 6.1 and 6.1.1. > > The first sentence of the fourth paragraph of sec. 6.1 reads: > > The Destination-Realm AVP MUST be present if the message > is routable. > > Replace with: > > The Destination-Realm AVP MUST be present if the message is > proxiable. Proxiable request messages MUST also contain either an > Acct-Application-Id AVP or an Auth-Application-Id AVP. > > Note that the term proxiable is defined in the draft. The > term routable > is not. So I changed routable to proxiable. Also note that > the draft > is inconsistent with respect to the spelling of proxiable, sometimes > spelling it proxyable. It should be spelled consistently. > > Section 6.1.1 currently reads: > > When creating a request, in addition to any other procedures > described in the application definition for that specific request, > the following procedures MUST be followed: > > - the Command-Code should be set to the appropriate value > - the 'R' bit should be set > - the End-to-End Identifier should be set to a locally unique > value > - the Origin-Host and Origin-Realm AVPs MUST be set to the > appropriate values, used to identify the source of the message > - the Destination-Host and Destination-Realm AVPs MUST be set to > the appropriate values as described in section 6.1. > > Add an additional bullet: > > - either an Acct-Application-Id AVP or an Auth-Application-Id > AVP must be included if the request is proxiable. > From owner-aaa-wg@merit.edu Thu Feb 28 14:56:29 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16174 for ; Thu, 28 Feb 2002 14:56:28 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id BF89791356; Thu, 28 Feb 2002 14:56:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A9029135B; Thu, 28 Feb 2002 14:56:19 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F5C691356 for ; Thu, 28 Feb 2002 14:56:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 576DC5DDFF; Thu, 28 Feb 2002 14:56:18 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 4DB7F5DE02 for ; Thu, 28 Feb 2002 14:56:17 -0500 (EST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228195607.QEAJ27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 21:56:07 +0200 Message-ID: <00da01c1c091$f7795740$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA4@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: Issue 252: Granting Access via Accounting Date: Thu, 28 Feb 2002 21:56:09 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D7_01C1C0A2.BAD8F460" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01C1C0A2.BAD8F460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No. The 'grant service' action should be deleted, but not the entry. Then there's actually a missed modification to the accounting state machine in [1]. We need to take that, issue 271 new state table, and then this modification. There needs to be some merge of the Discon state and the new style of handling record sends proposed in 271. PendingB state missed error case. As a result, the full state table should be like this: Idle Client or device requests send PendingS access accounting start req. Idle Accounting start request send Open received, and successfully accounting processed. start answer Idle Client or device requests send PendingE a one-time service accounting event req Idle Accounting event request send Idle received, and successfully accounting processed. event answer Idle Records in storage Send PendingB record Open Receive Interim Record send Open accounting answer Open User service terminated send PendingL accounting stop req. Open Accounting stop request send Idle received, and successfully accounting processed stop answer PendingL Successful accounting Idle stop answer received =20 PendingL Failure to send and buffer Store Idle space available Stop Record =20 PendingL Failure to send and no buffer Idle space available =20 PendingE Successful accounting Idle event answer received =20 PendingE Failure to send and buffer Store Idle space available Event Record =20 PendingE Failure to send and no buffer Idle space available =20 PendingS Successful accounting grant Open start answer received access =20 PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime =20 equal to GRANT_AND_LOSE =20 =20 PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE =20 =20 PendingI Failure to send and (buffer Store Open space available or old record Interim can be overwritten) and Record realtime not equal to DELIVER_AND_GRANT =20 PendingI Failure to send and no buffer Open space available and realtime =20 equal to GRANT_AND_LOSE =20 =20 PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE =20 PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle Jari [1] http://www.merit.edu/mail.archives/aaa-wg/2001-12/msg00000.html ----- Original Message -----=20 From: To: Sent: 26. helmikuuta 2002 22:45 Subject: [AAA-WG]: Issue 252: Granting Access via Accounting=20 Hi all, Just to be sure I've got it, should the following be removed from 8.2 Accounting Session State Machine. Pending Successful accounting grant Open start answer received access or ?? John Issue 252: Granting Access via Accounting=20 Submitter name: Bernard Aboba aboba@internaut.com=20 Submitter email address: aboba@internaut.com=20 Date first submitted: 28-Dec-01=20 Reference:=20 Document: base 08=20 Comment type: Technical=20 Priority: S=20 Section: 8.2=20 Rationale/Explanation of issue:=20 Access is not granted based on receipt of a successful=20 accounting start answer=20 Change:=20 In the state table on pp. 86, it states that in Pending state, receipt = of=20 a Successful accounting start answer results in "grant access" and=20 movement to the Open state. Since access is granted within the=20 authentication/authorization state machine, this appears to be an error. ------=_NextPart_000_00D7_01C1C0A2.BAD8F460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
No. The 'grant service' action = should be=20 deleted, but not
the entry.
 
Then there's actually a missed = modification=20 to the accounting
state machine in [1]. We need = to take that,=20 issue 271 new state
table, and then this = modification. There=20 needs to be some
merge of the Discon state and = the new style=20 of handling record
sends proposed in 271. PendingB = state=20 missed error case.
 
As a result, the full state = table should=20 be like this:
 
Idle      Client=20 or device requests     =20 send      =20 PendingS
         =20 access           &= nbsp;           &n= bsp;=20 accounting
          = ;            =             &= nbsp;     =20 start req.

Idle      Accounting start=20 request      =20 send      =20 Open
          received, = and=20 successfully    =20 accounting
        =20  processed.         &nb= sp;          =20 start
          &nbs= p;            = ;            =      =20 answer
Idle      Client=20 or device requests     =20 send      =20 PendingE
          a = one-time=20 service           =  =20 accounting
          = ;=20             &= nbsp;           &n= bsp;    =20 event req
 
Idle     =20 Accounting event request      =20 send      =20 Idle
          received, = and=20 successfully     accounting
         =20 processed.          &nb= sp;         =20 event
          &nbs= p;            = ;            =       answer
 
Idle      Records=20 in=20 storage           =  =20 Send      =20 PendingB
          &= nbsp;           &n= bsp;           &nb= sp;     =20 record

Open      = Receive Interim=20 Record        =20 send      =20 Open
           = ;            =             &= nbsp;    =20 accounting
          = ;            =             &= nbsp;     =20 answer

Open      User service=20 terminated       =20 send       PendingL
  &nb= sp;           &nbs= p;            = ;            =  =20 accounting
          = ;            =             &= nbsp;     =20 stop req.

Open      Accounting stop=20 request       =20 send      =20 Idle
          received, = and=20 successfully    =20 accounting
         =20 processed          &nbs= p;          =20 stop answer

PendingL  Successful=20 accounting          &nb= sp;     =20    =20 Idle
          stop = answer=20 received           =
PendingL  Failure to send and buffer    =20 Store     =20 Idle
          space=20 available          &nbs= p;     Stop
     &nb= sp;           &nbs= p;            = ;          =20 Record
          &nb= sp;           &nbs= p;=20
PendingL  Failure to send and no=20 buffer           &= nbsp;=20 Idle
          space=20 available    
PendingE  Successful=20 accounting          &nb= sp;   =20      =20 Idle
          event= answer=20 received          =
 
PendingE  Failure to send = and=20 buffer     Store     =20 Idle
          space=20 available          &nbs= p;    =20 Event
          &nbs= p;            = ;            =      =20 Record
          &nb= sp;           &nbs= p;=20
PendingE  Failure to send and no=20 buffer           &= nbsp;=20 Idle
          space=20 available    
PendingS  Successful=20 accounting         =20 grant     =20 Open
          start= answer=20 received         =20 access

          = ;            =    =20
PendingS  Failure to send and buffer    =20 Store     =20 Open
          space = available=20 and realtime  =20 Start
          not = equal to=20 DELIVER_AND_GRANT Record
 
PendingS  Failure to send = and no=20 buffer           &= nbsp;=20 Open
          space = available=20 and realtime  =20
          equal to=20 GRANT_AND_LOSE      =20
           &nb= sp;          =20
PendingS  Failure to send and no buffer  Disconnect=20 Idle
          space = available=20 and realtime  =20 user/dev
          not = equal=20 to
         =20 GRANT_AND_LOSE          = ;            =             &= nbsp;         =20
           &nb= sp;           &nbs= p;   =20
PendingI  Failure to send and=20 (buffer    Store    =20  Open
          = space=20 available or old=20 record  Interim
       &n= bsp; =20 can be overwritten)=20 and        Record
  =        =20 realtime not equal = to
         =20 DELIVER_AND_GRANT 
 
PendingI  Failure to send = and no=20 buffer           &= nbsp;=20 Open
          space = available=20 and realtime  =20
          equal to=20 GRANT_AND_LOSE      =20
           &nb= sp;          =20
PendingI  Failure to send and no buffer  Disconnect=20 Idle
          space = available=20 and realtime  =20 user/dev
          not = equal to=20 GRANT_AND_LOSE 
 
PendingB  Successful = accounting=20 answer   Delete    =20 Idle
         =20 received           = ;           =20 record
PendingB  Failure to=20 send           &nb= sp;           &nbs= p;  =20 Idle
 
Jari
 
[1] = http://www.merit.edu/mail.archives/aaa-wg/2001-12/msg00000.html<= /FONT>
 
----- Original Message ----- =
From: <john.loughney@nokia.com>
To: <aaa-wg@merit.edu>
Sent: 26. helmikuuta 2002=20 22:45
Subject: [AAA-WG]: Issue 252: = Granting=20 Access via Accounting

Hi all,

Just to be sure I've got = it, should the=20 following be removed
from 8.2  Accounting Session State=20 Machine.

Pending   Successful=20 accounting         =20 grant     =20 Open
          start = answer=20 received          = access

or=20 ??

John

Issue 252: Granting Access via Accounting =
Submitter=20 name: Bernard Aboba aboba@internaut.com
Submitter email address: aboba@internaut.com
Date=20 first submitted: 28-Dec-01
Reference:
Document: base 08 =
Comment=20 type: Technical
Priority: S
Section: 8.2 =
Rationale/Explanation of=20 issue:
Access is not granted based on receipt of a successful =
accounting=20 start answer

Change:
In the state table on pp. 86, it states = that in=20 Pending state, receipt of
a Successful accounting start answer = results in=20 "grant access" and
movement to the Open state. Since access is = granted=20 within the
authentication/authorization state machine, this appears = to be an=20 error. ------=_NextPart_000_00D7_01C1C0A2.BAD8F460-- From owner-aaa-wg@merit.edu Thu Feb 28 14:59:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16326 for ; Thu, 28 Feb 2002 14:59:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 5A1709135B; Thu, 28 Feb 2002 14:59:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F4159135C; Thu, 28 Feb 2002 14:59:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 382299135B for ; Thu, 28 Feb 2002 14:59:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AEBB5DDE9; Thu, 28 Feb 2002 14:59:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 42D475DDD6 for ; Thu, 28 Feb 2002 14:59:01 -0500 (EST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228195858.QEJT27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 21:58:58 +0200 Message-ID: <00f801c1c092$5d846340$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22AA4@esebe004.NOE.Nokia.com> <00da01c1c091$f7795740$8a1b6e0a@arenanet.fi> Subject: Re: [AAA-WG]: Issue 252: Granting Access via Accounting Date: Thu, 28 Feb 2002 21:59:00 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F5_01C1C0A3.20ED2820" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00F5_01C1C0A3.20ED2820 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sigh, forgot to remove 'grant access'. Retry: Idle Client or device requests send PendingS access accounting start req. Idle Accounting start request send Open received, and successfully accounting processed. start answer Idle Client or device requests send PendingE a one-time service accounting event req Idle Accounting event request send Idle received, and successfully accounting processed. event answer Idle Records in storage Send PendingB record Open Receive Interim Record send Open accounting answer Open User service terminated send PendingL accounting stop req. Open Accounting stop request send Idle received, and successfully accounting processed stop answer PendingL Successful accounting Idle stop answer received =20 PendingL Failure to send and buffer Store Idle space available Stop Record =20 PendingL Failure to send and no buffer Idle space available =20 PendingE Successful accounting Idle event answer received =20 PendingE Failure to send and buffer Store Idle space available Event Record =20 PendingE Failure to send and no buffer Idle space available =20 PendingS Successful accounting Open start answer received =20 =20 PendingS Failure to send and buffer Store Open space available and realtime Start not equal to DELIVER_AND_GRANT Record PendingS Failure to send and no buffer Open space available and realtime =20 equal to GRANT_AND_LOSE =20 =20 PendingS Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE =20 =20 PendingI Failure to send and (buffer Store Open space available or old record Interim can be overwritten) and Record realtime not equal to DELIVER_AND_GRANT =20 PendingI Failure to send and no buffer Open space available and realtime =20 equal to GRANT_AND_LOSE =20 =20 PendingI Failure to send and no buffer Disconnect Idle space available and realtime user/dev not equal to GRANT_AND_LOSE =20 PendingB Successful accounting answer Delete Idle received record PendingB Failure to send Idle ------=_NextPart_000_00F5_01C1C0A3.20ED2820 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sigh, forgot to remove 'grant access'. = Retry:
 
Idle      Client=20 or device requests     =20 send      =20 PendingS
         =20 access           &= nbsp;           &n= bsp;=20 accounting
          = ;            =             &= nbsp;     =20 start req.

Idle      Accounting start=20 request      =20 send      =20 Open
          received, = and=20 successfully    =20 accounting
        =20  processed.         &nb= sp;          =20 start
          &nbs= p;            = ;            =      =20 answer
Idle      Client=20 or device requests     =20 send      =20 PendingE
          a = one-time=20 service           =  =20 accounting
          = ;=20             &= nbsp;           &n= bsp;    =20 event req
 
Idle     =20 Accounting event request      =20 send      =20 Idle
          received, = and=20 successfully     accounting
         =20 processed.          &nb= sp;         =20 event
          &nbs= p;            = ;            =       answer
 
Idle      Records=20 in=20 storage           =  =20 Send      =20 PendingB
          &= nbsp;           &n= bsp;           &nb= sp;     =20 record

Open      = Receive Interim=20 Record        =20 send      =20 Open
           = ;            =             &= nbsp;    =20 accounting
          = ;            =             &= nbsp;     =20 answer

Open      User service=20 terminated       =20 send       PendingL
  &nb= sp;           &nbs= p;            = ;            =  =20 accounting
          = ;            =             &= nbsp;     =20 stop req.

Open      Accounting stop=20 request       =20 send      =20 Idle
          received, = and=20 successfully    =20 accounting
         =20 processed          &nbs= p;          =20 stop answer

PendingL  Successful=20 accounting          &nb= sp;     =20    =20 Idle
          stop = answer=20 received           =
PendingL  Failure to send and buffer    =20 Store     =20 Idle
          space=20 available          &nbs= p;     Stop
     &nb= sp;           &nbs= p;            = ;          =20 Record
          &nb= sp;           &nbs= p;=20
PendingL  Failure to send and no=20 buffer           &= nbsp;=20 Idle
          space=20 available    
PendingE  Successful=20 accounting          &nb= sp;   =20      =20 Idle
          event= answer=20 received          =
 
PendingE  Failure to send = and=20 buffer     Store     =20 Idle
          space=20 available          &nbs= p;    =20 Event
          &nbs= p;            = ;            =      =20 Record
          &nb= sp;           &nbs= p;=20
PendingE  Failure to send and no=20 buffer           &= nbsp;=20 Idle
          space=20 available    
PendingS  Successful=20 accounting          &nb= sp;   =20      =20 Open
          start= answer=20 received           = ;
           &n= bsp;           &nb= sp; =20
PendingS  Failure to send and buffer    =20 Store     =20 Open
          space = available=20 and realtime  =20 Start
          not = equal to=20 DELIVER_AND_GRANT Record
 
PendingS  Failure to send = and no=20 buffer           &= nbsp;=20 Open
          space = available=20 and realtime  =20
          equal to=20 GRANT_AND_LOSE      =20
           &nb= sp;          =20
PendingS  Failure to send and no buffer  Disconnect=20 Idle
          space = available=20 and realtime  =20 user/dev
          not = equal=20 to
         =20 GRANT_AND_LOSE          = ;            =             &= nbsp;         =20
           &nb= sp;           &nbs= p;   =20
PendingI  Failure to send and=20 (buffer    Store    =20  Open
          = space=20 available or old=20 record  Interim
       &n= bsp; =20 can be overwritten)=20 and        Record
  =        =20 realtime not equal = to
         =20 DELIVER_AND_GRANT 
 
PendingI  Failure to send = and no=20 buffer           &= nbsp;=20 Open
          space = available=20 and realtime  =20
          equal to=20 GRANT_AND_LOSE      =20
           &nb= sp;          =20
PendingI  Failure to send and no buffer  Disconnect=20 Idle
          space = available=20 and realtime  =20 user/dev
          not = equal to=20 GRANT_AND_LOSE 
 
PendingB  Successful = accounting=20 answer   Delete    =20 Idle
         =20 received           = ;           =20 record
PendingB  Failure to=20 send           &nb= sp;           &nbs= p;  =20 Idle
 
------=_NextPart_000_00F5_01C1C0A3.20ED2820-- From owner-aaa-wg@merit.edu Thu Feb 28 15:32:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18305 for ; Thu, 28 Feb 2002 15:32:50 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8BBB591362; Thu, 28 Feb 2002 15:32:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3DBB691361; Thu, 28 Feb 2002 15:32:31 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 336FD9135C for ; Thu, 28 Feb 2002 15:32:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1067D5DDFF; Thu, 28 Feb 2002 15:32:29 -0500 (EST) 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 D16175DDE7 for ; Thu, 28 Feb 2002 15:32:28 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D254D6A905; Thu, 28 Feb 2002 22:32:27 +0200 (EET) Message-ID: <3C7E9146.7040803@kolumbus.fi> Date: Thu, 28 Feb 2002 22:21:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed References: <0AA9E01B31168E42A308714A6EF27184211FF0@trebe002.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok so for the most part 271 solves 272 issues as well. (271 also does some additional things, such as handle the buffering of acct messages.) As for the spontanous updating, I think the intent at least of the spec has been that the base provides you exactly one mandatory situation to update: the interim production per the interval. When - not if - there is a need to have updates at other situations, the design allows for a new AVP to be designed in a specific application document. This AVP could be sent by the accounting server in the start answer to instruct the client to produce accounting interim records in some application specific way, e.g. every time the QoS of a link is modified. This would enable you to provide spontaneous records, for instance, by having the accounting server indicate in the start answer that by Accounting-Spontaneous AVP. The part about the semantics of your specific proposal e.g. more credit is needed -- I think that too can be handled by an application specific AVPs in the accounting requests. (Note that when the first application is designed that does this, it is perfectly OK for other apps to refer to these AVPs and require their use, so work doesn't have to be duplicated.) In conclusion I think 271 solution is sufficient for base, and the approach outlined above can be provided in a new apps document. However, we discussed modifying 271 proposed text to allow the acct server control the realtime flag. I propose modifying start of 9.8.x by adding " or in the Accounting-Answer from the accounting server" just before the first ".". Jari juha-pekka.koskinen@nokia.com wrote: > Hi, > > The 272 includes also one item which has not been discussed yet. > Among the new Accounting-Record-Type(s) introduced in 272 > there is also value for record which could be used when spontaneous > updating (from client to server) of ongoing acc session is needed. > I think this is also needed even in basic acc sessions. > > How/should this be included in base? > > Anyway, I think that basic idea of 271 and this > updating_possibility_from _client_to_server > are both needed. > > br, > JPK > > > -------- inc. -------------------- > >>UPDATE_PREPAID 7 >> An Accounting Update Prepaid record is used to indicate >>that a prepaid service will need more credit to continue. It is >>also used when service (client) need to update itself tariff of >>the ongoing accounting session. This record contains all >>information that is relevant to determine cost of the service and >>granted threshold. From owner-aaa-wg@merit.edu Thu Feb 28 15:33:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18345 for ; Thu, 28 Feb 2002 15:33:14 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id F145E9135E; Thu, 28 Feb 2002 15:32:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72D259135C; Thu, 28 Feb 2002 15:32:32 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 97F7E9135E for ; Thu, 28 Feb 2002 15:32:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B8925DDFF; Thu, 28 Feb 2002 15:32:29 -0500 (EST) 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 34B265DDE7 for ; Thu, 28 Feb 2002 15:32:29 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6C34D6A901; Thu, 28 Feb 2002 22:32:28 +0200 (EET) Message-ID: <3C7E91E5.4090002@kolumbus.fi> Date: Thu, 28 Feb 2002 22:24:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Harri Hakala (LMF)" Cc: "'juha-pekka.koskinen@nokia.com'" , john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed References: <0154633DAF7BD4119C360002A513AA0301F94747@efijont102> 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 Harri Hakala (LMF) wrote: > Hi, > > I agree with Jukka-Pekka that the spontaneous > updating (from client to server) would be helpful. > There are events in the client side that needs to be > reported before the Accounting-Interim-Interval expires. > These events might contain information which affects the > current rating of the service. I agree, but I don't have any generic way of describing when to send such records, hence I think this should be left to applications documents. By the way, I think INTERIM_RECORD is quite fine for this purpose as well -- we don't need new record types, we need new triggers to send INTERIM_RECORDs. Jari From owner-aaa-wg@merit.edu Thu Feb 28 15:33:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18369 for ; Thu, 28 Feb 2002 15:33:27 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 59BAF9135C; Thu, 28 Feb 2002 15:32:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 517F491363; Thu, 28 Feb 2002 15:32:34 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C42E91360 for ; Thu, 28 Feb 2002 15:32:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC1C95DDFF; Thu, 28 Feb 2002 15:32:29 -0500 (EST) 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 A8DC15DDE7 for ; Thu, 28 Feb 2002 15:32:29 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E76FC6A906; Thu, 28 Feb 2002 22:32:28 +0200 (EET) Message-ID: <3C7E92D7.5080706@kolumbus.fi> Date: Thu, 28 Feb 2002 22:28:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: juha-pekka.koskinen@nokia.com Cc: Harri.Hakala@lmf.ericsson.se, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 271: comments needed References: <0AA9E01B31168E42A308714A6EF27184211FF1@trebe002.NOE.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 juha-pekka.koskinen@nokia.com wrote: > I simply mean that threshold is some value (e.g. Interim-Interval > in seconds in basic cases) which client can decrease before the new > ACR must be sent. The type of the threshold could be anything > as long as it is measurable and understanable to client (and server). Exactly, and this confirms what I just said to Harri about INTERIM_RECORD being suitable for this new purpose and just new triggers are needed. So, if in your application the generic periodic update is not sufficient, you can define a new update trigger. For instance, Accounting-Interim-Chicken-Interval AVP defines the interval as the number of eggs a chicken may have produced before an INTERIM_RECORD must be sent. Jari From owner-aaa-wg@merit.edu Thu Feb 28 15:38:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18542 for ; Thu, 28 Feb 2002 15:38:40 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 3503D91361; Thu, 28 Feb 2002 15:38:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F258D91367; Thu, 28 Feb 2002 15:38:00 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4356D91361 for ; Thu, 28 Feb 2002 15:37:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 201155DDFF; Thu, 28 Feb 2002 15:37:57 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 60B825DDD6 for ; Thu, 28 Feb 2002 15:37:56 -0500 (EST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SKc4Z23099 for ; Thu, 28 Feb 2002 22:38:04 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 22:37:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 22:37:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 271: comments needed Date: Thu, 28 Feb 2002 22:37:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A94@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Issue 271: comments needed Thread-Index: AcHAlwq3CkLExfHdTJaMMVPag5qQSAAAFTsA From: To: Cc: X-OriginalArrivalTime: 28 Feb 2002 20:37:55.0342 (UTC) FILETIME=[CCE7C2E0:01C1C097] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18542 Jari, So the text to be added is adding to: 6.12 Redirect-Host-Usage AVP The following: UPDATE_PREPAID 7 An Accounting Update Prepaid record is used to indicate that a prepaid service will need more credit to continue. It is also used when service (client) need to update itself tariff of the ongoing accounting session. This record contains all information that is relevant to determine cost of the service and granted threshold. and modifying start of 9.8.x by adding " or in the Accounting-Answer from the accounting server" just before the first ".". Is that it? John > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 28 February, 2002 22:21 > To: Koskinen Juha-Pekka (NET/Tampere) > Cc: Loughney John (NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Issue 271: comments needed > > > Ok so for the most part 271 solves 272 issues as well. > (271 also does some additional things, such as handle the > buffering of acct messages.) > > As for the spontanous updating, I think the intent at least > of the spec has been that the base provides you exactly one > mandatory situation to update: the interim production per > the interval. When - not if - there is a need to have updates > at other situations, the design allows for a new AVP to be > designed in a specific application document. This AVP could > be sent by the accounting server in the start answer to > instruct the client to produce accounting interim records > in some application specific way, e.g. every time the QoS > of a link is modified. This would enable you to provide > spontaneous records, for instance, by having the accounting > server indicate in the start answer that by Accounting-Spontaneous > AVP. The part about the semantics of your specific proposal e.g. > more credit is needed -- I think that too can be handled by > an application specific AVPs in the accounting requests. (Note > that when the first application is designed that does this, > it is perfectly OK for other apps to refer to these AVPs and > require their use, so work doesn't have to be duplicated.) > > In conclusion I think 271 solution is sufficient for base, and > the approach outlined above can be provided in a new apps document. > However, we discussed modifying 271 proposed text to allow the > acct server control the realtime flag. I propose modifying > start of 9.8.x by adding " or in the Accounting-Answer from > the accounting server" just before the first ".". > > Jari > > juha-pekka.koskinen@nokia.com wrote: > > > Hi, > > > > The 272 includes also one item which has not been discussed yet. > > Among the new Accounting-Record-Type(s) introduced in 272 > > there is also value for record which could be used when spontaneous > > updating (from client to server) of ongoing acc session is needed. > > I think this is also needed even in basic acc sessions. > > > > How/should this be included in base? > > > > Anyway, I think that basic idea of 271 and this > > updating_possibility_from _client_to_server > > are both needed. > > > > br, > > JPK > > > > > > -------- inc. -------------------- > > > >>UPDATE_PREPAID 7 > >> An Accounting Update Prepaid record is used to indicate > >>that a prepaid service will need more credit to continue. It is > >>also used when service (client) need to update itself tariff of > >>the ongoing accounting session. This record contains all > >>information that is relevant to determine cost of the service and > >>granted threshold. > > > > > > From owner-aaa-wg@merit.edu Thu Feb 28 15:49:18 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19004 for ; Thu, 28 Feb 2002 15:49:17 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id D59CB91367; Thu, 28 Feb 2002 15:45:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD5EA91368; Thu, 28 Feb 2002 15:45:51 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F69591367 for ; Thu, 28 Feb 2002 15:45:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0420C5DDFF; Thu, 28 Feb 2002 15:45:47 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 21ABA5DDD6 for ; Thu, 28 Feb 2002 15:45:46 -0500 (EST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228204545.QKCS27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 22:45:45 +0200 Message-ID: <017401c1c098$e69263c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: Cc: References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A94@esebe004.NOE.Nokia.com> Subject: Re: [AAA-WG]: Issue 271: comments needed Date: Thu, 28 Feb 2002 22:45:47 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 6.12 Redirect-Host-Usage AVP > UPDATE_PREPAID 7 Uh... I think not. Wrong AVP first of all, I think the folks meant Accounting-Record-Type. Secondly, I was trying to argue that we don't need UPDATE_PREPAID in the base... > modifying start of 9.8.x by adding " or in the Accounting-Answer from > the accounting server" just before the first ".". Do that, and incorporate changes from 271 as they are listed in the issues file. Except for the state machine, which I sent in separately. I will take one more look at another e-mail around the prepaid issues and verify what I said above about the need for UPDATE_ PREPAID. Jari From owner-aaa-wg@merit.edu Thu Feb 28 16:16:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20108 for ; Thu, 28 Feb 2002 16:16:36 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id EBBC691365; Thu, 28 Feb 2002 16:15:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4C4F091369; Thu, 28 Feb 2002 16:15:26 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7020F91365 for ; Thu, 28 Feb 2002 16:15:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3EBF15DDDB; Thu, 28 Feb 2002 16:15:24 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 28D235DDD6 for ; Thu, 28 Feb 2002 16:15:24 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id CB87E79; Thu, 28 Feb 2002 16:15:23 -0500 (EST) Message-ID: <3C7E9DF1.758D2DD5@Interlinknetworks.com> Date: Thu, 28 Feb 2002 16:15:29 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com Cc: jacques_m_caron@yahoo.com, dzick@Interlinknetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded References: <0C1353ABB1DEB74DB067ADFF749C4EEFA22B5F@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------4944D4462FE6FE6BF9F727D7" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------4944D4462FE6FE6BF9F727D7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I certainly do not want to add text specifying what operators can do. I am only interested in the protocol. In this case, my concern is that you don't over-specify the protocol in such a way as to unnecessarily limit an operator's options. What I do request is that if there is no protocol requirement to resolve the fqdn, then you should relax the requirement and specify that it "contains the fqdn of the Diameter node" rather than that it "is the fqdn of the Diameter node". Then operators can do what they want. john.loughney@nokia.com wrote: > > Hi Jacques & David, > > I agree with Jacques. David, if you can carefully craft > text that fits your exact meaning, please do so. Otherwise > lets leave the text as fqdn & if needed, provide additional > details in a BCP doc or something, as we are getting into > operation details. > > John > > > -----Original Message----- > > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > Sent: 28 February, 2002 02:56 > > To: David Spence > > Cc: Loughney John (NRC/Helsinki); dzick@Interlinknetworks.com; > > aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded > > > > > > Then you're really adding something to the "real" FQDN that > > is functionally > > equivalent to a port number :-) > > > > If you manage to write some text that explains that clearly and > > unambiguously, why not. But I think it's easier to stick to > > "real" FQDNs. > > It's never hurt anyone to register a couple of addresses in the DNS. > > > > As an alternative, if the Identity is considered fully > > opaque, nothing > > prevents us to change it to FQDN;. Where > > may be a PID, a port number, a > > configuration > > file path name, or any other arbitrary string. > > > > Jacques. > > > > At 01:12 28/02/2002, David Spence wrote: > > >Actually, my idea was that the portion of the identity > > string following the > > >first dot would be a real host name registered to the host > > on which the > > >server was running. In my example below, both servers were > > running on > > >srv.interlinknetworks.com, which is the real name of the > > host. diam1 and > > >diam2 would be unregistered prefixes to a registered host name. > > > > > >Jacques Caron wrote: > > > > > > > > Even though the full name need not necessarily be in the > > DNS (though this > > > > might have other consequences?), it is necessary that it > > is based on a > > > > domain name that is registered and owned by the > > administrator of the > > > > server. Otherwise we'll end up with a bunch of > > "diameter.example.com" all > > > > over which are definitely not unique :-( > > > > > > > > I think it's easier if the fqdn is really registered, > > just for the purposes > > > > of ensuring uniqueness. > > > > > > > > Jacques. > > > > > > > > At 22:59 27/02/2002, David Spence wrote: > > > > >One question: Does it make any difference whether there > > is an A record for > > > > >the fqdn in the DNS, i.e., does the fqdn actually need to be > > > registered? I > > > > >think not. And if it doesn't, that makes it easier for > > administrators. > > > > >Suppose I run two Diameter servers on > > srv.interlinknetworks.com. Then I > > > > >could configure one to call itself > > diam1.srv.interlinknetworks.com, and I > > > > >could configue the other to call itself > > diam2.srv.interlinknetworks.com. > > > > >Voila! I have guaranteed uniqueness without having to > > register a domain > > > > >name. If this is agreeable, it might be worth stating > > in the draft > > > that the > > > > >term fqdn does not imply that the name be registered, > > only that it be > > > > >unique. > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > _________________________________________________________ > > > > Do You Yahoo!? > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > --------------4944D4462FE6FE6BF9F727D7 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------4944D4462FE6FE6BF9F727D7-- From owner-aaa-wg@merit.edu Thu Feb 28 16:17:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20164 for ; Thu, 28 Feb 2002 16:17:55 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id A334191369; Thu, 28 Feb 2002 16:17:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53DE69136A; Thu, 28 Feb 2002 16:17:09 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5A9891369 for ; Thu, 28 Feb 2002 16:17:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7112B5DDD6; Thu, 28 Feb 2002 16:17:05 -0500 (EST) 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 A7EC85DDDB for ; Thu, 28 Feb 2002 16:17:04 -0500 (EST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SLGT310976 for ; Thu, 28 Feb 2002 23:16:29 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 23:17:02 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 28 Feb 2002 23:17:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: [issue] AAA URI is Overloaded Date: Thu, 28 Feb 2002 23:17:02 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A9E@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: [issue] AAA URI is Overloaded Thread-Index: AcHAnQp8AitXukdCRya7o1SbJvSjIwAAC7ow From: To: Cc: , , X-OriginalArrivalTime: 28 Feb 2002 21:17:02.0780 (UTC) FILETIME=[44165FC0:01C1C09D] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA20164 Hi David, I think the change works for me. John > -----Original Message----- > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: 28 February, 2002 23:15 > To: Loughney John (NRC/Helsinki) > Cc: jacques_m_caron@yahoo.com; dzick@Interlinknetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded > > > I certainly do not want to add text specifying what operators > can do. I am > only interested in the protocol. In this case, my concern is > that you don't > over-specify the protocol in such a way as to unnecessarily limit an > operator's options. What I do request is that if there is no protocol > requirement to resolve the fqdn, then you should relax the > requirement and > specify that it "contains the fqdn of the Diameter node" > rather than that it > "is the fqdn of the Diameter node". Then operators can do > what they want. > > john.loughney@nokia.com wrote: > > > > Hi Jacques & David, > > > > I agree with Jacques. David, if you can carefully craft > > text that fits your exact meaning, please do so. Otherwise > > lets leave the text as fqdn & if needed, provide additional > > details in a BCP doc or something, as we are getting into > > operation details. > > > > John > > > > > -----Original Message----- > > > From: ext Jacques Caron [mailto:jacques_m_caron@yahoo.com] > > > Sent: 28 February, 2002 02:56 > > > To: David Spence > > > Cc: Loughney John (NRC/Helsinki); dzick@Interlinknetworks.com; > > > aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: [issue] AAA URI is Overloaded > > > > > > > > > Then you're really adding something to the "real" FQDN that > > > is functionally > > > equivalent to a port number :-) > > > > > > If you manage to write some text that explains that clearly and > > > unambiguously, why not. But I think it's easier to stick to > > > "real" FQDNs. > > > It's never hurt anyone to register a couple of addresses > in the DNS. > > > > > > As an alternative, if the Identity is considered fully > > > opaque, nothing > > > prevents us to change it to FQDN; host>. Where > > > may be a PID, a port number, a > > > configuration > > > file path name, or any other arbitrary string. > > > > > > Jacques. > > > > > > At 01:12 28/02/2002, David Spence wrote: > > > >Actually, my idea was that the portion of the identity > > > string following the > > > >first dot would be a real host name registered to the host > > > on which the > > > >server was running. In my example below, both servers were > > > running on > > > >srv.interlinknetworks.com, which is the real name of the > > > host. diam1 and > > > >diam2 would be unregistered prefixes to a registered host name. > > > > > > > >Jacques Caron wrote: > > > > > > > > > > Even though the full name need not necessarily be in the > > > DNS (though this > > > > > might have other consequences?), it is necessary that it > > > is based on a > > > > > domain name that is registered and owned by the > > > administrator of the > > > > > server. Otherwise we'll end up with a bunch of > > > "diameter.example.com" all > > > > > over which are definitely not unique :-( > > > > > > > > > > I think it's easier if the fqdn is really registered, > > > just for the purposes > > > > > of ensuring uniqueness. > > > > > > > > > > Jacques. > > > > > > > > > > At 22:59 27/02/2002, David Spence wrote: > > > > > >One question: Does it make any difference whether there > > > is an A record for > > > > > >the fqdn in the DNS, i.e., does the fqdn actually need to be > > > > registered? I > > > > > >think not. And if it doesn't, that makes it easier for > > > administrators. > > > > > >Suppose I run two Diameter servers on > > > srv.interlinknetworks.com. Then I > > > > > >could configure one to call itself > > > diam1.srv.interlinknetworks.com, and I > > > > > >could configue the other to call itself > > > diam2.srv.interlinknetworks.com. > > > > > >Voila! I have guaranteed uniqueness without having to > > > register a domain > > > > > >name. If this is agreeable, it might be worth stating > > > in the draft > > > > that the > > > > > >term fqdn does not imply that the name be registered, > > > only that it be > > > > > >unique. > > > > > > > > > > _________________________________________________________ > > > > > Do You Yahoo!? > > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > _________________________________________________________ > > > > > > Do You Yahoo!? > > > > > > Get your free @yahoo.com address at http://mail.yahoo.com > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Thu Feb 28 16:29:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20614 for ; Thu, 28 Feb 2002 16:29:51 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B9EBF9136F; Thu, 28 Feb 2002 16:27:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 813CA9136E; Thu, 28 Feb 2002 16:27:41 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EB129136A for ; Thu, 28 Feb 2002 16:27:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 013C35DDDB; Thu, 28 Feb 2002 16:27:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by segue.merit.edu (Postfix) with ESMTP id 2F7895DDD6 for ; Thu, 28 Feb 2002 16:27:38 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep03-svc.swip.net with ESMTP id <20020228212724.CDKT16920.fep03-svc.swip.net@ipunplugged.com> for ; Thu, 28 Feb 2002 22:27:24 +0100 Message-ID: <3C7EAEF5.9070904@ipunplugged.com> Date: Thu, 28 Feb 2002 22:28:05 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg Subject: [AAA-WG]: Accounting fault resilience Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, All. I'm wondering what the requirements on the client sending records when recovering from a fail-over is. Section 9.4 states (I think - keeping up with changes is difficult these days); Upon a reboot, the client MUST starting sending the records in the non-volatile memory to the accounting server with appropriate modifications in termination cause, session length, and other relevant information in the records. What information may change? I am mostly thinking about: 1. What should the record type be? If we limit ourselves to the ones in draft-8, is it ok to just send a STOP_RECORD. Could a session, now obviously long gone, be compressed into a single EVENT_RECORD? A single STOP_RECORD? Would it be necessary to first send a START_RECORD if no record was ever acked? 2. What if any session ids need to be maintained? Is it sufficient if the user can be identified? A Diameter client may among other things be a gateway from other AAA protocols, most probably some form of RADIUS, where the original device may be storing its own records non-volatilely and may wish to resend them on recovery. Can the Diameter client know what ids to use in such a case without storing *all* accounting session states for arbitrary amounts of time? j From owner-aaa-wg@merit.edu Thu Feb 28 16:33:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20940 for ; Thu, 28 Feb 2002 16:33:52 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AEA129136E; Thu, 28 Feb 2002 16:33:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3844991370; Thu, 28 Feb 2002 16:33:37 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 146DF9136E for ; Thu, 28 Feb 2002 16:33:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id EE5415DDDB; Thu, 28 Feb 2002 16:33:35 -0500 (EST) 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 BC3FE5DDD6 for ; Thu, 28 Feb 2002 16:33:35 -0500 (EST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CD60C6A904; Thu, 28 Feb 2002 23:33:34 +0200 (EET) Message-ID: <3C7EA220.5020508@kolumbus.fi> Date: Thu, 28 Feb 2002 23:33:20 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: aaa-wg@merit.edu, john.loughney@nokia.com Subject: Re: [AAA-WG]: Request for closure on issue 235 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, so after watching the mailing list discussion and having wondered about this for a while also in a conference call with the authors yesterday... and my proposed secondary method... I think we are not going to get consensus for this. Instead, we should add some text in the Base that discusses duplicate elimination. Some of the comments said that the method does not work. Maybe we could have finally agreed that it does work, because it does appear to work, at least my analysis said so. But even so, two concerns have been raised that are harder to agree on: 1) true benefit of the RAM check vs. the index check and 2) behaviour in reboot, RADIUS interoperability etc. situations. All is not lost however, for the D-bit forever. Specific applications *can* introduce an AVP for the same purpose, if they like. However, I hope the new text builds some understanding of the issues as well so extension designers and implementors can take a wider understanding of the issue. If my proposed scheme works -- I'm not 100% sure -- I would think that would be preferred, though. Here's the proposed text. Add a reference in 9.4 to a new appendix B 'Appendix B discusses duplicate detection need and implementation issues.' Then, Appendix B: As described in section 9.4, accounting record duplicate detection is based on the session identifiers. Duplicates can appear for various reasons: - Failover to an alternate server. Where we close to real-time performance is expected, failover tresholds need to be kept low and this may lead to a relatively large likelihood of duplicates. - A crash of a client at the time it just had managed to send a record from a non-volatile memory would likely cause the same record to be sent soon after the client has rebooted. - Duplicates received from RADIUS gateways. - Implementation problems and misconfiguration. In some cases the Diameter accounting server can delay the duplicate detection and accounting record processing until a post-processing phase takes place. At that time records are likely to be sorted according to the User-Name contained in them and duplicate elimination is easy in this case. In other situations it may be necessary to perform real-time duplicate detection, e.g. when the credit limits or fraud attempts are being monitored in real time. In general, only the duplicate generation at failover case is something that can be reliably detected by the Diameter client. The Diameter server is therefore responsible for the duplicate detection process. When real-time duplicate detection is required, this implies a database-like search functionality to find duplicate records. Implementors are advised, however, that there exists ways to avoid expensive all-record searches. For instance, it can be usually safely assumed that duplicates appear within a time window of longest imaginable network partition, perhaps a day as an example. So only records within this time window need to be looked at. Secondly, hashing techniques or other schemes may be used to eliminate the need to do a full search even in this set except for rare cases. From owner-aaa-wg@merit.edu Thu Feb 28 16:42:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21297 for ; Thu, 28 Feb 2002 16:42:02 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 713BA91371; Thu, 28 Feb 2002 16:41:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4461291372; Thu, 28 Feb 2002 16:41:47 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4724D91371 for ; Thu, 28 Feb 2002 16:41:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2823C5DDDB; Thu, 28 Feb 2002 16:41:46 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 764135DDD6 for ; Thu, 28 Feb 2002 16:41:45 -0500 (EST) Received: from jariws1 ([62.248.152.76]) by fep02-app.kolumbus.fi with SMTP id <20020228214140.QQAY27811.fep02-app.kolumbus.fi@jariws1>; Thu, 28 Feb 2002 23:41:40 +0200 Message-ID: <01ec01c1c0a0$b6e759c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Johan Johansson" , "aaa-wg" Cc: References: <3C7EAEF5.9070904@ipunplugged.com> Subject: Re: [AAA-WG]: Accounting fault resilience Date: Thu, 28 Feb 2002 23:41:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Upon a reboot, > the client MUST starting sending the records in the non-volatile > memory to the accounting server with appropriate modifications in > termination cause, session length, and other relevant information in > the records. > > What information may change? I am mostly thinking about: > > 1. What should the record type be? If we limit ourselves to the ones in > draft-8, is it ok to just send a STOP_RECORD. Could a session, now > obviously long gone, be compressed into a single EVENT_RECORD? A single > STOP_RECORD? Would it be necessary to first send a START_RECORD if no > record was ever acked? > > 2. What if any session ids need to be maintained? Is it sufficient if > the user can be identified? A Diameter client may among other things be > a gateway from other AAA protocols, most probably some form of RADIUS, > where the original device may be storing its own records non-volatilely > and may wish to resend them on recovery. Can the Diameter client know > what ids to use in such a case without storing *all* accounting session > states for arbitrary amounts of time? I'm thinking that we should do any of the very complicated things. It is still possible for the a device to crash and lose it's memory completely. So servers must be able to deal with a missing Stop record, for instance. But I see that the text may not be clear enough to make this obvious. How about: Upon a reboot, the client MUST starting sending the records in the non-volatile memory to the accounting server with appropriate modifications in termination cause, session length, and possibly other relevant, application specific information in the records. The client MUST not modify the Accounting-Record-Type or other basic information in the records, or try to reconstruct STOP_RECORDs. Jari From owner-aaa-wg@merit.edu Thu Feb 28 16:51:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21609 for ; Thu, 28 Feb 2002 16:51:24 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 394549120E; Thu, 28 Feb 2002 16:51:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 093B291372; Thu, 28 Feb 2002 16:51:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 04FF39120E for ; Thu, 28 Feb 2002 16:51:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id ABE3A5DDFC; Thu, 28 Feb 2002 16:51:12 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by segue.merit.edu (Postfix) with ESMTP id 0ACD85DDD6 for ; Thu, 28 Feb 2002 16:51:12 -0500 (EST) Received: from ipunplugged.com ([213.100.60.212]) by fep04-svc.swip.net with ESMTP id <20020228215010.CDVE27837.fep04-svc.swip.net@ipunplugged.com>; Thu, 28 Feb 2002 22:50:10 +0100 Message-ID: <3C7EB44C.7010706@ipunplugged.com> Date: Thu, 28 Feb 2002 22:50:52 +0000 From: Johan Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Jari Arkko Cc: aaa-wg , john.loughney@nokia.com Subject: Re: [AAA-WG]: Accounting fault resilience References: <3C7EAEF5.9070904@ipunplugged.com> <01ec01c1c0a0$b6e759c0$8a1b6e0a@arenanet.fi> 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 Jari Arkko wrote: >>Upon a reboot, >> the client MUST starting sending the records in the non-volatile >> memory to the accounting server with appropriate modifications in >> termination cause, session length, and other relevant information in >> the records. >> >>What information may change? I am mostly thinking about: >> >>1. What should the record type be? If we limit ourselves to the ones in >>draft-8, is it ok to just send a STOP_RECORD. Could a session, now >>obviously long gone, be compressed into a single EVENT_RECORD? A single >>STOP_RECORD? Would it be necessary to first send a START_RECORD if no >>record was ever acked? >> >>2. What if any session ids need to be maintained? Is it sufficient if >>the user can be identified? A Diameter client may among other things be >>a gateway from other AAA protocols, most probably some form of RADIUS, >>where the original device may be storing its own records non-volatilely >>and may wish to resend them on recovery. Can the Diameter client know >>what ids to use in such a case without storing *all* accounting session >>states for arbitrary amounts of time? >> > >I'm thinking that we should do any of the very complicated things. It >is still possible for the a device to crash and lose it's memory >completely. So servers must be able to deal with a missing Stop >record, for instance. > >But I see that the text may not be clear enough to make this >obvious. How about: > > Upon a reboot, > the client MUST starting sending the records in the non-volatile > memory to the accounting server with appropriate modifications in > termination cause, session length, and possibly other relevant, > application specific information in > the records. The client MUST not modify the Accounting-Record-Type > or other basic information in the records, or try to reconstruct > STOP_RECORDs > So the diameter node stores exactly those records that it has had time to receive and stores it complete with record type and the session id, accounting multi session id, sub session id and radius session id (the ones that apply anyway) and recovers properly only from faults in the diameter node but not from faults in the device/process generating the data? This would then by necessity be treated as a new session unless extra effort is applied? j From owner-aaa-wg@merit.edu Thu Feb 28 17:13:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22627 for ; Thu, 28 Feb 2002 17:13:31 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 2F08C91372; Thu, 28 Feb 2002 17:13:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE3B491373; Thu, 28 Feb 2002 17:13:20 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1326D91372 for ; Thu, 28 Feb 2002 17:13:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id EA8A45DDF1; Thu, 28 Feb 2002 17:13:19 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D54215DDD6 for ; Thu, 28 Feb 2002 17:13:19 -0500 (EST) Received: from Interlinknetworks.com (nat.interlinknetworks.com [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 720B079; Thu, 28 Feb 2002 17:13:19 -0500 (EST) Message-ID: <3C7EAB85.C9689596@Interlinknetworks.com> Date: Thu, 28 Feb 2002 17:13:25 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: tony.johansson@ericsson.com, aaa-wg@merit.edu Cc: john.loughney@nokia.com, pcalhoun@bstormnetworks.com Subject: Re: [AAA-WG]: Issue 285: Accouting AVP issue... References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64A2E@esebe004.NOE.Nokia.com> Content-Type: multipart/mixed; boundary="------------B4D809C723EC555A547304C8" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------B4D809C723EC555A547304C8 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have addressed this issue in the following way in nasreq. Let me know if you have any disagreements with this. I have left the accounting AVPs shared with mip in the nasreq draft. Wording is now as follows: 8.1 Accounting-Input--Octets AVP | The Accounting-Input-Octets AVP (AVP Code 363) is of type Unsigned64, | and contains the number of octets received from the user. For NASREQ usage, this AVP indicates how many octets have been | received from the port in the course of this session and can only be | present in ACR messages with an Accounting-Record-Type of | INTERIM_RECORD or STOP_RECORD. | 8.2 Accounting-Output-Octets AVP | The Accounting-Output-Octets AVP (AVP Code 364) is of type | Unsigned64, and contains the number of octets sent to the user. | For NASREQ usage, this AVP indicates how many octets have been sent | to the port in the course of this session and can only be present in | ACR messages with an Accounting-Record-Type of INTERIM_RECORD or | STOP_RECORD. 8.3 Acct-Session-Time AVP | The Acct-Session-Time AVP (AVP Code 46) is of type Unsigned32, and | indicates the length of the current session in seconds. It can only | be present in ACR messages with an Accounting-Record-Type of | INTERIM_RECORD or STOP_RECORD. 8.4 Accounting-Input-Packets AVP | The Accounting-Input-Packets (AVP Code 365) is of type Unsigned64, | and contains the number of packets received from the user. | For NASREQ usage, this AVP indicates how many packets have been | received from the port over the course of a session being provided to | a Framed User and can only be present in ACR messages with an | Accounting-Record-Type of INTERIM_RECORD or STOP_RECORD. 8.5 Accounting-Output-Packets AVP | The Accounting-Output-Packets (AVP Code 366) is of type Unsigned64, | and contains the number of IP packets sent to the user. | For NASREQ usage, this AVP indicates how many packets have been sent | to the port over the course of a session being provided to a Framed | User and can only be present in ACR messages with an Accounting- | Record-Type of INTERIM_RECORD or STOP_RECORD. Note that I deleted the word "Extended" from the AVP names. I also renamed Account-Session-Time to Acct-Session-Time for compatibility with RADIUS. I deleted references to IP packets in the count AVPs because nasreq users do not necessarily receive IP services. I added text from RADIUS to maintain RADIUS compatibility. I extended the RFC 2866 notion that these AVPs only appear in stop records by also inlcuding interim records. I did not include EVENT_RECORD in the list because the nasreq draft does not say anything about using this record type. If there is a need for the nasreq application to use this record type then text will have to be added to say so and at that time I will add EVENT_RECORD to these AVPs. I have moved the integer64 AVPs from the table in section 2.2 (Legacy RADIUS Attributes) to the table in section 2.1 (Diameter AVPs). I have numbered them correctly in the 363-366 range. I have made the following changes to the table in section 10.2.2 (Non-Framed Access): +-----------+ | Command | | Code | |-----+-----+ Attribute Name | ACR | ACA | ---------------------------------------|-----+-----+ Accounting-Input-Packets | 0 | 0 | | Accounting-Output-Packets | 0 | 0 | | The numbers had been 1 before. This is for compatibility with RADIUS which states that the packets are counted for users receiving a framed service and that they are counted at the port side (not the network side). john.loughney@nokia.com wrote: > > Hi David, > > > So, after all this rambling, I suggest the following: > > > > 1) Both MIP and NASREQ should define the AVPs. > > > > 2) Both drafts should contain the verbatim text that is now in MIP > > (not the erroneous text that is now in NASREQ). > > > > 3) The NASREQ draft should contain additional NASREQ usage instructions > > copied verbatim from RADIUS except for the part about only being present > > in stop records, which is no longer true.] > > > > 4) The MIP editor may want to consider adding usage instructions as well. > > > > 5) The word Extended should be removed from from the attribute names. The > > difference between the Acct- prefix and the Accounting- prefix can > > distinguish the RADIUS attributes from the Diameter attributes. Also > > the AVP codes are different -- 363-366 for the Diameter AVPs. > > > > 6) The Accounting-Session-Time AVP should be renamed to Acct-Session-Time > > for compatibility with RADIUS because it shares the RADIUS AVP Code of > > 46. > > This works for me (since it seems to imply no changes to the base, which I like ;) > > John --------------B4D809C723EC555A547304C8 Content-Type: text/x-vcard; charset=us-ascii; name="DSpence.vcf" Content-Description: Card for David Spence Content-Disposition: attachment; filename="DSpence.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:; tel;fax:+1 734 821 1235 tel;work:+1 734 821 1203 x-mozilla-html:FALSE url:http://www.interlinknetworks.com org:Interlink Networks, Inc. adr:;;775 Technology Dr., Suite 200;Ann Arbor;MI;48108;USA version:2.1 email;internet:DSpence@Interlinknetworks.com title:Architect fn:David Spence end:vcard --------------B4D809C723EC555A547304C8-- From owner-aaa-wg@merit.edu Thu Feb 28 17:29:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23420 for ; Thu, 28 Feb 2002 17:29:23 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id AAA8991373; Thu, 28 Feb 2002 17:29:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73A6C91374; Thu, 28 Feb 2002 17:29:03 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E8AC91373 for ; Thu, 28 Feb 2002 17:29:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5ED7B5DDFF; Thu, 28 Feb 2002 17:29:02 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 005CE5DDD6 for ; Thu, 28 Feb 2002 17:29:01 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g1SMV0x02365 for ; Thu, 28 Feb 2002 16:31:01 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 28 Feb 2002 16:28:54 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 28 Feb 2002 16:27:31 -0600 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Request for closure on issue 235 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Thu, 28 Feb 2002 16:27:30 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44A128A4@daebe007.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcHAn562R/53qJ96SKWCFBfdQatGIAAB207w From: To: , , X-OriginalArrivalTime: 28 Feb 2002 22:27:31.0295 (UTC) FILETIME=[1C7A8EF0:01C1C0A7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA23420 Jari Arkko [jari.arkko@kolumbus.fi] wrote: >Ok, so after watching the mailing list discussion and having wondered >about this for a while also in a conference call with the authors >yesterday... and my proposed secondary method... I think we are not >going to get consensus for this. Instead, we should add some text in >the Base that discusses duplicate elimination. > I believe the "D" bit method for duplicate checking is quite simple and hence surprised that no concensus could be reached. The "D" bit would be quite useful in scenarios where real-time (or near RT) accounting is required. But I have made all these arguments previously as well. So.... >Some of the comments said that the method does not work. Maybe >we could have finally agreed that it does work, because it does appear >to work, at least my analysis said so. But even so, two concerns have >been raised that are harder to agree on: > 1) true benefit of the RAM check vs. the index check and There are benefits. > 2) behaviour in reboot, RADIUS interoperability etc. situations. Behavior in reboot can be specified. I cannot say that I have looked at the RADIUS interoperability issue. > >All is not lost however, for the D-bit forever. Specific applications >*can* introduce an AVP for the same purpose, if they like. However, >I hope the new text builds some understanding of the issues as well >so extension designers and implementors can take a wider understanding >of the issue. Well, I hope so, but I am not very optimistic. >If my proposed scheme works -- I'm not 100% sure -- >I would think that would be preferred, though. Well, if you ask me, the "D" bit is preferabble :) -Basavaraj From owner-aaa-wg@merit.edu Thu Feb 28 20:35:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28649 for ; Thu, 28 Feb 2002 20:35:47 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id B2B079137A; Thu, 28 Feb 2002 20:32:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79DA49137C; Thu, 28 Feb 2002 20:32:14 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 343C19137A for ; Thu, 28 Feb 2002 20:31:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1180B5DE15; Thu, 28 Feb 2002 20:31:39 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from tp.databus.com (unknown [66.114.72.186]) by segue.merit.edu (Postfix) with ESMTP id 7F3F55DDB9 for ; Thu, 28 Feb 2002 20:31:38 -0500 (EST) Received: (from barney@localhost) by tp.databus.com (8.11.6/8.11.4) id g211UHw08447 for aaa-wg@merit.edu; Thu, 28 Feb 2002 20:30:17 -0500 (EST) (envelope-from barney) Date: Thu, 28 Feb 2002 20:30:17 -0500 From: Barney Wolff To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Request for closure on issue 235 Message-ID: <20020228203017.A8259@tp.databus.com> References: <697DAA22C5004B4596E033803A7CEF44A12884@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF44A12884@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Thu, Feb 28, 2002 at 10:06:29AM -0600 Sender: owner-aaa-wg@merit.edu Precedence: bulk Is the specification executable? How did I miss this breakthrough? Barney On Thu, Feb 28, 2002 at 10:06:29AM -0600, Basavaraj.Patil@nokia.com wrote: > Receivers could trust the sender if the specification mandates that > the sender mark potential duplicates with the "D" bit. From owner-aaa-wg@merit.edu Thu Feb 28 23:35:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03821 for ; Thu, 28 Feb 2002 23:35:26 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 582909137C; Thu, 28 Feb 2002 23:35:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 232BB9137D; Thu, 28 Feb 2002 23:35:15 -0500 (EST) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D95C9137C for ; Thu, 28 Feb 2002 23:35:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id E8E2A5DDD0; Thu, 28 Feb 2002 23:35:13 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 3E6D15DDB9 for ; Thu, 28 Feb 2002 23:35:13 -0500 (EST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g214ZMZ11324 for ; Fri, 1 Mar 2002 06:35:23 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 1 Mar 2002 06:35:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 06:35:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Iissue 235: Resolution Date: Fri, 1 Mar 2002 06:35:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AAD@esebe004.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Request for closure on issue 235 Thread-Index: AcHAwWYqU2qT30/DQpO9OCaZuFTKXwAGJ5XA From: To: X-OriginalArrivalTime: 01 Mar 2002 04:35:12.0294 (UTC) FILETIME=[79DBDC60:01C1C0DA] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA03821 Hi all, I have not seen consensus supporting this issue. There has been some support, in general, for this topic, but very strong opposition to the method. In that light, I cannot add this to the base specification. John