From owner-aaa-wg@merit.edu Wed Oct 2 02:17: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 CAA28358 for ; Wed, 2 Oct 2002 02:17:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 284CD9122F; Wed, 2 Oct 2002 02:19:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA55691232; Wed, 2 Oct 2002 02:19:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AF60F9122F for ; Wed, 2 Oct 2002 02:19:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 928395DE72; Wed, 2 Oct 2002 02:19:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id CEDB55DE2F for ; Wed, 2 Oct 2002 02:19:08 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g926JlF05915 for ; Wed, 2 Oct 2002 09:19:47 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 2 Oct 2002 09:16:58 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Oct 2002 09:16:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 2 Oct 2002 09:16:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Peer state machine Date: Wed, 2 Oct 2002 09:16:55 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A56B8@esebe004.ntc.nokia.com> Thread-Topic: Peer state machine Thread-Index: AcJki42DjTmIXslgEdatggAADnz2vQFT6fhg From: To: , X-OriginalArrivalTime: 02 Oct 2002 06:16:56.0535 (UTC) FILETIME=[4F155E70:01C269DB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA28358 Hi, Thanks for the text, I agree with your text. I haven't seen any other comments - I will fix the text, as long as there are no other comments. John > -----Original Message----- > From: ext [mailto:Ext-Venkata.Ghadiyaram@nokia.com] > Sent: 25 September, 2002 15:02 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Peer state machine > > > Issue 318:Peer state machine bug > Submitter name: Ghadiyaram Venkata Kishore > Submitter email address: Ext-Venkata.Ghadiyaram@nokia.com, > Date first submitted: September 25, 2002 > Reference: > Document: Base > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue > > In the peer state machine specification in the base protocol > there is a difference in handling R-Conn-CER event when the > state is R-Open and when the state is I-Open. > > R-Open R-Conn-CER R-Snd-CEA R-Open > R-Reject > I-Open R-Conn-CER R-Reject R-Open > > It should not be necessary to send a CEA as the state is > already open on another another connection. The incoming > R_CONN_CER can be just rejected. Moreover if a CEA is to be > sent then which result code should be used by the CEA in this case. > > Requested Change : > > Change > > R-Open Send-Message R-Snd-Message R-Open > R-Rcv-Message Process R-Open > R-Rcv-DWR Process-DWR, R-Open > R-Snd-DWA > R-Rcv-DWA Process-DWA R-Open > R-Conn-CER R-Snd-CEA R-Open > R-Reject > Stop R-Snd-DPR Closing > R-Rcv-DPR R-Snd-DPA, Closed > R-Disc > R-Peer-Disc R-Disc Closed > R-Rcv-CER R-Snd-CEA R-Open > R-Rcv-CEA Process-CEA R-Open > > To > > R-Open Send-Message R-Snd-Message R-Open > R-Rcv-Message Process R-Open > R-Rcv-DWR Process-DWR, R-Open > R-Snd-DWA > R-Rcv-DWA Process-DWA R-Open > R-Conn-CER R-Reject R-Open > Stop R-Snd-DPR Closing > R-Rcv-DPR R-Snd-DPA, Closed > R-Disc > R-Peer-Disc R-Disc Closed > R-Rcv-CER R-Snd-CEA R-Open > R-Rcv-CEA Process-CEA R-Open > > From owner-aaa-wg@merit.edu Thu Oct 3 04:38: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 EAA29550 for ; Thu, 3 Oct 2002 04:38:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEADC91222; Thu, 3 Oct 2002 04:40:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE8269122A; Thu, 3 Oct 2002 04:40:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73A0991222 for ; Thu, 3 Oct 2002 04:40:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 56EFD5DE3B; Thu, 3 Oct 2002 04:40:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 8C4BC5DE0C for ; Thu, 3 Oct 2002 04:40:40 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g938fKK17735 for ; Thu, 3 Oct 2002 11:41:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 3 Oct 2002 11:40:37 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 3 Oct 2002 11:40:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Updated Diameter Base Spec Date: Thu, 3 Oct 2002 11:40:33 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A56CE@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 357: Inappropriate UTF-8 encoding (fwd) Thread-Index: AcJaW6Y3lCVK+APeQiOhmRp34jm1FAAprNBgAADoDCAAAT6V0APrUSdA From: To: X-OriginalArrivalTime: 03 Oct 2002 08:40:33.0947 (UTC) FILETIME=[89DFD6B0:01C26AB8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA29550 Hi all, I've updated the Diameter base spec, closing all open issues. Until it hits the email reflector, it can be found here: http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-13.txt At this point, I think the document has had an exhaustive WG review, several folks have done a thorough read of the draft and so I hope that the ADs can do their review and pass it on for IESG review. br, John From owner-aaa-wg@merit.edu Sat Oct 5 14:05: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 OAA19842 for ; Sat, 5 Oct 2002 14:05:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83DF49121E; Sat, 5 Oct 2002 14:07:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 57C3C91221; Sat, 5 Oct 2002 14:07:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61E789121E for ; Sat, 5 Oct 2002 14:07:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47F945DDBA; Sat, 5 Oct 2002 14:07:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 884E45DD8C for ; Sat, 5 Oct 2002 14:07:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g95H6rr10423 for ; Sat, 5 Oct 2002 10:06:54 -0700 Date: Sat, 5 Oct 2002 10:06:53 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 370: IANA considerations issues Submitter name: Scott Bradner Submitter email address: sob@harvard.edu Date first submitted: October 5, 2002 Reference: Document: Base Comment type: T Priority: S Section: 11 Rationale/Explanation of issue This issue covers IESG concerns about Diameter IANA considerations. Date: Sat, 5 Oct 2002 12:53:38 -0400 (EDT) From: Scott Bradner Subject: Diameter IANA Considerations Issues I do not like ad-hoc assignments if that can lead to non-interoperable implementations so I like to require at least a public specification. I'd rather that the public spec be an RFC so that there is some additional sanity check when the IESG takes a pre-publication look but a Designated Expert is not too bad. one nit on the IPS wording - it does not require that a reject notice comes along with a reason and, where possible, suggestions on how to make the request acceptable. Scott Proposed changes to deal with this concern: Section 11: Change: " Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For registration requests requiring Expert Review, the AAA mailing list should be consulted. For registration requests requiring Expert Review, the AAA mailing list should be consulted; if the AAA WG is disbanded, and the mailing list is no longer available, then the Area Director may appoint a Designated Expert." To: "Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For Designated Expert with Specification Required, the request is posted to the AAA WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a point to a public specification. After a period of 30 days has passed, the Designated Expert will either approve or deny the registration request. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable." Section 11.1.1 Change: " The AVP Code namespace is used to identify attributes. When the Vendor ID value is set to zero (0), IANA will maintain a registry of assigned AVP codes and in some cases also their values. AVP Codes 0-254 are managed separtely as RADIUS Attribute Types [RADTYPE], while the remaining namespace is available for assignmetn via Expert Review with Specification Required [IANA]. Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP header is set to a non-zero value, are for Private Use. This document defines the AVP Codes 257-274, 276-285, 287, 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the namespace in this specification." To: " The AVP Code namespace is used to identify attributes. When the Vendor ID value is set to zero (0), IANA will maintain a registry of assigned AVP codes and in some cases also their values. AVP Codes 0-254 are managed separately as RADIUS Attribute Types [RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287, 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the namespace in this specification. AVPs may be allocated following Designated Expert with Specification Required [IANA]. Release of blocks of AVPs (more than 3 at a time for a given purpose) should require IETF Consensus. Note that Diameter defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVPs codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of Diameter, where no interoperability is deemed useful." Section 11.4 - 11.9, 11.11 - 11.16 I'd suggest that these sections be put under a single section entitled "AVP values". As part of this, we need a general policy for AVP values, other than the ones specified. In RADIUS this is first come first served. Here is suggested text for Diameter: 11.3 Change: "Assignment of standards-track application IDs are by Expert Review with Specification Required [IANA]." To: " Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA]." 11.4 AVP Values Certain AVPs in Diameter define a list of values with various meanings. For attributes other than those specified in this section, addition of values can be done on a First Come, First Served basis by the IANA. From owner-aaa-wg@merit.edu Sat Oct 5 15: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 PAA21883 for ; Sat, 5 Oct 2002 15:32:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48A4291221; Sat, 5 Oct 2002 15:33:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4ED9C91224; Sat, 5 Oct 2002 15:33:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A815691221 for ; Sat, 5 Oct 2002 15:31:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8A6F55DF7E; Sat, 5 Oct 2002 15:31:13 -0400 (EDT) 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 0F3165DDC7 for ; Sat, 5 Oct 2002 15:31:13 -0400 (EDT) Received: from gwzw2k (rtp-dial-1-123.cisco.com [10.83.97.123]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id MAA17574; Sat, 5 Oct 2002 12:31:00 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , Cc: "Scott Bradner" Subject: RE: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues Date: Sat, 5 Oct 2002 12:30:57 -0700 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 V5.50.4910.0300 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: Just a couple of comments. ... > Proposed changes to deal with this concern: > > Section 11: > > Change: > " Diameter is not intended as a general purpose protocol, and > allocations SHOULD NOT be made for purposes unrelated to > authentication, authorization or accounting. For registration > requests where a Designated Expert should be consulted, the > responsible IESG area director should appoint the Designated Expert. > > For registration requests requiring Expert Review, the AAA mailing > list should be consulted. For registration requests requiring Expert > Review, the AAA mailing list should be consulted; if the AAA WG is > disbanded, and the mailing list is no longer available, then the Area > Director may appoint a Designated Expert." > > To: > > "Diameter is not intended as a general purpose protocol, and > allocations SHOULD NOT be made for purposes unrelated to > authentication, authorization or accounting. > > For registration requests where a Designated Expert should be > consulted, the responsible IESG area director should appoint the > Designated Expert. For Designated Expert with Specification Required, > the request is posted to the AAA WG mailing list (or, if it has been > disbanded, a successor designated by the Area Director) for comment > and review, and MUST include a point to a public specification. After a > period of 30 days has passed, the Designated Expert will either approve > or deny the registration request. This does not appear to put a time limit on the approve/deny decision. Suggestion: change "After a period of 30 days has passed, the Designated Expert will either approve or deny the registration request." to "Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request and publish a notice of the decision." > A denial notice must be justified by > an explanation and, in the cases where it is possible, concrete > suggestions on how the request can be modified so as to become > acceptable." > > Section 11.1.1 > > Change: > > " The AVP Code namespace is used to identify attributes. When the > Vendor ID value is set to zero (0), IANA will maintain a registry of > assigned AVP codes and in some cases also their values. AVP Codes > 0-254 are managed separtely as RADIUS Attribute Types [RADTYPE], > while the remaining namespace is available for assignmetn via Expert > Review with Specification Required [IANA]. > > Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP > header is set to a non-zero value, are for Private Use. > > This document defines the AVP Codes 257-274, 276-285, 287, 291-299, > 480, 483 and 485-486. See section 4.6 for the assignment of the > namespace in this specification." > > To: > > " The AVP Code namespace is used to identify attributes. When the > Vendor ID value is set to zero (0), IANA will maintain a registry of > assigned AVP codes and in some cases also their values. > > AVP Codes 0-254 are managed separately as RADIUS Attribute Types > [RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287, > 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the > namespace in this specification. > > AVPs may be allocated following Designated Expert with Specification > Required [IANA]. Release of blocks of AVPs (more than 3 at a time > for a given purpose) should require IETF Consensus. > > Note that Diameter defines a mechanism for Vendor-Specific AVPs, where > the Vendor-Id field in the AVP header is set to a non-zero value. > Vendor-Specific AVPs codes are for Private Use and should be encouraged > instead of allocation of global attribute types, for functions specific > only to one vendor's implementation of Diameter, where no interoperability > is deemed useful." This begs the obvious question of _who_ 'deems interoperability useful'. An example can be found in the vendor-specific RADIUS attributes defined in section 2.4 of RFC 2548: the IESG has not deemed these attributes useful enough for standardization, but many vendors apparently disaggree. I suggest that the text be modified to reflect the requirement for standard allocation if a Vendor-Specific AVP is implemented by more than one vendor. > > Section 11.4 - 11.9, 11.11 - 11.16 > > I'd suggest that these sections be put under a single section entitled > "AVP values". As part of this, we need a general policy for AVP values, > other than the ones specified. In RADIUS this is first come first served. > Here is suggested text for Diameter: > > 11.3 > > Change: > > "Assignment of standards-track application IDs are by Expert Review > with Specification Required [IANA]." > > To: > > " Assignment of standards-track application IDs are by Designated Expert > with Specification Required [IANA]." > > 11.4 AVP Values > > Certain AVPs in Diameter define a list of values with various meanings. > For attributes other than those specified in this section, addition of > values can be done on a First Come, First Served basis by the IANA. > > > > From owner-aaa-wg@merit.edu Sat Oct 5 15:42: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 PAA22105 for ; Sat, 5 Oct 2002 15:42:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F2A791224; Sat, 5 Oct 2002 15:44:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED55991226; Sat, 5 Oct 2002 15:44:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15DB091224 for ; Sat, 5 Oct 2002 15:44:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 060E65DF82; Sat, 5 Oct 2002 15:44:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 783BD5DF81 for ; Sat, 5 Oct 2002 15:44:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g95IhPb15701; Sat, 5 Oct 2002 11:43:25 -0700 Date: Sat, 5 Oct 2002 11:43:25 -0700 (PDT) From: Bernard Aboba To: Glen Zorn Cc: aaa-wg@merit.edu, Scott Bradner Subject: RE: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > This does not appear to put a time limit on the approve/deny decision. > Suggestion: change "After a > period of 30 days has passed, the Designated Expert will either approve or > deny the registration request." to "Before a period of 30 days has passed, > the Designated Expert will either approve or deny the registration request > and publish a notice of the decision." Done. > This begs the obvious question of _who_ 'deems interoperability useful'. An > example can be found in the vendor-specific RADIUS attributes defined in > section 2.4 of RFC 2548: the IESG has not deemed these attributes useful > enough for standardization, but many vendors apparently disaggree. I > suggest that the text be modified to reflect the requirement for standard > allocation if a Vendor-Specific AVP is implemented by more than one vendor. How about this? "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVPs codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of Diameter, where no interoperability is deemed useful. Where a Vendor-Specific AVP is implemented by more than one vendor, use of a standard AVP is recommended." From owner-aaa-wg@merit.edu Sat Oct 5 18:53: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 SAA27183 for ; Sat, 5 Oct 2002 18:53:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2289891211; Sat, 5 Oct 2002 18:55:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E073D9121F; Sat, 5 Oct 2002 18:55:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D43BF91211 for ; Sat, 5 Oct 2002 18:55:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B805D5DDD2; Sat, 5 Oct 2002 18:55:03 -0400 (EDT) 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 918AC5DDC7 for ; Sat, 5 Oct 2002 18:55:03 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17xxp9-000LwK-00; Sat, 05 Oct 2002 15:55:03 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: aaa-wg@merit.edu, Scott Bradner Subject: RE: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues References: Message-Id: Date: Sat, 05 Oct 2002 15:55:03 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> Suggestion: change "After a >> period of 30 days has passed, the Designated Expert will either approve or >> deny the registration request." to "Before a period of 30 days has passed, >> the Designated Expert will either approve or deny the registration request >> and publish a notice of the decision." > Done. the designated expert advises the iana function. i suspect we do not wish to imbue the role with formal process. iana should announce any decision it makes. >> This begs the obvious question of _who_ 'deems interoperability useful'. >> An example can be found in the vendor-specific RADIUS attributes defined >> in section 2.4 of RFC 2548: the IESG has not deemed these attributes >> useful enough for standardization, but many vendors apparently disaggree. >> I suggest that the text be modified to reflect the requirement for >> standard allocation if a Vendor-Specific AVP is implemented by more than >> one vendor. > "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where > the Vendor-Id field in the AVP header is set to a non-zero value. > Vendor-Specific AVPs codes are for Private Use and should be encouraged > instead of allocation of global attribute types, for functions specific > only to one vendor's implementation of Diameter, where no interoperability > is deemed useful. Where a Vendor-Specific AVP is implemented by more than > one vendor, use of a standard AVP is recommended." ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ standard AVP documentation and process should be used instead. randy From owner-aaa-wg@merit.edu Sat Oct 5 22:48: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 WAA00362 for ; Sat, 5 Oct 2002 22:48:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AED1291226; Sat, 5 Oct 2002 22:50:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EAE091227; Sat, 5 Oct 2002 22:50:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8AD1491226 for ; Sat, 5 Oct 2002 22:50:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EFAF5DDF6; Sat, 5 Oct 2002 22:50:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EAEED5DDC7 for ; Sat, 5 Oct 2002 22:50:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g961nnn06527; Sat, 5 Oct 2002 18:49:49 -0700 Date: Sat, 5 Oct 2002 18:49:48 -0700 (PDT) From: Bernard Aboba To: Randy Bush Cc: aaa-wg@merit.edu, Scott Bradner Subject: RE: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > one vendor, use of a standard AVP is recommended." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > standard AVP documentation and process should be used instead. Done. From owner-aaa-wg@merit.edu Sun Oct 6 04:09: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 EAA12752 for ; Sun, 6 Oct 2002 04:09:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB9999122C; Sun, 6 Oct 2002 04:11:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A35049122D; Sun, 6 Oct 2002 04:11:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9723D9122C for ; Sun, 6 Oct 2002 04:11:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C3205DFBA; Sun, 6 Oct 2002 04:11:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 356EB5DFA4 for ; Sun, 6 Oct 2002 04:11:11 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 126B46A906; Sun, 6 Oct 2002 11:11:04 +0300 (EEST) Message-ID: <3D9FF17F.6090702@kolumbus.fi> Date: Sun, 06 Oct 2002 11:17:03 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Glen Zorn , aaa-wg@merit.edu, Scott Bradner Subject: Re: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues 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 First Glen brought up an event from history: >>This begs the obvious question of _who_ 'deems interoperability useful'. An >>example can be found in the vendor-specific RADIUS attributes defined in >>section 2.4 of RFC 2548: the IESG has not deemed these attributes useful >>enough for standardization, but many vendors apparently disaggree. I >>suggest that the text be modified to reflect the requirement for standard >>allocation if a Vendor-Specific AVP is implemented by more than one vendor. And then Bernard changed the wording to: > "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where > the Vendor-Id field in the AVP header is set to a non-zero value. > Vendor-Specific AVPs codes are for Private Use and should be encouraged > instead of allocation of global attribute types, for functions specific > only to one vendor's implementation of Diameter, where no interoperability > is deemed useful. Where a Vendor-Specific AVP is implemented by more than > one vendor, standard AVP documentation and process should be used instead." Now, let's see what would have happened if this text had been applied to RADIUS at time of RFC 2548. Obviously, the IESG would still have had the same opinion. Since there were many vendors who actually did use the Microsoft VSAs, the text above would have dictated *standard* AVP documention and process. Conclusion: there would not have been a standard RFC (IESG blocks it) and Microsoft could not have published their document in IETF, because the text dictates a standard process. Glen, did you really ask for this?! But note that the text in the first part of the AVP allocation rules says as follows: > AVPs may be allocated following Designated Expert with Specification > Required [IANA]. Release of blocks of AVPs (more than 3 at a time > for a given purpose) should require IETF Consensus. So my suggestion is that if multiple vendors implement an AVP, this shouldn't be changed to Standards Action! So, my suggestion is to change Bernard's wording to the following: "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVPs codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of Diameter, where no interoperability is deemed useful. Where an AVP is implemented by more than one vendor, an allocation of global attribute types should be encouraged instead." Jari From owner-aaa-wg@merit.edu Mon Oct 7 17:32: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 RAA06958 for ; Mon, 7 Oct 2002 17:32:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1249791277; Mon, 7 Oct 2002 17:34:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2378591278; Mon, 7 Oct 2002 17:32:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BD7F91277 for ; Mon, 7 Oct 2002 17:32:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 044025E01D; Mon, 7 Oct 2002 17:32:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id 9787F5DDA4 for ; Mon, 7 Oct 2002 17:32:14 -0400 (EDT) Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g97LWDP00651 for ; Mon, 7 Oct 2002 17:32:13 -0400 (EDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA10595; Mon, 7 Oct 2002 16:32:13 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id H3MRTJ-00015S-00 for aaa-wg@merit.edu; Mon, 07 Oct 2002 17:32:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15777.64853.474240.768477@gargle.gargle.HOWL> Date: Mon, 7 Oct 2002 16:32:05 -0500 From: Pete McCann To: aaa-wg@merit.edu Subject: [AAA-WG]: Editorial Comments on draft-13 X-Mailer: VM 7.03 under 21.4 (patch 7) "Economic Science (Windows [1])" XEmacs Lucid Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Issue: Editorial Comments on draft-13 Submitter name: Pete McCann Submitter email address: mccap@lucent.com Date first submitted: October 7, 2002 Reference: Document: Base Comment type: E Priority: S Section: 6, 11 I spotted a few editorial issues in draft-13: Section 6.1, page 69: it looks like steps 2 and 3 of the message processing rules have been munged together. Maybe some nroff needs fixing. Section 11, 1st paragraph: "IETF Consensus" needs a leading quotation mark. Section 11.3, 2nd paragraph, the wording is a little confusing. I suggest changing from this: IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. Assignment of standards-track application IDs are by Expert Review with Specification Required [IANA]. To this: IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications. Assignment of standards-track application IDs is by Expert Review with Specification Required [IANA]. Assignment of vendor specific application IDs is on a First Come First Served [IANA] basis. -Pete From owner-aaa-wg@merit.edu Tue Oct 8 03:14: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 DAA02137 for ; Tue, 8 Oct 2002 03:14:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 85AA59127F; Tue, 8 Oct 2002 03:15:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB8ED91281; Tue, 8 Oct 2002 03:15:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 767D39127F for ; Tue, 8 Oct 2002 03:15:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1672C5DD9B; Tue, 8 Oct 2002 03:15:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id D3B2D5DD94 for ; Tue, 8 Oct 2002 03:15:20 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g987G8K29177 for ; Tue, 8 Oct 2002 10:16:08 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 8 Oct 2002 10:13:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Oct 2002 10:13:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues Date: Tue, 8 Oct 2002 10:13:57 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5735@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues Thread-Index: AcJtD//HazMOnIAwQfis0hlNpVZuywBijVOw From: To: , Cc: , , X-OriginalArrivalTime: 08 Oct 2002 07:13:58.0361 (UTC) FILETIME=[45211490:01C26E9A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02137 Hi Jari, > "Note that Diameter defines a mechanism for Vendor-Specific AVPs, where > the Vendor-Id field in the AVP header is set to a non-zero value. > Vendor-Specific AVPs codes are for Private Use and should be encouraged > instead of allocation of global attribute types, for functions specific > only to one vendor's implementation of Diameter, where no interoperability > is deemed useful. Where an AVP is implemented by more than one vendor, > an allocation of global attribute types should be encouraged instead." This seems reasonable. John From owner-aaa-wg@merit.edu Wed Oct 9 00:05: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 AAA08865 for ; Wed, 9 Oct 2002 00:05:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2093B912C8; Wed, 9 Oct 2002 00:07:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBFA1912C9; Wed, 9 Oct 2002 00:07:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2BE48912C8 for ; Wed, 9 Oct 2002 00:04:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D38AB5E0A4; Wed, 9 Oct 2002 00:04:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from wire.cs.nthu.edu.tw (wire.cs.nthu.edu.tw [140.114.79.60]) by segue.merit.edu (Postfix) with ESMTP id A888B5DE77 for ; Wed, 9 Oct 2002 00:04:26 -0400 (EDT) Received: from mantis (mantis.cs.nthu.edu.tw [140.114.79.52]) by wire.cs.nthu.edu.tw (8.11.6/8.11.6) with SMTP id g99FeTR09152 for ; Wed, 9 Oct 2002 11:40:29 -0400 Message-ID: <047001c26f48$816a48f0$344f728c@mantis> From: "Ming-Chia Jiang" To: Subject: [AAA-WG]: Is there any Diameter implementation? Date: Wed, 9 Oct 2002 12:01:11 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" 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 Hi. Is there any Diameter implementation available now?? Regards jmc From owner-aaa-wg@merit.edu Wed Oct 9 05:37: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 FAA08057 for ; Wed, 9 Oct 2002 05:37:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF9B5912D0; Wed, 9 Oct 2002 05:39:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96EF2912D1; Wed, 9 Oct 2002 05:39:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 750F3912D0 for ; Wed, 9 Oct 2002 05:39:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 580B35DEB7; Wed, 9 Oct 2002 05:39:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id DF86C5DDCE for ; Wed, 9 Oct 2002 05:39:30 -0400 (EDT) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Wed, 09 Oct 2002 10:41:18 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id <43LLSMZ2>; Wed, 9 Oct 2002 10:36:03 +0100 Message-ID: From: Xin Chen To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: MIPv4 & Diameter MIPv4 application part Date: Wed, 9 Oct 2002 10:35:53 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-870ec193-46e6-49a8-88bf-0608cd9ee1b9" Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPartTM-000-870ec193-46e6-49a8-88bf-0608cd9ee1b9 Content-Type: text/plain Dear all, I have a question on the early stage of learning both AAA and mobile IP. Mobile IPv4 defines that during mobile node registration procedure, the foreign agent relays the registration request sent by the mobile node to its home agent. On the other hand, Diameter Mobile IP application defines that during mobile node registration procedure, the foreign agent sends AMR diameter message to home agent. Therefore I see that there are two different implementation on the foreign agent, one is relaying and one is sending AMR. Does this mean that if Mobile IP is used with the Diameter Mobile IP application part, then foreign agent and home agent are not needed to be implemented in the way which is defined in Mobile IPv4 specification. Since the foreign agent will have to map the parameters in the registration request sent by mobile node to a AMR message AVPs and the home agent is not needed to understand the registration request but the AMR? Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------=_NextPartTM-000-870ec193-46e6-49a8-88bf-0608cd9ee1b9 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-870ec193-46e6-49a8-88bf-0608cd9ee1b9-- From owner-aaa-wg@merit.edu Wed Oct 9 10:19: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 KAA18770 for ; Wed, 9 Oct 2002 10:19:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C6E1F91218; Wed, 9 Oct 2002 10:21:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92CDD912DA; Wed, 9 Oct 2002 10:21:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35CDF91218 for ; Wed, 9 Oct 2002 10:21:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 16BFB5DED7; Wed, 9 Oct 2002 10:21:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 6B65A5DE5D for ; Wed, 9 Oct 2002 10:21:30 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g99ELBlg016331 for ; Wed, 9 Oct 2002 10:21:12 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA00984 for ; Wed, 9 Oct 2002 10:21:42 -0400 (EDT) Date: Wed, 9 Oct 2002 10:21:10 -0400 To: aaa-wg@merit.edu Subject: [AAA-WG]: OpenDiameter announcement Message-ID: <20021009142110.GA1596@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 16 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, Let me allow to post this announce on the AAA mailing list. A new project for develpping open source Diameter software has been created. A Diameter message parser library is available in the first release. We will actively work on releasing new stuff and updating them. If you are interested in this project, visit http://opendiameter.org. For further questions, please send email to diameter-devel@opendiameter.org, not to this list. Thanks, Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 9 10:54: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 KAA20589 for ; Wed, 9 Oct 2002 10:54:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3CA74912DA; Wed, 9 Oct 2002 10:55:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 080A7912DB; Wed, 9 Oct 2002 10:55:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AB25912DA for ; Wed, 9 Oct 2002 10:55:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E59565DEE5; Wed, 9 Oct 2002 10:55:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 72ACF5DED7 for ; Wed, 9 Oct 2002 10:55:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g99Dspj28093; Wed, 9 Oct 2002 06:54:51 -0700 Date: Wed, 9 Oct 2002 06:54:51 -0700 (PDT) From: Bernard Aboba To: iesg@ietf.org Cc: aaa-wg@merit.edu, Subject: [AAA-WG]: Completion of AAA WG last call on Diameter Mobile IPv4 Application Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG has now completed working group last call on the Diameter Mobile IPv4 application document with 3 comments: Issues 351, 368 and 369. Comments received during this and previous AAA WG last calls are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html AAA WG last call comments have been resolved and reflected in a new document version posted on the IETF archive: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt As a result, the AAA WG recommends that the IESG begin IETF last call on this document, in order to consider it for adoption as an IETF Proposed Standard. From owner-aaa-wg@merit.edu Wed Oct 9 10:55: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 KAA20678 for ; Wed, 9 Oct 2002 10:55:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BAECC912DB; Wed, 9 Oct 2002 10:56:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9075B912DC; Wed, 9 Oct 2002 10:56:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A5256912DB for ; Wed, 9 Oct 2002 10:56:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F2365DEE7; Wed, 9 Oct 2002 10:56:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1ADD65DEE5 for ; Wed, 9 Oct 2002 10:56:51 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g99DtpV28147; Wed, 9 Oct 2002 06:55:51 -0700 Date: Wed, 9 Oct 2002 06:55:51 -0700 (PDT) From: Bernard Aboba To: iesg@ietf.org Cc: aaa-wg@merit.edu, Subject: [AAA-WG]: Completion of AAA WG last call on AAA Transport Profile Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG has now completed working group last call on the AAA Transport Profile document with no comments. Comments received during this and previous AAA WG last calls are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html The latest version of the document posted on the IETF archive is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt As a result, the AAA WG recommends that the IESG begin IETF last call on this document, in order to consider it for adoption as an IETF Proposed Standard. From owner-aaa-wg@merit.edu Wed Oct 9 11:40: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 LAA22367 for ; Wed, 9 Oct 2002 11:40:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BCF5891201; Wed, 9 Oct 2002 11:42:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CEAD912DE; Wed, 9 Oct 2002 11:42:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6E56591201 for ; Wed, 9 Oct 2002 11:42:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 516F95DEE1; Wed, 9 Oct 2002 11:42:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by segue.merit.edu (Postfix) with ESMTP id 0C3F05DEB0 for ; Wed, 9 Oct 2002 11:42:17 -0400 (EDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with ESMTP id LAA10005 for ; Wed, 9 Oct 2002 11:42:15 -0400 (EDT) From: "Subrata Goswami" To: Subject: [AAA-WG]: Redundant AVP's ? Date: Wed, 9 Oct 2002 08:40:37 -0700 Message-ID: <001001c26faa$399fe9a0$0300a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The following AVP's appear to be redundant in the AMR as they appear to be all ready contained in { MIP-Reg-Request }. { Origin-Host } { MIP-MN-AAA-Auth } [ Destination-Host ] [ MIP-Mobile-Node-Address ] [ MIP-Home-Agent-Address ] ::= < Diameter Header: 260, REQ, PXY > < Session-ID > { Auth-Application-Id } { User-Name } { Destination-Realm } { Origin-Host } { Origin-Realm } { MIP-Reg-Request } { MIP-MN-AAA-Auth } [ Acct-Multi-Session-Id ] [ Destination-Host ] [ Origin-State-Id ] [ MIP-Mobile-Node-Address ] [ MIP-Home-Agent-Address ] [ MIP-Feature-Vector ] [ MIP-Originating-Foreign-AAA ] [ Authorization-Lifetime ] [ Auth-Session-State ] [ MIP-FA-Challenge ] [ MIP-Candidate-Home-Agent-Host ] * [ Proxy-Info ] * [ Route-Record ] * [ AVP ] Subrata -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Bernard Aboba Sent: Saturday, October 05, 2002 10:07 AM To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues Issue 370: IANA considerations issues Submitter name: Scott Bradner Submitter email address: sob@harvard.edu Date first submitted: October 5, 2002 Reference: Document: Base Comment type: T Priority: S Section: 11 Rationale/Explanation of issue This issue covers IESG concerns about Diameter IANA considerations. Date: Sat, 5 Oct 2002 12:53:38 -0400 (EDT) From: Scott Bradner Subject: Diameter IANA Considerations Issues I do not like ad-hoc assignments if that can lead to non-interoperable implementations so I like to require at least a public specification. I'd rather that the public spec be an RFC so that there is some additional sanity check when the IESG takes a pre-publication look but a Designated Expert is not too bad. one nit on the IPS wording - it does not require that a reject notice comes along with a reason and, where possible, suggestions on how to make the request acceptable. Scott Proposed changes to deal with this concern: Section 11: Change: " Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For registration requests requiring Expert Review, the AAA mailing list should be consulted. For registration requests requiring Expert Review, the AAA mailing list should be consulted; if the AAA WG is disbanded, and the mailing list is no longer available, then the Area Director may appoint a Designated Expert." To: "Diameter is not intended as a general purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to authentication, authorization or accounting. For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. For Designated Expert with Specification Required, the request is posted to the AAA WG mailing list (or, if it has been disbanded, a successor designated by the Area Director) for comment and review, and MUST include a point to a public specification. After a period of 30 days has passed, the Designated Expert will either approve or deny the registration request. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable." Section 11.1.1 Change: " The AVP Code namespace is used to identify attributes. When the Vendor ID value is set to zero (0), IANA will maintain a registry of assigned AVP codes and in some cases also their values. AVP Codes 0-254 are managed separtely as RADIUS Attribute Types [RADTYPE], while the remaining namespace is available for assignmetn via Expert Review with Specification Required [IANA]. Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP header is set to a non-zero value, are for Private Use. This document defines the AVP Codes 257-274, 276-285, 287, 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the namespace in this specification." To: " The AVP Code namespace is used to identify attributes. When the Vendor ID value is set to zero (0), IANA will maintain a registry of assigned AVP codes and in some cases also their values. AVP Codes 0-254 are managed separately as RADIUS Attribute Types [RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287, 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the namespace in this specification. AVPs may be allocated following Designated Expert with Specification Required [IANA]. Release of blocks of AVPs (more than 3 at a time for a given purpose) should require IETF Consensus. Note that Diameter defines a mechanism for Vendor-Specific AVPs, where the Vendor-Id field in the AVP header is set to a non-zero value. Vendor-Specific AVPs codes are for Private Use and should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of Diameter, where no interoperability is deemed useful." Section 11.4 - 11.9, 11.11 - 11.16 I'd suggest that these sections be put under a single section entitled "AVP values". As part of this, we need a general policy for AVP values, other than the ones specified. In RADIUS this is first come first served. Here is suggested text for Diameter: 11.3 Change: "Assignment of standards-track application IDs are by Expert Review with Specification Required [IANA]." To: " Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA]." 11.4 AVP Values Certain AVPs in Diameter define a list of values with various meanings. For attributes other than those specified in this section, addition of values can be done on a First Come, First Served basis by the IANA. From owner-aaa-wg@merit.edu Wed Oct 9 11:42: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 LAA22482 for ; Wed, 9 Oct 2002 11:42:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 40B39912DE; Wed, 9 Oct 2002 11:44:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 121E3912DF; Wed, 9 Oct 2002 11:44:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC934912DE for ; Wed, 9 Oct 2002 11:44:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8D1E5DEB0; Wed, 9 Oct 2002 11:44:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id D111E5E0CA for ; Wed, 9 Oct 2002 11:44:27 -0400 (EDT) Received: from fmorn1dcode948i (a12.local.ipunplugged.com [192.168.4.182]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g99Fi824010921; Wed, 9 Oct 2002 17:44:09 +0200 From: "Fredrik Johansson" To: "Subrata Goswami" , Subject: RE: [AAA-WG]: Redundant AVP's ? Date: Wed, 9 Oct 2002 17:45:21 +0200 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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <001001c26faa$399fe9a0$0300a8c0@SGOSWAMIPCL> X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit the information might be redundant but the AVPs are put in the AMR since the AAA-server doesn't know how to parse the MIP registration request. /fredrik > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Subrata Goswami > Sent: den 9 oktober 2002 17:41 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Redundant AVP's ? > > > > The following AVP's appear to be redundant in the AMR as they > appear to be all ready contained in { MIP-Reg-Request }. > > { Origin-Host } > { MIP-MN-AAA-Auth } > [ Destination-Host ] > [ MIP-Mobile-Node-Address ] > [ MIP-Home-Agent-Address ] > > ::= < Diameter Header: 260, REQ, PXY > > < Session-ID > > { Auth-Application-Id } > { User-Name } > { Destination-Realm } > { Origin-Host } > { Origin-Realm } > { MIP-Reg-Request } > { MIP-MN-AAA-Auth } > [ Acct-Multi-Session-Id ] > [ Destination-Host ] > [ Origin-State-Id ] > [ MIP-Mobile-Node-Address ] > [ MIP-Home-Agent-Address ] > [ MIP-Feature-Vector ] > [ MIP-Originating-Foreign-AAA ] > [ Authorization-Lifetime ] > [ Auth-Session-State ] > [ MIP-FA-Challenge ] > [ MIP-Candidate-Home-Agent-Host ] > * [ Proxy-Info ] > * [ Route-Record ] > * [ AVP ] > Subrata > > > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of Bernard Aboba > Sent: Saturday, October 05, 2002 10:07 AM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 370: Diameter IANA Considerations Issues > > Issue 370: IANA considerations issues > Submitter name: Scott Bradner > Submitter email address: sob@harvard.edu > Date first submitted: October 5, 2002 > Reference: > Document: Base > Comment type: T > Priority: S > Section: 11 > Rationale/Explanation of issue > > This issue covers IESG concerns about Diameter IANA considerations. > > Date: Sat, 5 Oct 2002 12:53:38 -0400 (EDT) > From: Scott Bradner > Subject: Diameter IANA Considerations Issues > > I do not like ad-hoc assignments if that can lead to non-interoperable > implementations so I like to require at least a public specification. > > I'd rather that the public spec be an RFC so that there is some > additional sanity check when the IESG takes a pre-publication look > but a Designated Expert is not too bad. > > one nit on the IPS wording - it does not require that a reject notice > comes along with a reason and, where possible, suggestions on > how to make the request acceptable. > > Scott > > Proposed changes to deal with this concern: > > Section 11: > > Change: > " Diameter is not intended as a general purpose protocol, and > allocations SHOULD NOT be made for purposes unrelated to > authentication, authorization or accounting. For registration > requests where a Designated Expert should be consulted, the > responsible IESG area director should appoint the Designated Expert. > > For registration requests requiring Expert Review, the AAA mailing > list should be consulted. For registration requests requiring Expert > Review, the AAA mailing list should be consulted; if the AAA WG is > disbanded, and the mailing list is no longer available, then the Area > Director may appoint a Designated Expert." > > To: > > "Diameter is not intended as a general purpose protocol, and > allocations SHOULD NOT be made for purposes unrelated to > authentication, authorization or accounting. > > For registration requests where a Designated Expert should be > consulted, the responsible IESG area director should appoint the > Designated Expert. For Designated Expert with Specification Required, > the request is posted to the AAA WG mailing list (or, if it has been > disbanded, a successor designated by the Area Director) for comment > and review, and MUST include a point to a public specification. After > a > period of 30 days has passed, the Designated Expert will either > approve > or deny the registration request. A denial notice must be justified > by > an explanation and, in the cases where it is possible, concrete > suggestions on how the request can be modified so as to become > acceptable." > > Section 11.1.1 > > Change: > > " The AVP Code namespace is used to identify attributes. When the > Vendor ID value is set to zero (0), IANA will maintain a registry of > assigned AVP codes and in some cases also their values. AVP Codes > 0-254 are managed separtely as RADIUS Attribute Types [RADTYPE], > while the remaining namespace is available for assignmetn via Expert > Review with Specification Required [IANA]. > > Vendor-Specific AVP Codes, where the Vendor-Id field in the AVP > header is set to a non-zero value, are for Private Use. > > This document defines the AVP Codes 257-274, 276-285, 287, 291-299, > 480, 483 and 485-486. See section 4.6 for the assignment of the > namespace in this specification." > > To: > > " The AVP Code namespace is used to identify attributes. When the > Vendor ID value is set to zero (0), IANA will maintain a registry of > assigned AVP codes and in some cases also their values. > > AVP Codes 0-254 are managed separately as RADIUS Attribute Types > [RADTYPE]. This document defines the AVP Codes 257-274, 276-285, 287, > 291-299, 480, 483 and 485-486. See section 4.6 for the assignment of the > namespace in this specification. > > AVPs may be allocated following Designated Expert with Specification > Required [IANA]. Release of blocks of AVPs (more than 3 at a time > for a given purpose) should require IETF Consensus. > > Note that Diameter defines a mechanism for Vendor-Specific AVPs, where > the Vendor-Id field in the AVP header is set to a non-zero value. > Vendor-Specific AVPs codes are for Private Use and should be encouraged > instead of allocation of global attribute types, for functions specific > only to one vendor's implementation of Diameter, where no > interoperability > is deemed useful." > > Section 11.4 - 11.9, 11.11 - 11.16 > > I'd suggest that these sections be put under a single section entitled > "AVP values". As part of this, we need a general policy for AVP values, > other than the ones specified. In RADIUS this is first come first > served. > Here is suggested text for Diameter: > > 11.3 > > Change: > > "Assignment of standards-track application IDs are by Expert Review > with Specification Required [IANA]." > > To: > > " Assignment of standards-track application IDs are by Designated > Expert > with Specification Required [IANA]." > > 11.4 AVP Values > > Certain AVPs in Diameter define a list of values with various meanings. > For attributes other than those specified in this section, addition of > values can be done on a First Come, First Served basis by the IANA. > From owner-aaa-wg@merit.edu Fri Oct 11 07:52: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 HAA17687 for ; Fri, 11 Oct 2002 07:52:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F06091229; Fri, 11 Oct 2002 07:54:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08E379122C; Fri, 11 Oct 2002 07:54:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D245591229 for ; Fri, 11 Oct 2002 07:54:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B06E75DF6C; Fri, 11 Oct 2002 07:54:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id B748B5DDCD for ; Fri, 11 Oct 2002 07:54:43 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9BBsQw08518 for ; Fri, 11 Oct 2002 14:54:26 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Oct 2002 14:54:41 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Oct 2002 14:54:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: issue: real-time duplicate detection Date: Fri, 11 Oct 2002 14:54:40 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E436A@esebe016.ntc.nokia.com> Thread-Topic: issue: real-time duplicate detection Thread-Index: AcJxHPlK64swZ0JUSsmkcosqMSQGAw== From: To: , Cc: , , , , X-OriginalArrivalTime: 11 Oct 2002 11:54:40.0948 (UTC) FILETIME=[FB552740:01C2711C] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA17687 Hi, I apologize to open this discussion so late but in Nokia we just notice the we have a problem while discussing the possible error cases for the draft Diameter Credit Control Application, which is also used in 3GPP Rel5 IMS (IP Multimedia subsystem) to realize real-time credit based accounting (i.e prepaid accounting, sometime called token based accounting). The problem we have is related to real-time duplicate detection of event accounting request. I briefly summarize the problem below. In Credit Control Application is possible to perform one-time event for three different purposes: direct debiting, refund and balance check. The problem appears with direct debiting and refund. One time event uses accounting request[event] message and basically when the action is direct debiting the corresponding amount of money is directly deducted from the user's account and when the action is refund the corresponding amount of money is credited in the user's account. These use cases require real-time duplicate detection of the received event request in order to avoid multiple debiting or multiple refund for the same request. The duplicate detection must be performed and the proper answer must be given back to the client immediately so as to grant or to not grant the service to the end user. In short, within few seconds the service need to be granted or not granted to the end user, if the end user has to wait too long before being able to use the requested service (e.g. Instant message) the user experience will suffer too much. With the current Diameter base protocol, for every single received request the Credit Control Server would need to search possible duplicate among other request received within a certain backward time window (e.g a day). In current wireless GSM network there are several milion of prepaid subscriber and we have feeling that is an impossible task for the CC server to perform real-time duplicate detection with the mentioned approach, performances will suffer and the answer will be sent too late to the client. Use of hashing techniques or other schemes help to eliminate the need to do full search of received accounting request within a time window as mentioned in AnnexC. However, the hashing approach to address real-time duplicate detection hasn't been tried in practise and hasn't been evaluated in full. We beleive that hashing introduce additional complexity to server implementation and also in finding the proper hashing function, hash table size etc. to minimize for example collision cases. In contrast other techniques for duplicate detection are already used, proven to work and operational in live networks with millions of subscribers(e.g. 3GPP GPRS charging protocol). This techniques consist in the client marking the possible duplicate upon re-transmission of the messages. For those not familiar with this technique I suggest to read the 3GPP technical specifications 32.215 (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). Implementations in 3GPP use this mechanism to also support hot-billing where real-time duplicate detection is required and is proven to work in operational networks. For the above mentioned reasons we think that there might be implementation that do not make use of hashing techniques and that even do not plan to support these techniques in near future. Thus we believe that a more simple tool to enable optimization of real-time duplicate detection should be provided by the base protocol in addition to hashing techniques or other complex schemes that a server may chose to implement. A not so clean solution to this problem is the Re-transmission AVP defined in the CC Application that however introduce some challenge with the management of the base protocol pending message queue(i.e. CC messages in queue need to be deleted upon failover/failback execution to avoid their re-transmission without being marked with the AVP). In addition this solution does not solve the problem when relay/redirect agents are between client and server. The CC servers implementation that decide to use the Re-transmission AVP will search for possible duplicate only when a request message is received with this AVP and not for every single received request. We feel that a better solution based on the base protocol may exist. We propose that the base protocol to mark re-transmitted messages by dedicating one reserved bit of the Diameter header to this purpose, server may use D-bit or hashing according to their implementation. Please note that the way the server implement duplicate detection (use of D-bit or not) is implementation dependent and does not affect interoperability at all. This proposal was already discussed sometime ago (named D-bit)and was rejected because the real-time duplicate detection was not seen necessary, we beleive that this requirement is now existing due to the above mentioned reasons and proven to work tool to implement simple real-time duplicate detection in the server (without adding implementation complexity) should be offered by the base protocol. In conclusion if you have better proposal let us know otherwise we will suggest small changes to chapters 3, 5.5.4 and AppendixC on following e-mail for your review and comments. With our best regards Marco, Helen, JP From owner-aaa-wg@merit.edu Fri Oct 11 10:11: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 KAA22456 for ; Fri, 11 Oct 2002 10:11:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4392B91235; Fri, 11 Oct 2002 10:13:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1577F912FF; Fri, 11 Oct 2002 10:13:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1BD1E91235 for ; Fri, 11 Oct 2002 10:13:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 02AB25DF7D; Fri, 11 Oct 2002 10:13:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6277C5DF7B for ; Fri, 11 Oct 2002 10:13:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9BDCOb23993; Fri, 11 Oct 2002 06:12:24 -0700 Date: Fri, 11 Oct 2002 06:12:24 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E436A@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > A not so clean solution to this problem is the Re-transmission AVP defined > in the CC Application that however introduce some challenge with the management > of the base protocol pending message queue(i.e. CC messages in queue need to be > deleted upon failover/failback execution to avoid their re-transmission without > being marked with the AVP). In practice, this is very difficult to achieve. All a Diameter client can know is that it didn't receive an Application Layer ACK for the accounting message. There can be Diameter agents between the client and server, so that failover is initiated based on "liveness" of the Diameter agent, not receipt of the application layer ACK. If the Diameter agent is "live" (as indicated by receipt of DWRs) then it could be failing over to a different accounting server, and the Diameter client will not know it -- and therefore would be unable to mark the messages appropriately. And of course, the Diameter client has no visibility into transport behavior anywhere along the path. Even with no Diameter agents, it is possible that the server did send the ACK, but somehow it was never received, due to network or other problems. The Diameter client does not know whether it received a transport layer ACK for the accounting message, and whether retransmission of the accounting message or ACK is occuring at the transport layer. Based on the server not demonstrating "liveness" (such as lack of DWRs), the Diameter client will failover. Since the failover time is less than TIME_WAIT, it is conceivable that the failover connection will deliver the accounting message (and application layer ACK) and that afterwards an application layer ACK will finally be received from the failing connection. So in practice, some sort of search is necessary in any case, within a time window proportional to TIME_WAIT. > The CC servers implementation that decide to use the Re-transmission AVP will > search for possible duplicate only when a request message is received with this > AVP and not for every single received request. Unfortunately, that approach is not reliable, due to the vagaries of transport behavior -- and it fails completely where Diameter agents are deployed. > This proposal was already discussed sometime ago (named D-bit)and was rejected because > the real-time duplicate detection was not seen necessary Actually, it was rejected because the proposed solution does not work. From owner-aaa-wg@merit.edu Fri Oct 11 10:27: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 KAA23124 for ; Fri, 11 Oct 2002 10:27:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA021912FF; Fri, 11 Oct 2002 10:29:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9346F91302; Fri, 11 Oct 2002 10:29:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9DE70912FF for ; Fri, 11 Oct 2002 10:29:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 870655DE37; Fri, 11 Oct 2002 10:29:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by segue.merit.edu (Postfix) with SMTP id C32615DD8F for ; Fri, 11 Oct 2002 10:29:43 -0400 (EDT) Received: (cpmta 24145 invoked from network); 11 Oct 2002 07:29:42 -0700 Received: from 151.203.220.165 (HELO DMITTON-IBMTP.mitton.com) by smtp.mitton.com (209.228.32.72) with SMTP; 11 Oct 2002 07:29:42 -0700 X-Sent: 11 Oct 2002 14:29:42 GMT Message-Id: <5.1.1.6.2.20021011101751.03158170@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 11 Oct 2002 10:20:46 -0400 To: aaa-wg@merit.edu From: David Mitton Subject: [AAA-WG]: Request for spreadsheet AVP dictionary? In-Reply-To: References: <142DC466081D9B409AAD1DDCA4B21E1D9E436A@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Utility request: Has anyone spread-sheeted the Diameter (and/or/both RADIUS) AVPs (and attributes)?? Even a dictionary in tabular (or CSV) form would help. I'd appreciate a copy for checking tables and such. Thanks, Dave. From owner-aaa-wg@merit.edu Fri Oct 11 10:47: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 KAA24060 for ; Fri, 11 Oct 2002 10:47:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6E8D591302; Fri, 11 Oct 2002 10:49:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BD1D91303; Fri, 11 Oct 2002 10:49:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDCD691302 for ; Fri, 11 Oct 2002 10:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB63A5DEC7; Fri, 11 Oct 2002 10:47:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id F20BB5DE37 for ; Fri, 11 Oct 2002 10:47:48 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9BElWw13937 for ; Fri, 11 Oct 2002 17:47:32 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Oct 2002 17:43:52 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Oct 2002 17:43:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection Date: Fri, 11 Oct 2002 17:43:51 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E436C@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection Thread-Index: AcJxMGMdBCeVPgikSWCShZKDrPzhRgAALRAw From: To: Cc: X-OriginalArrivalTime: 11 Oct 2002 14:43:51.0542 (UTC) FILETIME=[9D8EE160:01C27134] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA24060 > > This proposal was already discussed sometime ago (named > D-bit)and was rejected because > > the real-time duplicate detection was not seen necessary > > Actually, it was rejected because the proposed solution does not work. So, what you are saying is that existing and deployed GPRS networks with million of subscribers that use exactly the same technique I described to detect duplicate, does not work. Very nice statement, this is like to deny the evidence. You may need to understand better how this work. > In practice, this is very difficult to achieve. All a > Diameter client can > know is that it didn't receive an Application Layer ACK for > the accounting message. > There can be Diameter agents between the client and server, so that > failover is initiated based on "liveness" of the Diameter agent, not > receipt of the application layer ACK. If the Diameter agent > is "live" (as > indicated by receipt of DWRs) then it could be failing over > to a different > accounting server, and the Diameter client will not know it -- and > therefore would be unable to mark the messages appropriately. And of > course, the Diameter client has no visibility into transport behavior > anywhere along the path. If you read better my mail you may find that I'm saying exactly the same thing. "In addition this solution does not solve the problem when relay/redirect agents are between client and server." > Even with no Diameter agents, it is possible that the server > did send the ACK, but somehow it was never received, due to network or > other problems. The Diameter client does not know whether it received > a transport layer ACK for the accounting message, and whether > retransmission > of the accounting message or ACK is occuring at the transport layer. I guess these kind of failure are handled by the transport protocol (i.e. SCTP/TCP). Reliable transport protocols such as SCTP/TCP insure that messages sent by application are received at the other end of the wire (i.e. the associated peer). Only re-transmission of data chunks or message's bytes occur, this is transparent to the application layer that just get the message when the transport layer has successfully received all the bytes of the message. No message duplicate occur in this case. > Based on the server not demonstrating "liveness" (such as > lack of DWRs), > the Diameter client will failover. Since the failover time is > less than TIME_WAIT, it > is conceivable that the failover connection will deliver the > accounting > message (and application layer ACK) and that afterwards an application > layer ACK will finally be received from the failing connection. So in > practice, some sort of search is necessary in any case, within a time > window proportional to TIME_WAIT. Considering the D-bit approach this simply means that D=1 may arrive before D=0. The solution for that is in the proposal I'm gonna send. > Unfortunately, that approach is not reliable, due to the vagaries of > transport behavior -- and it fails completely where Diameter > agents are > deployed. See above. Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11. October 2002 16:12 > To: Stura Marco (NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > > > > A not so clean solution to this problem is the > Re-transmission AVP defined > > in the CC Application that however introduce some challenge > with the management > > of the base protocol pending message queue(i.e. CC messages > in queue need to be > > deleted upon failover/failback execution to avoid their > re-transmission without > > being marked with the AVP). > > In practice, this is very difficult to achieve. All a > Diameter client can > know is that it didn't receive an Application Layer ACK for > the accounting message. > There can be Diameter agents between the client and server, so that > failover is initiated based on "liveness" of the Diameter agent, not > receipt of the application layer ACK. If the Diameter agent > is "live" (as > indicated by receipt of DWRs) then it could be failing over > to a different > accounting server, and the Diameter client will not know it -- and > therefore would be unable to mark the messages appropriately. And of > course, the Diameter client has no visibility into transport behavior > anywhere along the path. > > Even with no Diameter agents, it is possible that the server > did send the ACK, but somehow it was never received, due to network or > other problems. The Diameter client does not know whether it received > a transport layer ACK for the accounting message, and whether > retransmission > of the accounting message or ACK is occuring at the transport layer. > > Based on the server not demonstrating "liveness" (such as > lack of DWRs), > the Diameter client will failover. Since the failover time is > less than TIME_WAIT, it > is conceivable that the failover connection will deliver the > accounting > message (and application layer ACK) and that afterwards an application > layer ACK will finally be received from the failing connection. So in > practice, some sort of search is necessary in any case, within a time > window proportional to TIME_WAIT. > > > The CC servers implementation that decide to use the > Re-transmission AVP will > > search for possible duplicate only when a request message > is received with this > > AVP and not for every single received request. > > Unfortunately, that approach is not reliable, due to the vagaries of > transport behavior -- and it fails completely where Diameter > agents are > deployed. > > > This proposal was already discussed sometime ago (named > D-bit)and was rejected because > > the real-time duplicate detection was not seen necessary > > Actually, it was rejected because the proposed solution does not work. > > > From owner-aaa-wg@merit.edu Fri Oct 11 11:35: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 LAA25671 for ; Fri, 11 Oct 2002 11:35:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3116691303; Fri, 11 Oct 2002 11:37:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EE50D91304; Fri, 11 Oct 2002 11:37:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B826D91303 for ; Fri, 11 Oct 2002 11:37:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9FAE45DE4F; Fri, 11 Oct 2002 11:37:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id B25F65DE45 for ; Fri, 11 Oct 2002 11:37:29 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9BFbDw11089 for ; Fri, 11 Oct 2002 18:37:13 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 11 Oct 2002 18:28:03 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 11 Oct 2002 18:28:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Fri, 11 Oct 2002 18:28:00 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ECF1@esebe016.ntc.nokia.com> Thread-Topic: issue: real-time duplicate detection and proposed change. Thread-Index: AcJxOsaxwon7rUkHSZK9s3MzXelUmw== From: To: , Cc: , , , , X-OriginalArrivalTime: 11 Oct 2002 15:28:00.0431 (UTC) FILETIME=[C86B43F0:01C2713A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA25671 Hi, here is the proposal that address the real-time duplicate detection issue I rised in my previous mail. The proposal is to add the D flag in addition to hashing techniques mentioned in AnnexC. The D flag falls within the "other schemes" category already mentioned in the current base protocol specification. Br Marco et all Description of issue: Real-time duplicate detection Submitter name: Marco Stura Submitter email address: marco.stura@nokia.com Date first submitted: 11/10/2002 Document: draft-ietf-aaa-diameter-13.txt Comment type: T Priority: 1 Section: Insert_Section_Number_Here Rationale/Explanation of issue: I apologize to open this discussion so late but in Nokia we just notice the we have a problem while discussing the possible error cases for the draft Diameter Credit Control Application, which is also used in 3GPP Rel5 IMS (IP Multimedia subsystem) to realize real-time credit based accounting (i.e prepaid accounting, sometime called token based accounting). The problem we have is related to real-time duplicate detection of event accounting request. I briefly summarize the problem below. In Credit Control Application is possible to perform one-time event for three different purposes: direct debiting, refund and balance check. The problem appears with direct debiting and refund. One time event uses accounting request[event] message and basically when the action is direct debiting the corresponding amount of money is directly deducted from the user's account and when the action is refund the corresponding amount of money is credited in the user's account. These use cases require real-time duplicate detection of the received event request in order to avoid multiple debiting or multiple refund for the same request. The duplicate detection must be performed and the proper answer must be given back to the client immediately so as to grant or to not grant the service to the end user. In short, within few seconds the service need to be granted or not granted to the end user, if the end user has to wait too long before being able to use the requested service (e.g. Instant message) the user experience will suffer too much. With the current Diameter base protocol, for every single received request the Credit Control Server would need to search possible duplicate among other request received within a certain backward time window (e.g a day). In current wireless GSM network there are several milion of prepaid subscriber and we have feeling that is an impossible task for the CC server to perform real-time duplicate detection with the mentioned approach, performances will suffer and the answer will be sent too late to the client. Use of hashing techniques or other schemes help to eliminate the need to do full search of received accounting request within a time window as mentioned in AnnexC. However, the hashing approach to address real-time duplicate detection hasn't been tried in practise and hasn't been evaluated in full. We beleive that hashing introduce additional complexity to server implementation and also in finding the proper hashing function, hash table size etc. to minimize for example collision cases. In contrast other techniques for duplicate detection are already used, proven to work and operational in live networks with millions of subscribers(e.g. 3GPP GPRS charging protocol). This techniques consist in the client marking the possible duplicate upon re-transmission of the messages. For those not familiar with this technique I suggest to read the 3GPP technical specifications 32.215 (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). Implementations in 3GPP use this mechanism to also support hot-billing where real-time duplicate detection is required and is proven to work in operational networks. For the above mentioned reasons we think that there might be implementation that do not make use of hashing techniques and that even do not plan to support these techniques in near future. Thus we believe that a more simple tool to enable optimization of real-time duplicate detection should be provided by the base protocol in addition to hashing techniques or other complex schemes that a server may chose to implement. We propose that the base protocol to mark re-transmitted messages by dedicating one reserved bit of the Diameter header to this purpose, server may use D-bit or hashing according to their implementation. Please note that the way the server implement duplicate detection (use of D-bit or not) is implementation dependent and does not affect interoperability at all. This proposal was already discussed sometime ago (named D-bit)and was rejected because the real-time duplicate detection was not seen necessary, we beleive that this requirement is now existing due to the above mentioned reasons and proven to work tool to implement simple real-time duplicate detection in the server (without adding implementation complexity) should be offered by the base protocol. Requested change: Change chapter 3 as follow 3 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E D r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields. Command Flags The Command Flags field is eight bits. The following bits are assigned: R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed. 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 are commonly referred to as an error messages. This bit MUST NOT be set in request messages. See section 7.2. D(uplicate) - If set, the message is a possible duplicate request due to failover/failback process or re-sending of record in storage. This flag MUST NOT be set in answer messages. 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. 5.5.4 Failover and Failback Procedures Change the paragraph When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible. .....etc.. to When a transport failure is detected, all messages in the queue are sent to an alternate agent with the D flag set, if possible. ......etc.. 8.2 Accounting Session State Machine Change the line Idle Records in storage Send PendingB record of CLIENT, ACCOUNTING to Idle Records in storage Send PendingB record with D flag set Change appendix C as follow. Appendix C. Duplicate Detection 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 elimina- tion is easy in this case. In other situations it may be necessary to perform real-time dupli- cate detection, e.g. when the credit limits or fraud attempts are being monitored in real time. In general, only the duplicate generation at failover or re-sending of record in storage cases is something that can be reliably detected by the Diameter client or Diameter agents. In such cases the Diameter client and the Diameter agents mark the request message as possible duplicate by setting the D flag. 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, such as the use of the D flag in the received messages, may be used to eliminate the need to do a full search even in this set except for rare cases. The following is an example of how the D flag may be used by the server to detect duplicate records. Diameter server MAY check the D flag of the received message to determine if this record is a possible duplicate. If the D flag is set in the request message, the server search for the duplicate within the above mentioned time window. This way database search is only required for those received records whose the D flag is set. Since in today networks link failures, server breakdown or other similar events are very rare, this simple approach efficiently optimize performances of the duplicate detection process. It may happen that the original record is received after the D flag marked record because they did experience different delay in their way to the server. For this reason it is necessary for the server to buffer the D flag marked records for a short time period, as an example 10 or 15 minutes, and check every record received within this time period against the buffered D flag marked records. From owner-aaa-wg@merit.edu Fri Oct 11 13:03: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 NAA28181 for ; Fri, 11 Oct 2002 13:03:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD9169121B; Fri, 11 Oct 2002 13:05:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B6E991237; Fri, 11 Oct 2002 13:05:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F6B79121B for ; Fri, 11 Oct 2002 13:05:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 825355DECE; Fri, 11 Oct 2002 13:05:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 021D65DE39 for ; Fri, 11 Oct 2002 13:05:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9BG4Jc00985; Fri, 11 Oct 2002 09:04:19 -0700 Date: Fri, 11 Oct 2002 09:04:19 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: issue: real-time duplicate detection In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E436C@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > You may need to understand better how this work. Since you noted yourself that the proposal does not work at all when Diameter agents are present, I don't think we're in disagreement. > I guess these kind of failure are handled by the transport protocol > (i.e. SCTP/TCP). Reliable transport protocols such as SCTP/TCP insure > that messages sent by application are received at the other end of the > wire (i.e. the associated peer). Actually, they *don't* guarantee this -- that's the problem. If there is a network partition, TCP/SCTP or any other transport protocol can't get through. As Marshall Rose once said "you don't need reliable transport, you need more voltage!" All a TCP acknowledgment tells you is that the segment was received by the TCP on the destination -- it doesn't tell you that the application at the destination received it. So in practice to know that the application received the data, and that it was processed correctly, you need an application layer ACK. > Considering the D-bit approach this simply means that D=1 may arrive > before D=0. The solution for that is in the proposal I'm gonna send. Looking forward to it. From owner-aaa-wg@merit.edu Fri Oct 11 17:29: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 RAA05515 for ; Fri, 11 Oct 2002 17:29:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 182439121D; Fri, 11 Oct 2002 17:31:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE2649122E; Fri, 11 Oct 2002 17:31:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD1CC9121D for ; Fri, 11 Oct 2002 17:31:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC66C5DFB8; Fri, 11 Oct 2002 17:31:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 660AE5DFA8 for ; Fri, 11 Oct 2002 17:31:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9BKUI015586; Fri, 11 Oct 2002 13:30:18 -0700 Date: Fri, 11 Oct 2002 13:30:18 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1DA3ECF1@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Assigned Issue 372. From owner-aaa-wg@merit.edu Fri Oct 11 18:29: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 SAA06330 for ; Fri, 11 Oct 2002 18:29:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1E9F491237; Fri, 11 Oct 2002 18:30:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA81991239; Fri, 11 Oct 2002 18:30:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6ABE91237 for ; Fri, 11 Oct 2002 18:30:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9AD75DE70; Fri, 11 Oct 2002 18:30:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 54D635DF9D for ; Fri, 11 Oct 2002 18:30:55 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9BLTjc18785 for ; Fri, 11 Oct 2002 14:29:45 -0700 Date: Fri, 11 Oct 2002 14:29:45 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG agenda items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk AAA WG will meet at IETF 55. We have one slot. If you have agenda items, please send them to David or myself. From owner-aaa-wg@merit.edu Sun Oct 13 23:19: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 XAA29093 for ; Sun, 13 Oct 2002 23:19:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CDFBD9122A; Sun, 13 Oct 2002 23:21:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91AB791233; Sun, 13 Oct 2002 23:21:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D1819122A for ; Sun, 13 Oct 2002 23:21:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53C4A5DE8F; Sun, 13 Oct 2002 23:21:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by segue.merit.edu (Postfix) with ESMTP id 0BC115DE3C for ; Sun, 13 Oct 2002 23:21:48 -0400 (EDT) Received: from SGOSWAMIPCL ([65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id XAA02245 for ; Sun, 13 Oct 2002 23:21:43 -0400 (EDT) From: "Subrata Goswami" To: Subject: [AAA-WG]: MIP-Session-Key Date: Sun, 13 Oct 2002 20:19:48 -0700 Message-ID: <000e01c27330$934c22a0$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A simple question, the MIP-Session-Key AVP is used in the following AVP's. 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-FA-to-MN-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] It is not very clear how { MIP-Session-Key } are encrypted to provide privacy in transit, what type of keys are used and how are these key's distributed to the AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. Subrata From owner-aaa-wg@merit.edu Mon Oct 14 02:32: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 CAA10798 for ; Mon, 14 Oct 2002 02:32:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77EE291234; Mon, 14 Oct 2002 02:33:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 376629123A; Mon, 14 Oct 2002 02:33:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6CD091234 for ; Mon, 14 Oct 2002 02:33:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD35D5DEC4; Mon, 14 Oct 2002 02:33:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B57935DE76 for ; Mon, 14 Oct 2002 02:33:45 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E6YfK07426 for ; Mon, 14 Oct 2002 09:34:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 09:29:52 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 09:29:52 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Mon, 14 Oct 2002 09:29:51 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A57B9@esebe004.ntc.nokia.com> Thread-Topic: issue: real-time duplicate detection and proposed change. Thread-Index: AcJxOsaxwon7rUkHSZK9s3MzXelUmwCDxmDA From: To: , , Cc: , , , X-OriginalArrivalTime: 14 Oct 2002 06:29:52.0585 (UTC) FILETIME=[1A9A3390:01C2734B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA10798 Hi Marco, What you seem to be indicating is that there are some realtime services that may need to know if a Diameter message has been re-transmitted. Setting of the D-bit allows Diameter peers to know this and possible make decisions based on this. Perhaps the way forward for this dicussion would be to support the d-bit and marking of it when a Diameter re-transmits a message. The behavior of the Diameter peer when recieving such a message could be implementation specific or defined in some alternative Diameter application which specifies the real-time service. I think that supporting real-time services was not a primary consideration of Diamter, when it was first being specified - however, support for real-time services is now a key need of systems deploying Diameter, so it is reasonable to try to support these services. Additionally, the d-bit potentially has other side benefits - collecting statics on messages where the d-bit was set could potentially be useful for network administrators, etc. The alternatives I see are: 1) Not supporting the d-bit. 2) Allow the setting of the d-bit, but either making the response implementation specific or dependent on futher specification. 3) Supporting the d-bit and the behavior of responding to messages with the bit set. I support number 2, as this is a minimal approach - and allows for additional flexibility for future services. In order to close off this issue quickly, it would be good to get feedback on what would be the way forward. thanks, John > -----Original Message----- > From: ext [mailto:marco.stura@nokia.com] > Sent: 11 October, 2002 18:28 > To: aboba@internaut.com; aaa-wg@merit.edu > Cc: Loughney John (NRC/Helsinki); Jari.Arkko@lmf.ericsson.se; > Lialiamou > Elena (NET-IMN/Helsinki); Koskinen Juha-Pekka (NET/Tampere); > Sjoblom Kai > (NET/Helsinki) > Subject: [AAA-WG]: issue: real-time duplicate detection and proposed > change. > > > Hi, > > here is the proposal that address the real-time duplicate > detection issue > I rised in my previous mail. > > The proposal is to add the D flag in addition to hashing > techniques mentioned > in AnnexC. The D flag falls within the "other schemes" > category already > mentioned in the current base protocol specification. > > Br > Marco et all > > > Description of issue: Real-time duplicate detection > Submitter name: Marco Stura > Submitter email address: marco.stura@nokia.com > Date first submitted: 11/10/2002 > Document: draft-ietf-aaa-diameter-13.txt > Comment type: T > Priority: 1 > Section: Insert_Section_Number_Here > Rationale/Explanation of issue: > > I apologize to open this discussion so late but in Nokia we > just notice > the we have a problem while discussing the possible error > cases for the > draft Diameter Credit Control Application, which is also used in 3GPP > Rel5 IMS (IP Multimedia subsystem) to realize real-time credit based > accounting (i.e prepaid accounting, sometime called token > based accounting). > > The problem we have is related to real-time duplicate > detection of event > accounting request. I briefly summarize the problem below. > > In Credit Control Application is possible to perform one-time > event for three > different purposes: direct debiting, refund and balance > check. The problem > appears with direct debiting and refund. > One time event uses accounting request[event] message and > basically when the > action is direct debiting the corresponding amount of money > is directly > deducted from the user's account and when the action is > refund the corresponding > amount of money is credited in the user's account. > > These use cases require real-time duplicate detection of the > received event > request in order to avoid multiple debiting or multiple > refund for the same > request. The duplicate detection must be performed and the > proper answer > must be given back to the client immediately so as to grant > or to not grant > the service to the end user. In short, within few seconds the > service need > to be granted or not granted to the end user, if the end user > has to wait too > long before being able to use the requested service (e.g. > Instant message) > the user experience will suffer too much. > > With the current Diameter base protocol, for every single > received request > the Credit Control Server would need to search possible > duplicate among other > request received within a certain backward time window (e.g a day). > In current wireless GSM network there are several milion of prepaid > subscriber and we have feeling that is an impossible task for > the CC server > to perform real-time duplicate detection with the mentioned approach, > performances will suffer and the answer will be sent too late > to the client. > > Use of hashing techniques or other schemes help to eliminate > the need to do > full search of received accounting request within a time > window as mentioned > in AnnexC. > However, the hashing approach to address real-time duplicate > detection hasn't been > tried in practise and hasn't been evaluated in full. > We beleive that hashing introduce additional complexity to > server implementation and > also in finding the proper hashing function, hash table size > etc. to minimize > for example collision cases. In contrast other techniques for > duplicate detection > are already used, proven to work and operational in live > networks with millions of > subscribers(e.g. 3GPP GPRS charging protocol). > This techniques consist in the client marking the possible > duplicate upon re-transmission > of the messages. For those not familiar with this technique I > suggest to read > the 3GPP technical specifications 32.215 > (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). > Implementations in 3GPP use > this mechanism to also support hot-billing where real-time > duplicate detection > is required and is proven to work in operational networks. > > For the above mentioned reasons we think that there might be > implementation that > do not make use of hashing techniques and that even do not > plan to support these > techniques in near future. > Thus we believe that a more simple tool to enable > optimization of real-time > duplicate detection should be provided by the base protocol > in addition to > hashing techniques or other complex schemes that a server may > chose to implement. > > We propose that the base protocol to mark re-transmitted > messages by dedicating one reserved > bit of the Diameter header to this purpose, server may use > D-bit or hashing according > to their implementation. Please note that the way the server > implement duplicate > detection (use of D-bit or not) is implementation dependent > and does not affect > interoperability at all. > This proposal was already discussed sometime ago (named > D-bit)and was rejected because > the real-time duplicate detection was not seen necessary, we > beleive that this requirement > is now existing due to the above mentioned reasons and proven > to work tool to implement > simple real-time duplicate detection in the server (without > adding implementation complexity) > should be offered by the base protocol. > > > Requested change: > > > Change chapter 3 as follow > > 3 Diameter Header > > A summary of the Diameter header format is shown below. The fields > are transmitted in network byte order. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E D r r r r| Command-Code > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier > | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Version > This Version field MUST be set to 1 to indicate Diameter Version > 1. > > Message Length > The Message Length field is three octets and indicates > the length > of the Diameter message including the header fields. > > Command Flags > The Command Flags field is eight bits. The following bits are > assigned: > > R(equest) - If set, the message is a request. If > cleared, the > message is an answer. > P(roxiable) - If set, the message MAY be proxied, relayed or > redirected. If cleared, the message MUST be > locally processed. > 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 are commonly referred to as an error > messages. This bit MUST NOT be set in request > messages. See section 7.2. > D(uplicate) - If set, the message is a possible > duplicate request > due to failover/failback process > or re-sending of > record in storage. This flag MUST NOT > be set in > answer messages. > > 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. > > 5.5.4 Failover and Failback Procedures > > Change the paragraph > > When a transport failure is detected, all messages in the queue are > sent to an alternate agent, if possible. > .....etc.. > > to > > When a transport failure is detected, all messages in the queue are > sent to an alternate agent with the D flag set, if possible. > ......etc.. > > 8.2 Accounting Session State Machine > > Change the line > > Idle Records in storage Send PendingB > record > > of CLIENT, ACCOUNTING to > > Idle Records in storage Send PendingB > record > with D > flag set > > > Change appendix C as follow. > > Appendix C. Duplicate Detection > > 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 elimina- > tion is easy in this case. > > In other situations it may be necessary to perform real-time dupli- > cate detection, e.g. when the credit limits or fraud attempts are > being monitored in real time. > > In general, only the duplicate generation at failover or > re-sending of > record in storage cases is something that can be reliably > detected by > the Diameter client or Diameter agents. In such cases the Diameter > client and the Diameter agents mark the request message as possible > duplicate by setting the D flag. 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, > such as the use > of the D flag in the received messages, may be used to > eliminate the need > to do a full search even in this set except for rare cases. > > The following is an example of how the D flag may be used > by the server to > detect duplicate records. > > Diameter server MAY check the D flag of the received > message to determine > if this record is a possible duplicate. If the D flag is > set in the request > message, the server search for the duplicate within the > above mentioned time > window. This way database search is only required for > those received records > whose the D flag is set. Since in today networks link > failures, server breakdown > or other similar events are very rare, this simple > approach efficiently > optimize performances of the duplicate detection process. > It may happen that the original record is received after > the D flag marked > record because they did experience different delay in > their way to the > server. For this reason it is necessary for the server to > buffer the D flag > marked records for a short time period, as an example 10 > or 15 minutes, and > check every record received within this time period > against the buffered > D flag marked records. > > From owner-aaa-wg@merit.edu Mon Oct 14 02:35: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 CAA10851 for ; Mon, 14 Oct 2002 02:35:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE0D191210; Mon, 14 Oct 2002 02:37:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8201D9123A; Mon, 14 Oct 2002 02:37:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83F7391210 for ; Mon, 14 Oct 2002 02:37:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76D7B5DEC4; Mon, 14 Oct 2002 02:37:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B50AF5DE76 for ; Mon, 14 Oct 2002 02:37:09 -0400 (EDT) Received: from fmorn1dcode948i (a12.local.ipunplugged.com [192.168.4.182]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g9E6ak24027834; Mon, 14 Oct 2002 08:36:46 +0200 From: "Fredrik Johansson" To: "Subrata Goswami" , Subject: RE: [AAA-WG]: MIP-Session-Key Date: Mon, 14 Oct 2002 08:38:06 +0200 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 In-Reply-To: <000e01c27330$934c22a0$c900a8c0@SGOSWAMIPCL> Importance: Normal X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Subrata, The MIP-Session-Key is encrypted by the hop-by-hop security mechanism (i.e. ipsec or tls) or if there is more than one hop between any of the nodes end-to-end encryption may be used if deemed necessary (e.g. CMS when it becoms standarized). How you set up the hop-by-hop security like ipsec is out of the scope of the diameter protocol /fredrik > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Subrata Goswami > Sent: den 14 oktober 2002 05:20 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: MIP-Session-Key > > > A simple question, the MIP-Session-Key AVP is used in the following > AVP's. > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > It is not very clear how { MIP-Session-Key } are encrypted to provide > privacy in > transit, what type of keys are used and how are these key's distributed > to the > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > Subrata > From owner-aaa-wg@merit.edu Mon Oct 14 03:23: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 DAA11230 for ; Mon, 14 Oct 2002 03:23:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F066B9123A; Mon, 14 Oct 2002 03:25:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AFDEB9123C; Mon, 14 Oct 2002 03:25:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5ECC59123A for ; Mon, 14 Oct 2002 03:24:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4019D5DEBF; Mon, 14 Oct 2002 03:24:59 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 67E005DDFC for ; Mon, 14 Oct 2002 03:24:58 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E7PsK19228 for ; Mon, 14 Oct 2002 10:25:54 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 10:20:45 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 10:20:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection Date: Mon, 14 Oct 2002 10:20:42 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E436E@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection Thread-Index: AcJxSGiP0NzKFZsWSYOB6378X/rSAAB/UO6w From: To: Cc: , X-OriginalArrivalTime: 14 Oct 2002 07:20:44.0678 (UTC) FILETIME=[35CAA260:01C27352] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11230 Hi Bernard; In general, when discussing with you, I can say that you are very good in turning up side down the discussions that I initiate. Busy people receiving hundred of e-mail per day, as high-tech people are, usually don't follow the full mail thread. Instead they read the last received mail, especially if the last mail is an answer of the WG chair. If I say 'You are stupid if you think that Saddam doesn't have nuclear army' and you comment only the statement 'You are stupid' , the readers will simply conclude that I say 'You are stupid' and not only they'll disagree with me but also they'll get very bad feeling about me. This is a good way to mess up discussions and also unfair in the respect of the individual. So , I invite you to comment full stories rather than some incomplete statement picked up at your convenience. You wrote >You may need to understand better how this work. BAb: "Since you noted yourself that the proposal does not work at all when Diameter agents are present, I don't think we're in disagreement." MSt: I noted my self that Re-transmission AVP approach doesn't work when Diameter agents are present. Unfortunately the D-bit approach it does work....and my sentence was referring to that. Also it seems that you don't object anymore that the same technique is used in several operational GPRS networks with millions of subscribers and it works. >I guess these kind of failure are handled by the transport protocol >(i.e. SCTP/TCP). Reliable transport protocols such as SCTP/TCP insure >that messages sent by application are received at the other end of the >wire (i.e. the associated peer). BAb: "Actually, they *don't* guarantee this -- that's the problem. If there is a network partition, TCP/SCTP or any other transport protocol can't get through. As Marshall Rose once said "you don't need reliable transport, you need more voltage!" All a TCP acknowledgment tells you is that the segment was received by the TCP on the destination -- it doesn't tell you that the application at the destination received it. So in practice to know that the application received the data, and that it was processed correctly, you need an application layer ACK." MSt: again you should have answered to the whole paragraph. What I say is that transport layer (SCTP, TCP) never deliver the message to the application layer before all the segments or data chunks have not been succesfully received. And here is my full story again. "I guess these kind of failure are handled by the transport protocol (i.e. SCTP/TCP). Reliable transport protocols such as SCTP/TCP insure that messages sent by application are received at the other end of the wire (i.e. the associated peer). Only re-transmission of data chunks or message's bytes occur, this is transparent to the application layer that just get the message when the transport layer has successfully received all the bytes of the message. No message duplicate occur in this case." No application layer message duplicate occur in this case. And that I need an application ACK to know that the other Diameter peer received the message, well I was not waiting for your lesson to learn that you know... I'm very surprised that you accept a broad statement as the one in AnnexC "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." What does it mean hashing techniques in the context of real-time duplicate detection? does it mean that the full disk database for record storage is built up using hashing techniques ? or does it mean that a hashing table to keep track of the received Session-Ids within e.g one day time window is maintained in RAM memory ? In the latter case is it so that you perform Key== hash(Session-id), you set e.g . 'True' in the bucket identified by the key and you store the record in the database and If the value stored in the bucket was already 'True' you perform disk database search for the possible duplicate ? Well a broad statement that refer to 'hashing technique' does not suffice in a technical specification . You should also recommend the hashing function to be used to minimize collision cases, with the relevant arguments, the proper hashing algorithm as well as the proper criteria to select the table size etc. and don't say that you can find the proper hashing function to be applied to Session-id from the literature, this would sound like a political answer to a technical problem (i.e. not a solution). I don't know what it could be the hashing function but let's try to analyze what size the hashing table might be considering the multimedia messaging use case. Currently in GSM networks people send in average 1 SMS per hour. If your server need to handle 4 millions of prepaid subscribers it means that in 24 hours it will get 4*24=96 millions requests. If we consider a Key of 32-bits(4 bytes) the hashing table should be 96*4= around 370MB. Now if we want to limit the risk of collision we may double the size to reduce to load factor 370*2=740MB. But I just considered one service, if we consider other services as well we can safely assume 2 or even 3 requests per hour per subscriber. Just with 2 requests per hour the size would double to 740*2= aroun 1.5GB in addition to the disk database. Well, to me it sounds quite huge amount of memory. Moreover, the hashing approach to address real-time duplicate detection hasn't been tried in practise and hasn't been evaluated in full so I don't see any good technical reason why the broad statement referring to hashing techniques is in and a proven to work and widely deployed technique for duplicate detection that falls within 'other schemes' category is out a priori. Since the Diameter protocol is gonna be used as accounting protocol to deploy real-time prepaid services ,I just would insure that the protocol offers the required tool to properly perform simple real-time duplicate detection without placing huge memory amount requirement to implementation. In conclusion my proposal is then to include the Issue 372 proposed changes to the base protocol specification (base 14), which in light of the above adding D flag approach in addition to hushing techniques is just question of common sense nothing more nothing less. With my best regards Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 11. October 2002 19:04 > To: Stura Marco (NET/Helsinki) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > > > You may need to understand better how this work. > > Since you noted yourself that the proposal does not work at all > when Diameter agents are present, I don't think we're in disagreement. > > > I guess these kind of failure are handled by the transport protocol > > (i.e. SCTP/TCP). Reliable transport protocols such as > SCTP/TCP insure > > that messages sent by application are received at the other > end of the > > wire (i.e. the associated peer). > > Actually, they *don't* guarantee this -- that's the problem. > If there is a > network partition, TCP/SCTP or any other transport protocol can't get > through. As Marshall Rose once said "you don't need reliable > transport, > you need more voltage!" > > All a TCP acknowledgment tells you is that the segment was > received by the > TCP on the destination -- it doesn't tell you that the > application at the > destination received it. > > So in practice to know that the application received the > data, and that > it was processed correctly, you need an application layer ACK. > > > Considering the D-bit approach this simply means that D=1 may arrive > > before D=0. The solution for that is in the proposal I'm gonna send. > > Looking forward to it. > > From owner-aaa-wg@merit.edu Mon Oct 14 03:44: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 DAA11482 for ; Mon, 14 Oct 2002 03:44:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C1B79123C; Mon, 14 Oct 2002 03:46:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C98339123D; Mon, 14 Oct 2002 03:46:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DAEF9123C for ; Mon, 14 Oct 2002 03:46:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AE285DEC9; Mon, 14 Oct 2002 03:46:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 0AAA35DDFC for ; Mon, 14 Oct 2002 03:46:22 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E7lHK11026 for ; Mon, 14 Oct 2002 10:47:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 10:45:09 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 10:45:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Mon, 14 Oct 2002 10:45:08 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E436F@esebe016.ntc.nokia.com> Thread-Topic: issue: real-time duplicate detection and proposed change. Thread-Index: AcJxOsaxwon7rUkHSZK9s3MzXelUmwCDxmDAAAIsqFA= From: To: , , Cc: , , X-OriginalArrivalTime: 14 Oct 2002 07:45:08.0584 (UTC) FILETIME=[9E58F680:01C27355] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11482 Hi John; I support number 2 as well. Actually my proposal in Issue 372 is exactly that one, client and agents setting the D flag when failover/failback occur and client to set the D flag also when re-sending stored records. I'm not proposing the server to answer differently if the D flag was set in the request and the Server MAY use the D flag for duplicate detection if so required by the Server implementation. Br Marco > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 14. October 2002 9:30 > To: Stura Marco (NET/Helsinki); aboba@internaut.com; aaa-wg@merit.edu > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > Koskinen Juha-Pekka (NET/Tampere); Sjoblom Kai (NET/Helsinki) > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > Hi Marco, > > What you seem to be indicating is that there are some > realtime services > that may need to know if a Diameter message has been re-transmitted. > Setting of the D-bit allows Diameter peers to know this and possible > make decisions based on this. > > Perhaps the way forward for this dicussion would be to > support the d-bit > and marking of it when a Diameter re-transmits a message. > The behavior > of the Diameter peer when recieving such a message could be > implementation > specific or defined in some alternative Diameter application which > specifies the real-time service. > > I think that supporting real-time services was not a primary > consideration > of Diamter, when it was first being specified - however, support for > real-time services is now a key need of systems deploying Diameter, so > it is reasonable to try to support these services. > > Additionally, the d-bit potentially has other side benefits - > collecting > statics on messages where the d-bit was set could potentially > be useful > for network administrators, etc. > > The alternatives I see are: > > 1) Not supporting the d-bit. > 2) Allow the setting of the d-bit, but either making > the response > implementation specific or dependent on futher > specification. > 3) Supporting the d-bit and the behavior of responding > to messages > with the bit set. > > I support number 2, as this is a minimal approach - and > allows for additional > flexibility for future services. > > In order to close off this issue quickly, it would be good to > get feedback on > what would be the way forward. > > thanks, > John > > > > > -----Original Message----- > > From: ext [mailto:marco.stura@nokia.com] > > Sent: 11 October, 2002 18:28 > > To: aboba@internaut.com; aaa-wg@merit.edu > > Cc: Loughney John (NRC/Helsinki); Jari.Arkko@lmf.ericsson.se; > > Lialiamou > > Elena (NET-IMN/Helsinki); Koskinen Juha-Pekka (NET/Tampere); > > Sjoblom Kai > > (NET/Helsinki) > > Subject: [AAA-WG]: issue: real-time duplicate detection and proposed > > change. > > > > > > Hi, > > > > here is the proposal that address the real-time duplicate > > detection issue > > I rised in my previous mail. > > > > The proposal is to add the D flag in addition to hashing > > techniques mentioned > > in AnnexC. The D flag falls within the "other schemes" > > category already > > mentioned in the current base protocol specification. > > > > Br > > Marco et all > > > > > > Description of issue: Real-time duplicate detection > > Submitter name: Marco Stura > > Submitter email address: marco.stura@nokia.com > > Date first submitted: 11/10/2002 > > Document: draft-ietf-aaa-diameter-13.txt > > Comment type: T > > Priority: 1 > > Section: Insert_Section_Number_Here > > Rationale/Explanation of issue: > > > > I apologize to open this discussion so late but in Nokia we > > just notice > > the we have a problem while discussing the possible error > > cases for the > > draft Diameter Credit Control Application, which is also > used in 3GPP > > Rel5 IMS (IP Multimedia subsystem) to realize real-time > credit based > > accounting (i.e prepaid accounting, sometime called token > > based accounting). > > > > The problem we have is related to real-time duplicate > > detection of event > > accounting request. I briefly summarize the problem below. > > > > In Credit Control Application is possible to perform one-time > > event for three > > different purposes: direct debiting, refund and balance > > check. The problem > > appears with direct debiting and refund. > > One time event uses accounting request[event] message and > > basically when the > > action is direct debiting the corresponding amount of money > > is directly > > deducted from the user's account and when the action is > > refund the corresponding > > amount of money is credited in the user's account. > > > > These use cases require real-time duplicate detection of the > > received event > > request in order to avoid multiple debiting or multiple > > refund for the same > > request. The duplicate detection must be performed and the > > proper answer > > must be given back to the client immediately so as to grant > > or to not grant > > the service to the end user. In short, within few seconds the > > service need > > to be granted or not granted to the end user, if the end user > > has to wait too > > long before being able to use the requested service (e.g. > > Instant message) > > the user experience will suffer too much. > > > > With the current Diameter base protocol, for every single > > received request > > the Credit Control Server would need to search possible > > duplicate among other > > request received within a certain backward time window (e.g a day). > > In current wireless GSM network there are several milion of prepaid > > subscriber and we have feeling that is an impossible task for > > the CC server > > to perform real-time duplicate detection with the mentioned > approach, > > performances will suffer and the answer will be sent too late > > to the client. > > > > Use of hashing techniques or other schemes help to eliminate > > the need to do > > full search of received accounting request within a time > > window as mentioned > > in AnnexC. > > However, the hashing approach to address real-time duplicate > > detection hasn't been > > tried in practise and hasn't been evaluated in full. > > We beleive that hashing introduce additional complexity to > > server implementation and > > also in finding the proper hashing function, hash table size > > etc. to minimize > > for example collision cases. In contrast other techniques for > > duplicate detection > > are already used, proven to work and operational in live > > networks with millions of > > subscribers(e.g. 3GPP GPRS charging protocol). > > This techniques consist in the client marking the possible > > duplicate upon re-transmission > > of the messages. For those not familiar with this technique I > > suggest to read > > the 3GPP technical specifications 32.215 > > (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). > > Implementations in 3GPP use > > this mechanism to also support hot-billing where real-time > > duplicate detection > > is required and is proven to work in operational networks. > > > > For the above mentioned reasons we think that there might be > > implementation that > > do not make use of hashing techniques and that even do not > > plan to support these > > techniques in near future. > > Thus we believe that a more simple tool to enable > > optimization of real-time > > duplicate detection should be provided by the base protocol > > in addition to > > hashing techniques or other complex schemes that a server may > > chose to implement. > > > > We propose that the base protocol to mark re-transmitted > > messages by dedicating one reserved > > bit of the Diameter header to this purpose, server may use > > D-bit or hashing according > > to their implementation. Please note that the way the server > > implement duplicate > > detection (use of D-bit or not) is implementation dependent > > and does not affect > > interoperability at all. > > This proposal was already discussed sometime ago (named > > D-bit)and was rejected because > > the real-time duplicate detection was not seen necessary, we > > beleive that this requirement > > is now existing due to the above mentioned reasons and proven > > to work tool to implement > > simple real-time duplicate detection in the server (without > > adding implementation complexity) > > should be offered by the base protocol. > > > > > > Requested change: > > > > > > Change chapter 3 as follow > > > > 3 Diameter Header > > > > A summary of the Diameter header format is shown below. > The fields > > are transmitted in network byte order. > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ver | Message Length > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E D r r r r| Command-Code > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Application-ID > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hop-by-Hop Identifier > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | End-to-End Identifier > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Version > > This Version field MUST be set to 1 to indicate > Diameter Version > > 1. > > > > Message Length > > The Message Length field is three octets and indicates > > the length > > of the Diameter message including the header fields. > > > > Command Flags > > The Command Flags field is eight bits. The following bits are > > assigned: > > > > R(equest) - If set, the message is a request. If > > cleared, the > > message is an answer. > > P(roxiable) - If set, the message MAY be proxied, > relayed or > > redirected. If cleared, the message MUST be > > locally processed. > > 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 are commonly referred to as an error > > messages. This bit MUST NOT be set in request > > messages. See section 7.2. > > D(uplicate) - If set, the message is a possible > > duplicate request > > due to failover/failback process > > or re-sending of > > record in storage. This flag MUST NOT > > be set in > > answer messages. > > > > 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. > > > > 5.5.4 Failover and Failback Procedures > > > > Change the paragraph > > > > When a transport failure is detected, all messages in the > queue are > > sent to an alternate agent, if possible. > > .....etc.. > > > > to > > > > When a transport failure is detected, all messages in the > queue are > > sent to an alternate agent with the D flag set, if possible. > > ......etc.. > > > > 8.2 Accounting Session State Machine > > > > Change the line > > > > Idle Records in storage Send PendingB > > record > > > > of CLIENT, ACCOUNTING to > > > > Idle Records in storage Send PendingB > > record > > with D > > flag set > > > > > > Change appendix C as follow. > > > > Appendix C. Duplicate Detection > > > > 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 elimina- > > tion is easy in this case. > > > > In other situations it may be necessary to perform > real-time dupli- > > cate detection, e.g. when the credit limits or fraud attempts are > > being monitored in real time. > > > > In general, only the duplicate generation at failover or > > re-sending of > > record in storage cases is something that can be reliably > > detected by > > the Diameter client or Diameter agents. In such cases > the Diameter > > client and the Diameter agents mark the request message > as possible > > duplicate by setting the D flag. 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, > > such as the use > > of the D flag in the received messages, may be used to > > eliminate the need > > to do a full search even in this set except for rare cases. > > > > The following is an example of how the D flag may be used > > by the server to > > detect duplicate records. > > > > Diameter server MAY check the D flag of the received > > message to determine > > if this record is a possible duplicate. If the D flag is > > set in the request > > message, the server search for the duplicate within the > > above mentioned time > > window. This way database search is only required for > > those received records > > whose the D flag is set. Since in today networks link > > failures, server breakdown > > or other similar events are very rare, this simple > > approach efficiently > > optimize performances of the duplicate detection process. > > It may happen that the original record is received after > > the D flag marked > > record because they did experience different delay in > > their way to the > > server. For this reason it is necessary for the server to > > buffer the D flag > > marked records for a short time period, as an example 10 > > or 15 minutes, and > > check every record received within this time period > > against the buffered > > D flag marked records. > > > > > From owner-aaa-wg@merit.edu Mon Oct 14 03:59: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 DAA11782 for ; Mon, 14 Oct 2002 03:59:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8FFE9123D; Mon, 14 Oct 2002 04:01:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 669819123E; Mon, 14 Oct 2002 04:01:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B3949123D for ; Mon, 14 Oct 2002 04:01:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2BE25DECF; Mon, 14 Oct 2002 04:01:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B42B35DDFC for ; Mon, 14 Oct 2002 04:01:41 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E82bK25419 for ; Mon, 14 Oct 2002 11:02:37 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 11:01:39 +0300 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 11:01:37 +0300 Received: from trebe002.NOE.Nokia.com ([172.22.232.173]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 11:01:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Mon, 14 Oct 2002 11:01:36 +0300 Message-ID: <0AA9E01B31168E42A308714A6EF271840256C2C3@trebe002.europe.nokia.com> Thread-Topic: issue: real-time duplicate detection and proposed change. Thread-Index: AcJxOsaxwon7rUkHSZK9s3MzXelUmwCDxmDAAAIsqFAAASf3YA== From: To: , , , Cc: , X-OriginalArrivalTime: 14 Oct 2002 08:01:36.0941 (UTC) FILETIME=[EB7445D0:01C27357] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA11782 Hi, I support number 2 with remark that server should answer normally also to requests where d-bit is set. br, JPK -----Original Message----- From: ext [mailto:marco.stura@nokia.com] Sent: 14. October 2002 10:45 To: Loughney John (NRC/Helsinki); aboba@internaut.com; aaa-wg@merit.edu Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); Koskinen Juha-Pekka (NET/Tampere) Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Hi John; I support number 2 as well. Actually my proposal in Issue 372 is exactly that one, client and agents setting the D flag when failover/failback occur and client to set the D flag also when re-sending stored records. I'm not proposing the server to answer differently if the D flag was set in the request and the Server MAY use the D flag for duplicate detection if so required by the Server implementation. Br Marco > -----Original Message----- > From: Loughney John (NRC/Helsinki) > Sent: 14. October 2002 9:30 > To: Stura Marco (NET/Helsinki); aboba@internaut.com; aaa-wg@merit.edu > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > Koskinen Juha-Pekka (NET/Tampere); Sjoblom Kai (NET/Helsinki) > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > Hi Marco, > > What you seem to be indicating is that there are some > realtime services > that may need to know if a Diameter message has been re-transmitted. > Setting of the D-bit allows Diameter peers to know this and possible > make decisions based on this. > > Perhaps the way forward for this dicussion would be to > support the d-bit > and marking of it when a Diameter re-transmits a message. > The behavior > of the Diameter peer when recieving such a message could be > implementation > specific or defined in some alternative Diameter application which > specifies the real-time service. > > I think that supporting real-time services was not a primary > consideration > of Diamter, when it was first being specified - however, support for > real-time services is now a key need of systems deploying Diameter, so > it is reasonable to try to support these services. > > Additionally, the d-bit potentially has other side benefits - > collecting > statics on messages where the d-bit was set could potentially > be useful > for network administrators, etc. > > The alternatives I see are: > > 1) Not supporting the d-bit. > 2) Allow the setting of the d-bit, but either making > the response > implementation specific or dependent on futher > specification. > 3) Supporting the d-bit and the behavior of responding > to messages > with the bit set. > > I support number 2, as this is a minimal approach - and > allows for additional > flexibility for future services. > > In order to close off this issue quickly, it would be good to > get feedback on > what would be the way forward. > > thanks, > John > > > > > -----Original Message----- > > From: ext [mailto:marco.stura@nokia.com] > > Sent: 11 October, 2002 18:28 > > To: aboba@internaut.com; aaa-wg@merit.edu > > Cc: Loughney John (NRC/Helsinki); Jari.Arkko@lmf.ericsson.se; > > Lialiamou > > Elena (NET-IMN/Helsinki); Koskinen Juha-Pekka (NET/Tampere); > > Sjoblom Kai > > (NET/Helsinki) > > Subject: [AAA-WG]: issue: real-time duplicate detection and proposed > > change. > > > > > > Hi, > > > > here is the proposal that address the real-time duplicate > > detection issue > > I rised in my previous mail. > > > > The proposal is to add the D flag in addition to hashing > > techniques mentioned > > in AnnexC. The D flag falls within the "other schemes" > > category already > > mentioned in the current base protocol specification. > > > > Br > > Marco et all > > > > > > Description of issue: Real-time duplicate detection > > Submitter name: Marco Stura > > Submitter email address: marco.stura@nokia.com > > Date first submitted: 11/10/2002 > > Document: draft-ietf-aaa-diameter-13.txt > > Comment type: T > > Priority: 1 > > Section: Insert_Section_Number_Here > > Rationale/Explanation of issue: > > > > I apologize to open this discussion so late but in Nokia we > > just notice > > the we have a problem while discussing the possible error > > cases for the > > draft Diameter Credit Control Application, which is also > used in 3GPP > > Rel5 IMS (IP Multimedia subsystem) to realize real-time > credit based > > accounting (i.e prepaid accounting, sometime called token > > based accounting). > > > > The problem we have is related to real-time duplicate > > detection of event > > accounting request. I briefly summarize the problem below. > > > > In Credit Control Application is possible to perform one-time > > event for three > > different purposes: direct debiting, refund and balance > > check. The problem > > appears with direct debiting and refund. > > One time event uses accounting request[event] message and > > basically when the > > action is direct debiting the corresponding amount of money > > is directly > > deducted from the user's account and when the action is > > refund the corresponding > > amount of money is credited in the user's account. > > > > These use cases require real-time duplicate detection of the > > received event > > request in order to avoid multiple debiting or multiple > > refund for the same > > request. The duplicate detection must be performed and the > > proper answer > > must be given back to the client immediately so as to grant > > or to not grant > > the service to the end user. In short, within few seconds the > > service need > > to be granted or not granted to the end user, if the end user > > has to wait too > > long before being able to use the requested service (e.g. > > Instant message) > > the user experience will suffer too much. > > > > With the current Diameter base protocol, for every single > > received request > > the Credit Control Server would need to search possible > > duplicate among other > > request received within a certain backward time window (e.g a day). > > In current wireless GSM network there are several milion of prepaid > > subscriber and we have feeling that is an impossible task for > > the CC server > > to perform real-time duplicate detection with the mentioned > approach, > > performances will suffer and the answer will be sent too late > > to the client. > > > > Use of hashing techniques or other schemes help to eliminate > > the need to do > > full search of received accounting request within a time > > window as mentioned > > in AnnexC. > > However, the hashing approach to address real-time duplicate > > detection hasn't been > > tried in practise and hasn't been evaluated in full. > > We beleive that hashing introduce additional complexity to > > server implementation and > > also in finding the proper hashing function, hash table size > > etc. to minimize > > for example collision cases. In contrast other techniques for > > duplicate detection > > are already used, proven to work and operational in live > > networks with millions of > > subscribers(e.g. 3GPP GPRS charging protocol). > > This techniques consist in the client marking the possible > > duplicate upon re-transmission > > of the messages. For those not familiar with this technique I > > suggest to read > > the 3GPP technical specifications 32.215 > > (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). > > Implementations in 3GPP use > > this mechanism to also support hot-billing where real-time > > duplicate detection > > is required and is proven to work in operational networks. > > > > For the above mentioned reasons we think that there might be > > implementation that > > do not make use of hashing techniques and that even do not > > plan to support these > > techniques in near future. > > Thus we believe that a more simple tool to enable > > optimization of real-time > > duplicate detection should be provided by the base protocol > > in addition to > > hashing techniques or other complex schemes that a server may > > chose to implement. > > > > We propose that the base protocol to mark re-transmitted > > messages by dedicating one reserved > > bit of the Diameter header to this purpose, server may use > > D-bit or hashing according > > to their implementation. Please note that the way the server > > implement duplicate > > detection (use of D-bit or not) is implementation dependent > > and does not affect > > interoperability at all. > > This proposal was already discussed sometime ago (named > > D-bit)and was rejected because > > the real-time duplicate detection was not seen necessary, we > > beleive that this requirement > > is now existing due to the above mentioned reasons and proven > > to work tool to implement > > simple real-time duplicate detection in the server (without > > adding implementation complexity) > > should be offered by the base protocol. > > > > > > Requested change: > > > > > > Change chapter 3 as follow > > > > 3 Diameter Header > > > > A summary of the Diameter header format is shown below. > The fields > > are transmitted in network byte order. > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > 6 7 8 9 0 1 > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ver | Message Length > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E D r r r r| Command-Code > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Application-ID > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hop-by-Hop Identifier > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | End-to-End Identifier > > | > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > Version > > This Version field MUST be set to 1 to indicate > Diameter Version > > 1. > > > > Message Length > > The Message Length field is three octets and indicates > > the length > > of the Diameter message including the header fields. > > > > Command Flags > > The Command Flags field is eight bits. The following bits are > > assigned: > > > > R(equest) - If set, the message is a request. If > > cleared, the > > message is an answer. > > P(roxiable) - If set, the message MAY be proxied, > relayed or > > redirected. If cleared, the message MUST be > > locally processed. > > 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 are commonly referred to as an error > > messages. This bit MUST NOT be set in request > > messages. See section 7.2. > > D(uplicate) - If set, the message is a possible > > duplicate request > > due to failover/failback process > > or re-sending of > > record in storage. This flag MUST NOT > > be set in > > answer messages. > > > > 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. > > > > 5.5.4 Failover and Failback Procedures > > > > Change the paragraph > > > > When a transport failure is detected, all messages in the > queue are > > sent to an alternate agent, if possible. > > .....etc.. > > > > to > > > > When a transport failure is detected, all messages in the > queue are > > sent to an alternate agent with the D flag set, if possible. > > ......etc.. > > > > 8.2 Accounting Session State Machine > > > > Change the line > > > > Idle Records in storage Send PendingB > > record > > > > of CLIENT, ACCOUNTING to > > > > Idle Records in storage Send PendingB > > record > > with D > > flag set > > > > > > Change appendix C as follow. > > > > Appendix C. Duplicate Detection > > > > 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 elimina- > > tion is easy in this case. > > > > In other situations it may be necessary to perform > real-time dupli- > > cate detection, e.g. when the credit limits or fraud attempts are > > being monitored in real time. > > > > In general, only the duplicate generation at failover or > > re-sending of > > record in storage cases is something that can be reliably > > detected by > > the Diameter client or Diameter agents. In such cases > the Diameter > > client and the Diameter agents mark the request message > as possible > > duplicate by setting the D flag. 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, > > such as the use > > of the D flag in the received messages, may be used to > > eliminate the need > > to do a full search even in this set except for rare cases. > > > > The following is an example of how the D flag may be used > > by the server to > > detect duplicate records. > > > > Diameter server MAY check the D flag of the received > > message to determine > > if this record is a possible duplicate. If the D flag is > > set in the request > > message, the server search for the duplicate within the > > above mentioned time > > window. This way database search is only required for > > those received records > > whose the D flag is set. Since in today networks link > > failures, server breakdown > > or other similar events are very rare, this simple > > approach efficiently > > optimize performances of the duplicate detection process. > > It may happen that the original record is received after > > the D flag marked > > record because they did experience different delay in > > their way to the > > server. For this reason it is necessary for the server to > > buffer the D flag > > marked records for a short time period, as an example 10 > > or 15 minutes, and > > check every record received within this time period > > against the buffered > > D flag marked records. > > > > > From owner-aaa-wg@merit.edu Mon Oct 14 05:38: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 FAA13084 for ; Mon, 14 Oct 2002 05:38:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 90D4B9123E; Mon, 14 Oct 2002 05:40:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A92C9123F; Mon, 14 Oct 2002 05:40:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 138489123E for ; Mon, 14 Oct 2002 05:40:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC97B5DEDD; Mon, 14 Oct 2002 05:40:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id CB6345DED9 for ; Mon, 14 Oct 2002 05:40:37 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9E9eKw18418 for ; Mon, 14 Oct 2002 12:40:20 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 12:40:36 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 12:40:35 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 12:40:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Mon, 14 Oct 2002 12:40:33 +0300 Message-ID: <93532512B06FC3489824C18037DB3D4B012A9CB7@esebe015.ntc.nokia.com> Thread-Topic: issue: real-time duplicate detection and proposed change. Thread-Index: AcJxOsaxwon7rUkHSZK9s3MzXelUmwCDxmDAAAIsqFAAASf3YAADlvPg From: To: , , , , Cc: X-OriginalArrivalTime: 14 Oct 2002 09:40:34.0869 (UTC) FILETIME=[BEBC2E50:01C27365] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA13084 Hi, I also support number 2 proposal on the issue. BR Elena > -----Original Message----- > From: ext [mailto:juha-pekka.koskinen@nokia.com] > Sent: 14. October 2002 11:02 > To: Stura Marco (NET/Helsinki); Loughney John (NRC/Helsinki); > aboba@internaut.com; aaa-wg@merit.edu > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki) > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > Hi, > > I support number 2 with remark that server should answer > normally also to requests where d-bit is set. > > br, > JPK > > -----Original Message----- > From: ext [mailto:marco.stura@nokia.com] > Sent: 14. October 2002 10:45 > To: Loughney John (NRC/Helsinki); aboba@internaut.com; > aaa-wg@merit.edu > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > Koskinen Juha-Pekka (NET/Tampere) > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > Hi John; > > I support number 2 as well. > > Actually my proposal in Issue 372 is exactly that one, client > and agents setting > the D flag when failover/failback occur and client to set the > D flag also when > re-sending stored records. I'm not proposing the server to > answer differently if > the D flag was set in the request and the Server MAY use the > D flag for duplicate > detection if so required by the Server implementation. > > Br > Marco > > > -----Original Message----- > > From: Loughney John (NRC/Helsinki) > > Sent: 14. October 2002 9:30 > > To: Stura Marco (NET/Helsinki); aboba@internaut.com; > aaa-wg@merit.edu > > Cc: Jari.Arkko@lmf.ericsson.se; Lialiamou Elena (NET-IMN/Helsinki); > > Koskinen Juha-Pekka (NET/Tampere); Sjoblom Kai (NET/Helsinki) > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed > > change. > > > > > > Hi Marco, > > > > What you seem to be indicating is that there are some > > realtime services > > that may need to know if a Diameter message has been re-transmitted. > > Setting of the D-bit allows Diameter peers to know this and possible > > make decisions based on this. > > > > Perhaps the way forward for this dicussion would be to > > support the d-bit > > and marking of it when a Diameter re-transmits a message. > > The behavior > > of the Diameter peer when recieving such a message could be > > implementation > > specific or defined in some alternative Diameter application which > > specifies the real-time service. > > > > I think that supporting real-time services was not a primary > > consideration > > of Diamter, when it was first being specified - however, support for > > real-time services is now a key need of systems deploying > Diameter, so > > it is reasonable to try to support these services. > > > > Additionally, the d-bit potentially has other side benefits - > > collecting > > statics on messages where the d-bit was set could potentially > > be useful > > for network administrators, etc. > > > > The alternatives I see are: > > > > 1) Not supporting the d-bit. > > 2) Allow the setting of the d-bit, but either making > > the response > > implementation specific or dependent on futher > > specification. > > 3) Supporting the d-bit and the behavior of responding > > to messages > > with the bit set. > > > > I support number 2, as this is a minimal approach - and > > allows for additional > > flexibility for future services. > > > > In order to close off this issue quickly, it would be good to > > get feedback on > > what would be the way forward. > > > > thanks, > > John > > > > > > > > > -----Original Message----- > > > From: ext [mailto:marco.stura@nokia.com] > > > Sent: 11 October, 2002 18:28 > > > To: aboba@internaut.com; aaa-wg@merit.edu > > > Cc: Loughney John (NRC/Helsinki); Jari.Arkko@lmf.ericsson.se; > > > Lialiamou > > > Elena (NET-IMN/Helsinki); Koskinen Juha-Pekka (NET/Tampere); > > > Sjoblom Kai > > > (NET/Helsinki) > > > Subject: [AAA-WG]: issue: real-time duplicate detection > and proposed > > > change. > > > > > > > > > Hi, > > > > > > here is the proposal that address the real-time duplicate > > > detection issue > > > I rised in my previous mail. > > > > > > The proposal is to add the D flag in addition to hashing > > > techniques mentioned > > > in AnnexC. The D flag falls within the "other schemes" > > > category already > > > mentioned in the current base protocol specification. > > > > > > Br > > > Marco et all > > > > > > > > > Description of issue: Real-time duplicate detection > > > Submitter name: Marco Stura > > > Submitter email address: marco.stura@nokia.com > > > Date first submitted: 11/10/2002 > > > Document: draft-ietf-aaa-diameter-13.txt > > > Comment type: T > > > Priority: 1 > > > Section: Insert_Section_Number_Here > > > Rationale/Explanation of issue: > > > > > > I apologize to open this discussion so late but in Nokia we > > > just notice > > > the we have a problem while discussing the possible error > > > cases for the > > > draft Diameter Credit Control Application, which is also > > used in 3GPP > > > Rel5 IMS (IP Multimedia subsystem) to realize real-time > > credit based > > > accounting (i.e prepaid accounting, sometime called token > > > based accounting). > > > > > > The problem we have is related to real-time duplicate > > > detection of event > > > accounting request. I briefly summarize the problem below. > > > > > > In Credit Control Application is possible to perform one-time > > > event for three > > > different purposes: direct debiting, refund and balance > > > check. The problem > > > appears with direct debiting and refund. > > > One time event uses accounting request[event] message and > > > basically when the > > > action is direct debiting the corresponding amount of money > > > is directly > > > deducted from the user's account and when the action is > > > refund the corresponding > > > amount of money is credited in the user's account. > > > > > > These use cases require real-time duplicate detection of the > > > received event > > > request in order to avoid multiple debiting or multiple > > > refund for the same > > > request. The duplicate detection must be performed and the > > > proper answer > > > must be given back to the client immediately so as to grant > > > or to not grant > > > the service to the end user. In short, within few seconds the > > > service need > > > to be granted or not granted to the end user, if the end user > > > has to wait too > > > long before being able to use the requested service (e.g. > > > Instant message) > > > the user experience will suffer too much. > > > > > > With the current Diameter base protocol, for every single > > > received request > > > the Credit Control Server would need to search possible > > > duplicate among other > > > request received within a certain backward time window > (e.g a day). > > > In current wireless GSM network there are several milion > of prepaid > > > subscriber and we have feeling that is an impossible task for > > > the CC server > > > to perform real-time duplicate detection with the mentioned > > approach, > > > performances will suffer and the answer will be sent too late > > > to the client. > > > > > > Use of hashing techniques or other schemes help to eliminate > > > the need to do > > > full search of received accounting request within a time > > > window as mentioned > > > in AnnexC. > > > However, the hashing approach to address real-time duplicate > > > detection hasn't been > > > tried in practise and hasn't been evaluated in full. > > > We beleive that hashing introduce additional complexity to > > > server implementation and > > > also in finding the proper hashing function, hash table size > > > etc. to minimize > > > for example collision cases. In contrast other techniques for > > > duplicate detection > > > are already used, proven to work and operational in live > > > networks with millions of > > > subscribers(e.g. 3GPP GPRS charging protocol). > > > This techniques consist in the client marking the possible > > > duplicate upon re-transmission > > > of the messages. For those not familiar with this technique I > > > suggest to read > > > the 3GPP technical specifications 32.215 > > > (http://www.3gpp.org/ftp/Specs/archive/32_series/32.215/). > > > Implementations in 3GPP use > > > this mechanism to also support hot-billing where real-time > > > duplicate detection > > > is required and is proven to work in operational networks. > > > > > > For the above mentioned reasons we think that there might be > > > implementation that > > > do not make use of hashing techniques and that even do not > > > plan to support these > > > techniques in near future. > > > Thus we believe that a more simple tool to enable > > > optimization of real-time > > > duplicate detection should be provided by the base protocol > > > in addition to > > > hashing techniques or other complex schemes that a server may > > > chose to implement. > > > > > > We propose that the base protocol to mark re-transmitted > > > messages by dedicating one reserved > > > bit of the Diameter header to this purpose, server may use > > > D-bit or hashing according > > > to their implementation. Please note that the way the server > > > implement duplicate > > > detection (use of D-bit or not) is implementation dependent > > > and does not affect > > > interoperability at all. > > > This proposal was already discussed sometime ago (named > > > D-bit)and was rejected because > > > the real-time duplicate detection was not seen necessary, we > > > beleive that this requirement > > > is now existing due to the above mentioned reasons and proven > > > to work tool to implement > > > simple real-time duplicate detection in the server (without > > > adding implementation complexity) > > > should be offered by the base protocol. > > > > > > > > > Requested change: > > > > > > > > > Change chapter 3 as follow > > > > > > 3 Diameter Header > > > > > > A summary of the Diameter header format is shown below. > > The fields > > > are transmitted in network byte order. > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > > 6 7 8 9 0 1 > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Ver | Message Length > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > |R P E D r r r r| Command-Code > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Application-ID > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Hop-by-Hop Identifier > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | End-to-End Identifier > > > | > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | AVPs ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > > > Version > > > This Version field MUST be set to 1 to indicate > > Diameter Version > > > 1. > > > > > > Message Length > > > The Message Length field is three octets and indicates > > > the length > > > of the Diameter message including the header fields. > > > > > > Command Flags > > > The Command Flags field is eight bits. The > following bits are > > > assigned: > > > > > > R(equest) - If set, the message is a request. If > > > cleared, the > > > message is an answer. > > > P(roxiable) - If set, the message MAY be proxied, > > relayed or > > > redirected. If cleared, the message MUST be > > > locally processed. > > > 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 are commonly referred to > as an error > > > messages. This bit MUST NOT be set > in request > > > messages. See section 7.2. > > > D(uplicate) - If set, the message is a possible > > > duplicate request > > > due to failover/failback process > > > or re-sending of > > > record in storage. This flag MUST NOT > > > be set in > > > answer messages. > > > > > > 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. > > > > > > 5.5.4 Failover and Failback Procedures > > > > > > Change the paragraph > > > > > > When a transport failure is detected, all messages in the > > queue are > > > sent to an alternate agent, if possible. > > > .....etc.. > > > > > > to > > > > > > When a transport failure is detected, all messages in the > > queue are > > > sent to an alternate agent with the D flag set, if possible. > > > ......etc.. > > > > > > 8.2 Accounting Session State Machine > > > > > > Change the line > > > > > > Idle Records in storage Send PendingB > > > record > > > > > > of CLIENT, ACCOUNTING to > > > > > > Idle Records in storage Send PendingB > > > record > > > with D > > > flag set > > > > > > > > > Change appendix C as follow. > > > > > > Appendix C. Duplicate Detection > > > > > > 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 elimina- > > > tion is easy in this case. > > > > > > In other situations it may be necessary to perform > > real-time dupli- > > > cate detection, e.g. when the credit limits or fraud > attempts are > > > being monitored in real time. > > > > > > In general, only the duplicate generation at failover or > > > re-sending of > > > record in storage cases is something that can be reliably > > > detected by > > > the Diameter client or Diameter agents. In such cases > > the Diameter > > > client and the Diameter agents mark the request message > > as possible > > > duplicate by setting the D flag. 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, > > > such as the use > > > of the D flag in the received messages, may be used to > > > eliminate the need > > > to do a full search even in this set except for rare cases. > > > > > > The following is an example of how the D flag may be used > > > by the server to > > > detect duplicate records. > > > > > > Diameter server MAY check the D flag of the received > > > message to determine > > > if this record is a possible duplicate. If the D flag is > > > set in the request > > > message, the server search for the duplicate within the > > > above mentioned time > > > window. This way database search is only required for > > > those received records > > > whose the D flag is set. Since in today networks link > > > failures, server breakdown > > > or other similar events are very rare, this simple > > > approach efficiently > > > optimize performances of the duplicate detection process. > > > It may happen that the original record is received after > > > the D flag marked > > > record because they did experience different delay in > > > their way to the > > > server. For this reason it is necessary for the server to > > > buffer the D flag > > > marked records for a short time period, as an example 10 > > > or 15 minutes, and > > > check every record received within this time period > > > against the buffered > > > D flag marked records. > > > > > > > > > From owner-aaa-wg@merit.edu Mon Oct 14 10:16: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 KAA21362 for ; Mon, 14 Oct 2002 10:16:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4ECFC91240; Mon, 14 Oct 2002 10:18:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D38691241; Mon, 14 Oct 2002 10:18:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 051D091240 for ; Mon, 14 Oct 2002 10:18:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE97F5DEF1; Mon, 14 Oct 2002 10:18:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4AEA75DE0A for ; Mon, 14 Oct 2002 10:18:02 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9EDGZ702770; Mon, 14 Oct 2002 06:16:35 -0700 Date: Mon, 14 Oct 2002 06:16:35 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A57B9@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > The alternatives I see are: > > 1) Not supporting the d-bit. > 2) Allow the setting of the d-bit, but either making the response > implementation specific or dependent on futher specification. > 3) Supporting the d-bit and the behavior of responding to messages > with the bit set. We have an issue filed (372). Approach #1 would be to reject the issue. Approach #3 appears to accept the changes requested in Issue 372. What does approach #2 do? The text for Appendix C says: "Diameter server MAY check the D flag of the received message to determine if this record is a possible duplicate. If the D flag is set in the request message, the server search for the duplicate within the above mentioned time window. This way database search is only required for those received records whose the D flag is set. Since in today networks link failures, server breakdown or other similar events are very rare, this simple approach efficiently optimize performances of the duplicate detection process. It may happen that the original record is received after the D flag marked record because they did experience different delay in their way to the server. For this reason it is necessary for the server to buffer the D flag marked records for a short time period, as an example 10 or 15 minutes, and check every record received within this time period against the buffered D flag marked records." The problem is that failover can cause the accounting record to be sent to *another* server. For example, if a proxy fails, the Diameter client may go to another proxy, and the new proxy may set up a connection to a different accounting server. The approach described in the last sentence appears to assume that the duplicate arrives at the *same* server as the original record. I'd suggest that the last sentence say: "As a result, a simple approach is not foolproof, and may result in occasional duplicates being accepted by the system. If occasional duplicate records are not acceptable, then it may be difficult to retain realtime performance. If the server cannot locate the original record corresponding to the D flag marked record, it is still possible for the original to arrive later. To ensure that the duplicate is detected, it is necessary to delay processing of the D flag marked record until the original record can be assured to have been received. This corresponds approximately to TIME_WAIT." My question is whether the above defeats the purpose of realtime processing. From owner-aaa-wg@merit.edu Mon Oct 14 11:27: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 LAA23750 for ; Mon, 14 Oct 2002 11:27:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 75AA291218; Mon, 14 Oct 2002 11:29:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4170091241; Mon, 14 Oct 2002 11:29:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10B9791218 for ; Mon, 14 Oct 2002 11:29:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E92265DEFE; Mon, 14 Oct 2002 11:29:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by segue.merit.edu (Postfix) with ESMTP id A316B5DEFA for ; Mon, 14 Oct 2002 11:29:22 -0400 (EDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id LAA12460 for ; Mon, 14 Oct 2002 11:29:21 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [AAA-WG]: MIP-Session-Key Date: Mon, 14 Oct 2002 08:27:31 -0700 Message-ID: <003a01c27396$36d2aba0$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik, so you are saying each of the different pair of entities would have to be provisioned with a distinct key or a private key/certificate. How is situation handled when there is no existing security association ? Also, if you look into the following 3 AVP that I mentioned, there is no SPI specified for the MIP-HA-to-FA-Key and the MIP-HA-to-MN-Key. Would not it be better to have a security association between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt the MIP-Session-Keys ? Subrata -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Fredrik Johansson Sent: Sunday, October 13, 2002 11:38 PM To: Subrata Goswami; aaa-wg@merit.edu Subject: RE: [AAA-WG]: MIP-Session-Key Hi Subrata, The MIP-Session-Key is encrypted by the hop-by-hop security mechanism (i.e. ipsec or tls) or if there is more than one hop between any of the nodes end-to-end encryption may be used if deemed necessary (e.g. CMS when it becoms standarized). How you set up the hop-by-hop security like ipsec is out of the scope of the diameter protocol /fredrik > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > Of Subrata Goswami > Sent: den 14 oktober 2002 05:20 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: MIP-Session-Key > > > A simple question, the MIP-Session-Key AVP is used in the following > AVP's. > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-FA-to-MN-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > It is not very clear how { MIP-Session-Key } are encrypted to provide > privacy in transit, what type of keys are used and how are these key's > distributed to the > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > Subrata > From owner-aaa-wg@merit.edu Mon Oct 14 12: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 MAA24667 for ; Mon, 14 Oct 2002 12:09:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E495691201; Mon, 14 Oct 2002 12:11:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B064391241; Mon, 14 Oct 2002 12:11:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 85B8291201 for ; Mon, 14 Oct 2002 12:11:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 67B7A5DE0A; Mon, 14 Oct 2002 12:11:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 7F4F65DDBB for ; Mon, 14 Oct 2002 12:11:46 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9EGChK27705 for ; Mon, 14 Oct 2002 19:12:43 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 14 Oct 2002 19:06:57 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 14 Oct 2002 19:06:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Mon, 14 Oct 2002 19:06:57 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E437C@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposed change. Thread-Index: AcJzjI3ZbAgXsNAOS+WmmEpZZ9EJYgACMZRA From: To: , Cc: X-OriginalArrivalTime: 14 Oct 2002 16:06:57.0584 (UTC) FILETIME=[B8B5C300:01C2739B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA24667 Hi Bernard, thanks for considering the issue. Actually the real benefits of the D flag is that duplicate happen very seldom, so for all the D=0 records (say 90-95% of the records) the server can immediately process the request and answer to the client e.g. service granted or no money. D=1 records are statistically very few and duplicate search only for those records do not affect the overall performance of the system. Finally, your proposed text seems better than my original proposal. However, I'm not yet fully sure it is acceptable to delay the processing of all the D=1 records and don't have time to think now since I have to harry on and go back home, I'll come back tomorrow. I guess Time_Wait may be couple of seconds, am I right? However proposal#2 could be just to replace the text I proposed in Annex C that state that D falg may be used by server implementation and specified in diameter application etc..etc John could you make some proposal to replace my text? Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 14. October 2002 16:17 > To: Loughney John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > > The alternatives I see are: > > > > 1) Not supporting the d-bit. > > 2) Allow the setting of the d-bit, but either making > the response > > implementation specific or dependent on futher > specification. > > 3) Supporting the d-bit and the behavior of responding > to messages > > with the bit set. > > We have an issue filed (372). Approach #1 would be to reject > the issue. > Approach #3 appears to accept the changes requested in Issue 372. What > does approach #2 do? > > The text for Appendix C says: > > "Diameter server MAY check the D flag of the received message > to determine > if this record is a possible duplicate. If the D flag is set in the > request message, the server search for the duplicate within the above > mentioned time window. This way database search is only > required for those > received records whose the D flag is set. Since in today > networks link failures, server > breakdown or other similar events are very rare, this simple approach > efficiently optimize performances of the duplicate detection process. > It may happen that the original record is received after the > D flag marked > record because they did experience different delay in their way to the > server. For this reason it is necessary for the server to buffer the D > flag marked records for a short time period, as an example 10 or 15 > minutes, and check every record received within this time > period against > the buffered D flag marked records." > > The problem is that failover can cause the accounting record > to be sent to > *another* server. For example, if a proxy fails, the Diameter > client may > go to another proxy, and the new proxy may set up a connection to a > different accounting server. The approach described in the > last sentence > appears to assume that the duplicate arrives at the *same* > server as the > original record. > > I'd suggest that the last sentence say: > > "As a result, a simple approach is not foolproof, and may result in > occasional duplicates being accepted by the system. If occasional > duplicate records are not acceptable, then it may be > difficult to retain > realtime performance. If the server cannot locate the original > record corresponding to the D flag marked record, it is still > possible for > the original to arrive later. To ensure that the duplicate is > detected, it > is necessary to delay processing of the D flag marked record until > the original record can be assured to have been received. > This corresponds > approximately to TIME_WAIT." > > My question is whether the above defeats the purpose of realtime > processing. > > From owner-aaa-wg@merit.edu Mon Oct 14 12:51: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 MAA25907 for ; Mon, 14 Oct 2002 12:51:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D06DE91236; Mon, 14 Oct 2002 12:53:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C3CA91241; Mon, 14 Oct 2002 12:53:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77AA791236 for ; Mon, 14 Oct 2002 12:53:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FDF45DEFD; Mon, 14 Oct 2002 12:53:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 16B5F5DEFA for ; Mon, 14 Oct 2002 12:53:08 -0400 (EDT) Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. From: Pat Calhoun To: marco.stura@nokia.com Cc: aboba@internaut.com, john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E437C@esebe016.ntc.nokia.com> References: <142DC466081D9B409AAD1DDCA4B21E1D9E437C@esebe016.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Oct 2002 09:53:11 +0000 Message-Id: <1034589191.16025.18.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit But what would happen if two packets were received by a Diameter server out of order, so the first packet received had the 'D' bit set, while the second packet did not. PatC On Mon, 2002-10-14 at 16:06, marco.stura@nokia.com wrote: > Hi Bernard, > > thanks for considering the issue. > > Actually the real benefits of the D flag is that duplicate > happen very seldom, so for all the D=0 records (say 90-95% of > the records) the server can immediately process the request > and answer to the client e.g. service granted or no money. > > D=1 records are statistically very few and duplicate search > only for those records do not affect the overall performance > of the system. > > Finally, your proposed text seems better than my original > proposal. However, I'm not yet fully sure it is acceptable to > delay the processing of all the D=1 records and don't have > time to think now since I have to harry on and go back home, > I'll come back tomorrow. I guess Time_Wait may be couple of > seconds, am I right? > > However proposal#2 could be just to replace the text I proposed > in Annex C that state that D falg may be used by server implementation > and specified in diameter application etc..etc > > John could you make some proposal to replace my text? > > > Br > Marco > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 14. October 2002 16:17 > > To: Loughney John (NRC/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed > > change. > > > > > > > The alternatives I see are: > > > > > > 1) Not supporting the d-bit. > > > 2) Allow the setting of the d-bit, but either making > > the response > > > implementation specific or dependent on futher > > specification. > > > 3) Supporting the d-bit and the behavior of responding > > to messages > > > with the bit set. > > > > We have an issue filed (372). Approach #1 would be to reject > > the issue. > > Approach #3 appears to accept the changes requested in Issue 372. What > > does approach #2 do? > > > > The text for Appendix C says: > > > > "Diameter server MAY check the D flag of the received message > > to determine > > if this record is a possible duplicate. If the D flag is set in the > > request message, the server search for the duplicate within the above > > mentioned time window. This way database search is only > > required for those > > received records whose the D flag is set. Since in today > > networks link failures, server > > breakdown or other similar events are very rare, this simple approach > > efficiently optimize performances of the duplicate detection process. > > It may happen that the original record is received after the > > D flag marked > > record because they did experience different delay in their way to the > > server. For this reason it is necessary for the server to buffer the D > > flag marked records for a short time period, as an example 10 or 15 > > minutes, and check every record received within this time > > period against > > the buffered D flag marked records." > > > > The problem is that failover can cause the accounting record > > to be sent to > > *another* server. For example, if a proxy fails, the Diameter > > client may > > go to another proxy, and the new proxy may set up a connection to a > > different accounting server. The approach described in the > > last sentence > > appears to assume that the duplicate arrives at the *same* > > server as the > > original record. > > > > I'd suggest that the last sentence say: > > > > "As a result, a simple approach is not foolproof, and may result in > > occasional duplicates being accepted by the system. If occasional > > duplicate records are not acceptable, then it may be > > difficult to retain > > realtime performance. If the server cannot locate the original > > record corresponding to the D flag marked record, it is still > > possible for > > the original to arrive later. To ensure that the duplicate is > > detected, it > > is necessary to delay processing of the D flag marked record until > > the original record can be assured to have been received. > > This corresponds > > approximately to TIME_WAIT." > > > > My question is whether the above defeats the purpose of realtime > > processing. > > > > From owner-aaa-wg@merit.edu Mon Oct 14 13:54: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 NAA27904 for ; Mon, 14 Oct 2002 13:54:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56AB391203; Mon, 14 Oct 2002 13:56:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2688591222; Mon, 14 Oct 2002 13:56:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34BA591203 for ; Mon, 14 Oct 2002 13:56:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1F2325DF0B; Mon, 14 Oct 2002 13:56:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 869375DF0A for ; Mon, 14 Oct 2002 13:56:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9EGsil04660; Mon, 14 Oct 2002 09:54:45 -0700 Date: Mon, 14 Oct 2002 09:54:44 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: marco.stura@nokia.com, , Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. In-Reply-To: <1034589191.16025.18.camel@dhcp-229-243> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On 14 Oct 2002, Pat Calhoun wrote: > But what would happen if two packets were received by a Diameter server > out of order, so the first packet received had the 'D' bit set, while > the second packet did not. > > PatC That's where delaying by TIME_WAIT comes in, so that the second packet could be processed. > D=1 records are statistically very few and duplicate search > only for those records do not affect the overall performance > of the system. Question: so it wouldn't be an issue if some delay were required in processing those records? > I guess Time_Wait may be couple of seconds, am I right? It varies between 30 seconds and 2 minutes. > However proposal #2 could be just to replace the text I proposed > in Annex C that state that D flag may be used by server implementation > and specified in diameter application etc. If we're only talking about a few paragraphs in Appendix C, then I'd suggest that we should probably try to hammer this out now. However, if using the "D" bit requires more than this, it might need to wait for another application. From owner-aaa-wg@merit.edu Mon Oct 14 14:05: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 OAA28210 for ; Mon, 14 Oct 2002 14:05:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 565C391222; Mon, 14 Oct 2002 14:07:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2230691241; Mon, 14 Oct 2002 14:07:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 15F1F91222 for ; Mon, 14 Oct 2002 14:07:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3C6E5DF0D; Mon, 14 Oct 2002 14:07:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id B00C95DF0A for ; Mon, 14 Oct 2002 14:07:03 -0400 (EDT) Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. From: Pat Calhoun To: Bernard Aboba Cc: marco.stura@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 14 Oct 2002 11:07:07 +0000 Message-Id: <1034593627.16025.28.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If the purpose for this "feature" is to support real-time services, such as pre-paid calls, then I would assume that a 30-120 second delay in a response would not be a good idea. But perhaps I misunderstand the intention behind this feature request. PatC On Mon, 2002-10-14 at 16:54, Bernard Aboba wrote: > On 14 Oct 2002, Pat Calhoun wrote: > > > But what would happen if two packets were received by a Diameter server > > out of order, so the first packet received had the 'D' bit set, while > > the second packet did not. > > > > PatC > > That's where delaying by TIME_WAIT comes in, so that the second packet > could be processed. > > > D=1 records are statistically very few and duplicate search > > only for those records do not affect the overall performance > > of the system. > > Question: so it wouldn't be an issue if some delay were required in > processing those records? > > > I guess Time_Wait may be couple of seconds, am I right? > > It varies between 30 seconds and 2 minutes. > > > However proposal #2 could be just to replace the text I proposed > > in Annex C that state that D flag may be used by server implementation > > and specified in diameter application etc. > > If we're only talking about a few paragraphs in Appendix C, then I'd > suggest that we should probably try to hammer this out now. However, if > using the "D" bit requires more than this, it might need to wait for > another application. > > > From owner-aaa-wg@merit.edu Mon Oct 14 15:23: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 PAA00547 for ; Mon, 14 Oct 2002 15:23:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4775E91213; Mon, 14 Oct 2002 15:25:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 154AE91241; Mon, 14 Oct 2002 15:25:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8AFE91213 for ; Mon, 14 Oct 2002 15:25:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B49BC5DF1A; Mon, 14 Oct 2002 15:25:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 4527E5DF19 for ; Mon, 14 Oct 2002 15:25:17 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9EJOcPk023554; Mon, 14 Oct 2002 15:24:39 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA14118; Mon, 14 Oct 2002 15:25:08 -0400 (EDT) Date: Mon, 14 Oct 2002 15:24:34 -0400 To: Bernard Aboba Cc: Pat Calhoun , marco.stura@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. Message-ID: <20021014192434.GB683@catfish> References: <1034589191.16025.18.camel@dhcp-229-243> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 51 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk It seems that there is an assumption that _all_ Diameter clients and agents mandatory support 'D' bit set when failover/failback occurs. Otherwise, the scheme will not work as is expected when failover/failback occurs at some node that does not set 'D' bit while the server supports D-bit handling, resulting in duplicated accounting request undetected. If the assumption is correct, I'm not sure if the scheme is worth being defined in the base specification while other accounting application does not require this scheme and more generic scheme (i.e., hashing) may be able to solve the problem without changing the specification. Yoshihiro Ohba On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > On 14 Oct 2002, Pat Calhoun wrote: > > > But what would happen if two packets were received by a Diameter server > > out of order, so the first packet received had the 'D' bit set, while > > the second packet did not. > > > > PatC > > That's where delaying by TIME_WAIT comes in, so that the second packet > could be processed. > > > D=1 records are statistically very few and duplicate search > > only for those records do not affect the overall performance > > of the system. > > Question: so it wouldn't be an issue if some delay were required in > processing those records? > > > I guess Time_Wait may be couple of seconds, am I right? > > It varies between 30 seconds and 2 minutes. > > > However proposal #2 could be just to replace the text I proposed > > in Annex C that state that D flag may be used by server implementation > > and specified in diameter application etc. > > If we're only talking about a few paragraphs in Appendix C, then I'd > suggest that we should probably try to hammer this out now. However, if > using the "D" bit requires more than this, it might need to wait for > another application. > > > > From owner-aaa-wg@merit.edu Mon Oct 14 15:42: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 PAA01029 for ; Mon, 14 Oct 2002 15:42:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A2BD91241; Mon, 14 Oct 2002 15:44:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1C9391242; Mon, 14 Oct 2002 15:44:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A103891241 for ; Mon, 14 Oct 2002 15:44:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78DB05DF23; Mon, 14 Oct 2002 15:44:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id E30855DF1B for ; Mon, 14 Oct 2002 15:44:00 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9EJhvC06011; Mon, 14 Oct 2002 12:43:58 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9EJi9D19103; Mon, 14 Oct 2002 14:44:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 14:43:56 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24066CC178@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: marco.stura@nokia.com, aboba@internaut.com, john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed c hange. Date: Mon, 14 Oct 2002 14:43:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C273BA.056CE890" 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_01C273BA.056CE890 Content-Type: text/plain Hello, As I understand the issue: we are trying to make sure that the (near)real-time accounting systems (e.g. pre-paid) do not debit/credit users accounts multiple times when the same message is re-transmitted. Can't this be solved by appending a message sequence number (string) with every request? The client will send the same sequence number as long as it does not receive a response containing the same sequence number. The server should loop back the same sequence number in the reply. If the same message sequence was received at the server before (a reasonable time window for real-time service) then the server replicates the earlier message and send back a response w/o crediting/debiting the user's account. upon receiving the response with a previously generated and acknowledged sequence number the recipient ignores the message. I am not against the D-bit idea, however I think the message sequence numbers provide a good protection mechanism for avoiding erroneous accounting due to duplicate requests. Regards, Kuntal > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Monday, October 14, 2002 11:07 AM > To: aboba@internaut.com; john.loughney@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed change. > > > Hi Bernard, > > thanks for considering the issue. > > Actually the real benefits of the D flag is that duplicate > happen very seldom, so for all the D=0 records (say 90-95% of > the records) the server can immediately process the request > and answer to the client e.g. service granted or no money. > > D=1 records are statistically very few and duplicate search > only for those records do not affect the overall performance > of the system. > > Finally, your proposed text seems better than my original > proposal. However, I'm not yet fully sure it is acceptable to > delay the processing of all the D=1 records and don't have > time to think now since I have to harry on and go back home, > I'll come back tomorrow. I guess Time_Wait may be couple of > seconds, am I right? > > However proposal#2 could be just to replace the text I > proposed in Annex C that state that D falg may be used by > server implementation and specified in diameter application etc..etc > > John could you make some proposal to replace my text? > > > Br > Marco > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:aboba@internaut.com] > > Sent: 14. October 2002 16:17 > > To: Loughney John (NRC/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed > > change. > > > > > > > The alternatives I see are: > > > > > > 1) Not supporting the d-bit. > > > 2) Allow the setting of the d-bit, but either making > > the response > > > implementation specific or dependent on futher > > specification. > > > 3) Supporting the d-bit and the behavior of responding > > to messages > > > with the bit set. > > > > We have an issue filed (372). Approach #1 would be to reject > > the issue. > > Approach #3 appears to accept the changes requested in > Issue 372. What > > does approach #2 do? > > > > The text for Appendix C says: > > > > "Diameter server MAY check the D flag of the received message > > to determine > > if this record is a possible duplicate. If the D flag is set in the > > request message, the server search for the duplicate within > the above > > mentioned time window. This way database search is only > > required for those > > received records whose the D flag is set. Since in today > > networks link failures, server > > breakdown or other similar events are very rare, this > simple approach > > efficiently optimize performances of the duplicate > detection process. > > It may happen that the original record is received after the > > D flag marked > > record because they did experience different delay in their > way to the > > server. For this reason it is necessary for the server to > buffer the D > > flag marked records for a short time period, as an example 10 or 15 > > minutes, and check every record received within this time > > period against > > the buffered D flag marked records." > > > > The problem is that failover can cause the accounting record > > to be sent to > > *another* server. For example, if a proxy fails, the Diameter > > client may > > go to another proxy, and the new proxy may set up a connection to a > > different accounting server. The approach described in the > > last sentence > > appears to assume that the duplicate arrives at the *same* > > server as the > > original record. > > > > I'd suggest that the last sentence say: > > > > "As a result, a simple approach is not foolproof, and may result in > > occasional duplicates being accepted by the system. If occasional > > duplicate records are not acceptable, then it may be difficult to > > retain realtime performance. If the server cannot locate > the original > > record corresponding to the D flag marked record, it is still > > possible for > > the original to arrive later. To ensure that the duplicate is > > detected, it > > is necessary to delay processing of the D flag marked record until > > the original record can be assured to have been received. > > This corresponds > > approximately to TIME_WAIT." > > > > My question is whether the above defeats the purpose of realtime > > processing. > > > > > ------_=_NextPart_001_01C273BA.056CE890 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: issue: real-time duplicate detection and proposed = change.

Hello,
As I understand the issue: we are trying to make = sure that the (near)real-time accounting systems (e.g. pre-paid) do not = debit/credit users accounts multiple times when the same message is = re-transmitted. Can't this be solved by appending a message sequence = number (string) with every request? The client will send the same = sequence number as long as it does not receive a response containing = the same sequence number. The server should loop back the same sequence = number in the reply. If the same message sequence was received at the = server before (a reasonable time window for real-time service) then the = server replicates the earlier message and send back a response w/o = crediting/debiting the user's account. upon receiving the response with = a previously generated and acknowledged sequence number the recipient = ignores the message.

I am not against the D-bit idea, however I think the = message sequence numbers provide a good protection mechanism for = avoiding erroneous accounting due to duplicate requests.

Regards,
Kuntal


> -----Original Message-----
> From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
> Sent: Monday, October 14, 2002 11:07 AM
> To: aboba@internaut.com; = john.loughney@nokia.com
> Cc: aaa-wg@merit.edu
> Subject: RE: [AAA-WG]: issue: real-time = duplicate detection
> and proposed change.
>
>
> Hi Bernard,
>
> thanks for considering the issue.
>
> Actually the real benefits of the D flag is = that duplicate
> happen very seldom, so for all the D=3D0 = records (say 90-95% of
> the records) the server can immediately process = the request
> and answer to the client e.g. service granted = or no money.
>
> D=3D1 records are statistically very few and = duplicate search
> only for those records do not affect the = overall performance
> of the system.
>
> Finally, your proposed text seems better than = my original
> proposal. However, I'm not yet fully sure it is = acceptable to
> delay the processing of all the D=3D1 records = and don't have
> time to think now since I have to harry on and = go back home,
> I'll come back tomorrow. I guess Time_Wait may = be couple of
> seconds, am I right?
>
> However proposal#2 could be just to replace the = text I
> proposed in Annex C that state that D falg may = be used by
> server implementation and specified in diameter = application etc..etc
>
> John could you make some proposal to replace my = text?
>
>
> Br
> Marco
>
> > -----Original Message-----
> > From: ext Bernard Aboba [mailto:aboba@internaut.com]
> > Sent: 14. October 2002 16:17
> > To: Loughney John (NRC/Helsinki)
> > Cc: aaa-wg@merit.edu
> > Subject: RE: [AAA-WG]: issue: real-time = duplicate detection
> > and proposed
> > change.
> >
> >
> > > The alternatives I see are:
> > >
> > >   1) Not supporting the = d-bit.
> > >   2) Allow the setting of the = d-bit, but either making
> > the response
> > >   =         implementation specific or = dependent on futher
> > specification.
> > >   3) Supporting the d-bit and = the behavior of responding
> > to messages
> > >   =         with the bit set.
> >
> > We have an issue filed (372). Approach #1 = would be to reject
> > the issue.
> > Approach #3 appears to accept the changes = requested in
> Issue 372. What
> > does approach #2 do?
> >
> > The text for Appendix C says:
> >
> > "Diameter server MAY check the D flag = of the received message
> > to determine
> > if this record is a possible duplicate. If = the D flag is set in the
> > request message, the server search for the = duplicate within
> the above
> > mentioned time window. This way database = search is only
> > required for those
> > received records whose the D flag is set. = Since in today
> > networks link failures, server
> > breakdown or other similar events are very = rare, this
> simple approach
> > efficiently optimize performances of the = duplicate
> detection process.
> > It may happen that the original record is = received after the
> > D flag marked
> > record because they did experience = different delay in their
> way to the
> > server. For this reason it is necessary = for the server to
> buffer the D
> > flag marked records for a short time = period, as an example 10 or 15
> > minutes, and check every record received = within this time
> > period against
> > the buffered D flag marked = records."
> >
> > The problem is that failover can cause the = accounting record
> > to be sent to
> > *another* server. For example, if a proxy = fails, the Diameter
> > client may
> > go to another proxy, and the new proxy may = set up a connection to a
> > different accounting server. The approach = described in the
> > last sentence
> > appears to assume that the duplicate = arrives at the *same*
> > server as the
> > original record.
> >
> > I'd suggest that the last sentence = say:
> >
> > "As a result, a simple approach is = not foolproof, and may result in
> > occasional duplicates being accepted by = the system. If occasional
> > duplicate records are not acceptable, then = it may be difficult to
> > retain realtime performance. If the server = cannot locate
> the original
> > record corresponding to the D flag marked = record, it is still
> > possible for
> > the original to arrive later. To ensure = that the duplicate is
> > detected, it
> > is necessary to delay processing of the D = flag marked record until
> > the original record can be assured to have = been received.
> > This corresponds
> > approximately to TIME_WAIT."
> >
> > My question is whether the above defeats = the purpose of realtime
> > processing.
> >
> >
>

------_=_NextPart_001_01C273BA.056CE890-- From owner-aaa-wg@merit.edu Tue Oct 15 05:14: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 FAA24370 for ; Tue, 15 Oct 2002 05:14:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C158E91216; Tue, 15 Oct 2002 05:16:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8100B91247; Tue, 15 Oct 2002 05:16:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 615A191216 for ; Tue, 15 Oct 2002 05:16:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10F945DF58; Tue, 15 Oct 2002 05:16:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 459525DF52 for ; Tue, 15 Oct 2002 05:16:46 -0400 (EDT) Received: from fmorn1dcode948i (a12.local.ipunplugged.com [192.168.4.182]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g9F9GJ24032224; Tue, 15 Oct 2002 11:16:20 +0200 From: "Fredrik Johansson" To: "Subrata Goswami" , Subject: RE: [AAA-WG]: MIP-Session-Key Date: Tue, 15 Oct 2002 11:17:41 +0200 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 In-Reply-To: <003a01c27396$36d2aba0$c900a8c0@SGOSWAMIPCL> Importance: Normal X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > Subrata Goswami > Sent: den 14 oktober 2002 17:28 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > Fredrik, so you are saying each of the different pair of entities would > have to be > provisioned with a distinct key or a private key/certificate. How is > situation > handled when there is no existing security association ? There MUST be a hop-by-hop security mechanism, either ipsec or tls according to the protocol > Also, if you > look into > the following 3 AVP that I mentioned, there is no SPI specified for the > MIP-HA-to-FA-Key > and the MIP-HA-to-MN-Key. Would not it be better to have a security > association > between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt the > MIP-Session-Keys ? that's exactly what's used, since the whole message between the FA-AAAF and HA-AAAH is encrypted with the hop-by-hop security mechanism the keys are encrypted, if there are several hops between each node a end-to-end security mechanism should be used (e.g. cms) /fredrik > > Subrata > > > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of Fredrik Johansson > Sent: Sunday, October 13, 2002 11:38 PM > To: Subrata Goswami; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > Hi Subrata, > > The MIP-Session-Key is encrypted by the hop-by-hop security mechanism > (i.e. ipsec or tls) or if there is more than one hop between any of the > nodes end-to-end encryption may be used if deemed necessary (e.g. CMS > when it becoms standarized). > > How you set up the hop-by-hop security like ipsec is out of the scope of > the diameter protocol > > /fredrik > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > > Of Subrata Goswami > > Sent: den 14 oktober 2002 05:20 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: MIP-Session-Key > > > > > > A simple question, the MIP-Session-Key AVP is used in the following > > AVP's. > > > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-FA-to-MN-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > It is not very clear how { MIP-Session-Key } are encrypted to provide > > privacy in transit, what type of keys are used and how are these key's > > > distributed to the > > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > > > > Subrata > > From owner-aaa-wg@merit.edu Tue Oct 15 05:55: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 FAA25013 for ; Tue, 15 Oct 2002 05:55:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5663491249; Tue, 15 Oct 2002 05:57:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1DEB09124A; Tue, 15 Oct 2002 05:57:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB31491249 for ; Tue, 15 Oct 2002 05:57:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC63E5DF61; Tue, 15 Oct 2002 05:57:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id E2E6E5DF52 for ; Tue, 15 Oct 2002 05:57:44 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9F9wgK19546 for ; Tue, 15 Oct 2002 12:58:42 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 12:57:14 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 12:56:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Tue, 15 Oct 2002 12:56:41 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E437F@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposed change. Thread-Index: AcJzug06HvoiUNTzTW+IeP3MUcCpngAbe+hA From: To: , , Cc: X-OriginalArrivalTime: 15 Oct 2002 09:56:41.0893 (UTC) FILETIME=[298A1550:01C27431] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA25013 Hi, sequence number is not the same as Session-Id and record number? If we consider the case of "one time event" direct debiting, the ACR[event, Session-Id, Record-number] is sent to the server and the server loop back the same Session-Id and Record-number in the ACA. am I right? When the server receives the ACR money are deducted from the user's account, If the server doesn't know if the ACR is a possible duplicate, it needs to perform database search among at least all the records received by this particular client within a reasonable time window (e.g. a day) to avoid double debiting, database searchthis is what we try to avoid. Hashing may do it with certain memory requirements, D flag may do it with less memory requirements. Br Marco -----Original Message----- From: ext Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] Sent: 14. October 2002 22:44 To: Stura Marco (NET/Helsinki); aboba@internaut.com; Loughney John (NRC/Helsinki) Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Hello, As I understand the issue: we are trying to make sure that the (near)real-time accounting systems (e.g. pre-paid) do not debit/credit users accounts multiple times when the same message is re-transmitted. Can't this be solved by appending a message sequence number (string) with every request? The client will send the same sequence number as long as it does not receive a response containing the same sequence number. The server should loop back the same sequence number in the reply. If the same message sequence was received at the server before (a reasonable time window for real-time service) then the server replicates the earlier message and send back a response w/o crediting/debiting the user's account. upon receiving the response with a previously generated and acknowledged sequence number the recipient ignores the message. I am not against the D-bit idea, however I think the message sequence numbers provide a good protection mechanism for avoiding erroneous accounting due to duplicate requests. Regards, Kuntal > -----Original Message----- > From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com] > Sent: Monday, October 14, 2002 11:07 AM > To: aboba@internaut.com; john.loughney@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed change. > > > Hi Bernard, > > thanks for considering the issue. > > Actually the real benefits of the D flag is that duplicate > happen very seldom, so for all the D=0 records (say 90-95% of > the records) the server can immediately process the request > and answer to the client e.g. service granted or no money. > > D=1 records are statistically very few and duplicate search > only for those records do not affect the overall performance > of the system. > > Finally, your proposed text seems better than my original > proposal. However, I'm not yet fully sure it is acceptable to > delay the processing of all the D=1 records and don't have > time to think now since I have to harry on and go back home, > I'll come back tomorrow. I guess Time_Wait may be couple of > seconds, am I right? > > However proposal#2 could be just to replace the text I > proposed in Annex C that state that D falg may be used by > server implementation and specified in diameter application etc..etc > > John could you make some proposal to replace my text? > > > Br > Marco > > > -----Original Message----- > > From: ext Bernard Aboba [ mailto:aboba@internaut.com] > > Sent: 14. October 2002 16:17 > > To: Loughney John (NRC/Helsinki) > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed > > change. > > > > > > > The alternatives I see are: > > > > > > 1) Not supporting the d-bit. > > > 2) Allow the setting of the d-bit, but either making > > the response > > > implementation specific or dependent on futher > > specification. > > > 3) Supporting the d-bit and the behavior of responding > > to messages > > > with the bit set. > > > > We have an issue filed (372). Approach #1 would be to reject > > the issue. > > Approach #3 appears to accept the changes requested in > Issue 372. What > > does approach #2 do? > > > > The text for Appendix C says: > > > > "Diameter server MAY check the D flag of the received message > > to determine > > if this record is a possible duplicate. If the D flag is set in the > > request message, the server search for the duplicate within > the above > > mentioned time window. This way database search is only > > required for those > > received records whose the D flag is set. Since in today > > networks link failures, server > > breakdown or other similar events are very rare, this > simple approach > > efficiently optimize performances of the duplicate > detection process. > > It may happen that the original record is received after the > > D flag marked > > record because they did experience different delay in their > way to the > > server. For this reason it is necessary for the server to > buffer the D > > flag marked records for a short time period, as an example 10 or 15 > > minutes, and check every record received within this time > > period against > > the buffered D flag marked records." > > > > The problem is that failover can cause the accounting record > > to be sent to > > *another* server. For example, if a proxy fails, the Diameter > > client may > > go to another proxy, and the new proxy may set up a connection to a > > different accounting server. The approach described in the > > last sentence > > appears to assume that the duplicate arrives at the *same* > > server as the > > original record. > > > > I'd suggest that the last sentence say: > > > > "As a result, a simple approach is not foolproof, and may result in > > occasional duplicates being accepted by the system. If occasional > > duplicate records are not acceptable, then it may be difficult to > > retain realtime performance. If the server cannot locate > the original > > record corresponding to the D flag marked record, it is still > > possible for > > the original to arrive later. To ensure that the duplicate is > > detected, it > > is necessary to delay processing of the D flag marked record until > > the original record can be assured to have been received. > > This corresponds > > approximately to TIME_WAIT." > > > > My question is whether the above defeats the purpose of realtime > > processing. > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 10: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 KAA02779 for ; Tue, 15 Oct 2002 10:14:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E17DE9120D; Tue, 15 Oct 2002 10:16:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EB629124B; Tue, 15 Oct 2002 10:16:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 608D39120D for ; Tue, 15 Oct 2002 10:16:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 458185DF82; Tue, 15 Oct 2002 10:16:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 9BA565DF81 for ; Tue, 15 Oct 2002 10:16:24 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FEG7w03428 for ; Tue, 15 Oct 2002 17:16:07 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 17:16:22 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 17:16:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Date: Tue, 15 Oct 2002 17:16:21 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4382@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Thread-Index: AcJzrIGXxWNeM8P4S7utEcyAN8LLIwAnbJ1Q From: To: , Cc: , X-OriginalArrivalTime: 15 Oct 2002 14:16:21.0420 (UTC) FILETIME=[6FA93EC0:01C27455] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA02779 Hi Pat and Bernard, > If the purpose for this "feature" is to support real-time > services, such > as pre-paid calls, then I would assume that a 30-120 second delay in a > response would not be a good idea. Since D=1 would be already a duplicate and happen very seldom I guess 30-120 seconds delay for D=1 records is more than acceptable. > > > D=1 records are statistically very few and duplicate search > > > only for those records do not affect the overall performance > > > of the system. > > > > Question: so it wouldn't be an issue if some delay were required in > > processing those records? Right! > > If we're only talking about a few paragraphs in Appendix C, then I'd > > suggest that we should probably try to hammer this out now. Yes, it is better to hammer the text now in one effort. I will send tomorrow a new wording proposal to consider. Best regards Marco > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] > Sent: 14. October 2002 14:07 > To: Bernard Aboba > Cc: Stura Marco (NET/Helsinki); Loughney John (NRC/Helsinki); > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection and > proposedchange. > > > If the purpose for this "feature" is to support real-time > services, such > as pre-paid calls, then I would assume that a 30-120 second delay in a > response would not be a good idea. > > But perhaps I misunderstand the intention behind this feature request. > > PatC > On Mon, 2002-10-14 at 16:54, Bernard Aboba wrote: > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > But what would happen if two packets were received by a > Diameter server > > > out of order, so the first packet received had the 'D' > bit set, while > > > the second packet did not. > > > > > > PatC > > > > That's where delaying by TIME_WAIT comes in, so that the > second packet > > could be processed. > > > > > D=1 records are statistically very few and duplicate search > > > only for those records do not affect the overall performance > > > of the system. > > > > Question: so it wouldn't be an issue if some delay were required in > > processing those records? > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > It varies between 30 seconds and 2 minutes. > > > > > However proposal #2 could be just to replace the text I proposed > > > in Annex C that state that D flag may be used by server > implementation > > > and specified in diameter application etc. > > > > If we're only talking about a few paragraphs in Appendix C, then I'd > > suggest that we should probably try to hammer this out now. > However, if > > using the "D" bit requires more than this, it might need to wait for > > another application. > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 10:44: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 KAA03758 for ; Tue, 15 Oct 2002 10:44:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2003E9124E; Tue, 15 Oct 2002 10:45:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D19919124F; Tue, 15 Oct 2002 10:45:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C73E9124E for ; Tue, 15 Oct 2002 10:45:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 924F25DF83; Tue, 15 Oct 2002 10:45:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id A3CFB5DF74 for ; Tue, 15 Oct 2002 10:45:33 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FEjGw24720 for ; Tue, 15 Oct 2002 17:45:16 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 17:40:04 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 17:40:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Tue, 15 Oct 2002 17:40:02 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED25@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposed change. Thread-Index: AcJzt31oy7btETifRcCi6WJrgz/G2AAoL+fA From: To: , Cc: , , X-OriginalArrivalTime: 15 Oct 2002 14:40:03.0022 (UTC) FILETIME=[BF007EE0:01C27458] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I'm not sure my previous mail went through, so I re-send. > It seems that there is an assumption that _all_ Diameter clients and > agents mandatory support 'D' bit set when failover/failback occurs. > Otherwise, the scheme will not work as is expected when > failover/failback occurs at some node that does not set 'D' bit while > the server supports D-bit handling, resulting in duplicated accounting > request undetected. Yes, the proposal is for diameter base (client and agents) to set the D flag when failover/failback occur or, only for client, when a stored record is re-sent. The server may support this scheme or other schemes as already mentioned in the Annex C. I guess setting this flag is really minor change. > If the assumption is correct, I'm not sure if the scheme is worth > being defined in the base specification while other accounting > application does not require this scheme and more generic scheme > (i.e., hashing) may be able to solve the problem without changing the > specification. I guess hashing is placing additional memory requirement to implementation, here is some rough number I drafted as an example in some other mail, how much those numbers are accurate I don't know but they give an idea. The point is that not all the implementations are willing to use this memory size just to cover cases that happen very seldom , which also translate in cost for your product. I don't know what it could be the hashing function but let's try to analyze what size the hashing table might be considering the multimedia messaging use case. Currently in GSM networks people send in average 1 SMS per hour. If your server need to handle 4 millions of prepaid subscribers it means that in 24 hours it will get 4*24=96 millions requests. If we consider a Key of 32-bits(4 bytes) the hashing table should be 96*4= around 370MB. Now if we want to limit the risk of collision we may double the size to reduce to load factor 370*2=740MB. But I just considered one service, if we consider other services as well we can safely assume 2 or even 3 requests per hour per subscriber. Just with 2 requests per hour the size would double to 740*2= aroun 1.5GB in addition to the disk database and the memory to run the other server SW. Br Marco > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 14. October 2002 22:25 > To: Bernard Aboba > Cc: Pat Calhoun; Stura Marco (NET/Helsinki); Loughney John > (NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > It seems that there is an assumption that _all_ Diameter clients and > agents mandatory support 'D' bit set when failover/failback occurs. > Otherwise, the scheme will not work as is expected when > failover/failback occurs at some node that does not set 'D' bit while > the server supports D-bit handling, resulting in duplicated accounting > request undetected. > > If the assumption is correct, I'm not sure if the scheme is worth > being defined in the base specification while other accounting > application does not require this scheme and more generic scheme > (i.e., hashing) may be able to solve the problem without changing the > specification. > > Yoshihiro Ohba > > > On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > But what would happen if two packets were received by a > Diameter server > > > out of order, so the first packet received had the 'D' > bit set, while > > > the second packet did not. > > > > > > PatC > > > > That's where delaying by TIME_WAIT comes in, so that the > second packet > > could be processed. > > > > > D=1 records are statistically very few and duplicate search > > > only for those records do not affect the overall performance > > > of the system. > > > > Question: so it wouldn't be an issue if some delay were required in > > processing those records? > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > It varies between 30 seconds and 2 minutes. > > > > > However proposal #2 could be just to replace the text I proposed > > > in Annex C that state that D flag may be used by server > implementation > > > and specified in diameter application etc. > > > > If we're only talking about a few paragraphs in Appendix C, then I'd > > suggest that we should probably try to hammer this out now. > However, if > > using the "D" bit requires more than this, it might need to wait for > > another application. > > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 11:39: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 LAA05178 for ; Tue, 15 Oct 2002 11:39:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 77BC69124F; Tue, 15 Oct 2002 11:41:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3725A91250; Tue, 15 Oct 2002 11:41:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 14CF69124F for ; Tue, 15 Oct 2002 11:41:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 028815DF86; Tue, 15 Oct 2002 11:41:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 5DAFB5DF2A for ; Tue, 15 Oct 2002 11:41:42 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FFfd326257; Tue, 15 Oct 2002 08:41:40 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9FFfp409325; Tue, 15 Oct 2002 10:41:51 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 15 Oct 2002 10:41:37 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24066CCB95@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: marco.stura@nokia.com, aboba@internaut.com, john.loughney@nokia.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed c hange. Date: Tue, 15 Oct 2002 10:41:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27461.54B73DE0" 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_01C27461.54B73DE0 Content-Type: text/plain Hello Marco, I am not sure why would the reasonable search window be 1 day (the example you mentioned). In your email reply to Pat you are saying that 30-120 sec for delay of D=1 processing is OK. If the assumption is that the packets get delayed only for a few seconds in the path, then we can safely narrow down the search window for duplicates to say a couple of minutes. I think the kind of debit/credit system you have in mind is prepaid SMS. However there can be other session based prepaid systems e.g. VoIP for which each session won't last more than few minutes (normally) or a few hours (max). The search windows for these session based prepaid systems will be much narrow. The search window can be Timestamp of the Beginning of the session (Account start) to present time. The search in the server will only trigger if the received message sequence number is out of order ( i.e. received 3 when 4 is expected). Regards, Kuntal > -----Original Message----- > From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] > Sent: Tuesday, October 15, 2002 4:57 AM > To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; aboba@internaut.com; > john.loughney@nokia.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed change. > > > Hi, > > sequence number is not the same as Session-Id and record > number? If we consider the case of "one time event" direct > debiting, the ACR[event, Session-Id, Record-number] is sent > to the server and the server loop back the same Session-Id > and Record-number in the ACA. am I right? > > When the server receives the ACR money are deducted from the > user's account, If the server doesn't know if the ACR is a > possible duplicate, it needs to perform database search among > at least all the records received by this particular client > within a reasonable time window (e.g. a day) to avoid double > debiting, database searchthis is what we try to avoid. > > Hashing may do it with certain memory requirements, D flag > may do it with less memory requirements. > > Br > Marco > > -----Original Message----- > From: ext Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > Sent: 14. October 2002 22:44 > To: Stura Marco (NET/Helsinki); aboba@internaut.com; Loughney > John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > and proposed change. > > > > Hello, > As I understand the issue: we are trying to make sure that > the (near)real-time accounting systems (e.g. pre-paid) do not > debit/credit users accounts multiple times when the same > message is re-transmitted. Can't this be solved by appending > a message sequence number (string) with every request? The > client will send the same sequence number as long as it does > not receive a response containing the same sequence number. > The server should loop back the same sequence number in the > reply. If the same message sequence was received at the > server before (a reasonable time window for real-time > service) then the server replicates the earlier message and > send back a response w/o crediting/debiting the user's > account. upon receiving the response with a previously > generated and acknowledged sequence number the recipient > ignores the message. > > I am not against the D-bit idea, however I think the message > sequence numbers provide a good protection mechanism for > avoiding erroneous accounting due to duplicate requests. > > Regards, > Kuntal > > > > -----Original Message----- > > From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com] > > Sent: Monday, October 14, 2002 11:07 AM > > To: aboba@internaut.com; john.loughney@nokia.com > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed change. > > > > > > Hi Bernard, > > > > thanks for considering the issue. > > > > Actually the real benefits of the D flag is that duplicate > > happen very seldom, so for all the D=0 records (say 90-95% of > > the records) the server can immediately process the request > > and answer to the client e.g. service granted or no money. > > > > D=1 records are statistically very few and duplicate search > > only for those records do not affect the overall performance > > of the system. > > > > Finally, your proposed text seems better than my original > > proposal. However, I'm not yet fully sure it is acceptable to > > delay the processing of all the D=1 records and don't have > > time to think now since I have to harry on and go back home, > > I'll come back tomorrow. I guess Time_Wait may be couple of > > seconds, am I right? > > > > However proposal#2 could be just to replace the text I > > proposed in Annex C that state that D falg may be used by > > server implementation and specified in diameter application > etc..etc > > > > John could you make some proposal to replace my text? > > > > > > Br > > Marco > > > > > -----Original Message----- > > > From: ext Bernard Aboba [ mailto:aboba@internaut.com] > > > Sent: 14. October 2002 16:17 > > > To: Loughney John (NRC/Helsinki) > > > Cc: aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > > and proposed > > > change. > > > > > > > > > > The alternatives I see are: > > > > > > > > 1) Not supporting the d-bit. > > > > 2) Allow the setting of the d-bit, but either making > > > the response > > > > implementation specific or dependent on futher > > > specification. > > > > 3) Supporting the d-bit and the behavior of responding > > > to messages > > > > with the bit set. > > > > > > We have an issue filed (372). Approach #1 would be to reject > > > the issue. > > > Approach #3 appears to accept the changes requested in > > Issue 372. What > > > does approach #2 do? > > > > > > The text for Appendix C says: > > > > > > "Diameter server MAY check the D flag of the received message > > > to determine > > > if this record is a possible duplicate. If the D flag is > set in the > > > request message, the server search for the duplicate within > > the above > > > mentioned time window. This way database search is only > > > required for those > > > received records whose the D flag is set. Since in today > > > networks link failures, server > > > breakdown or other similar events are very rare, this > > simple approach > > > efficiently optimize performances of the duplicate > > detection process. > > > It may happen that the original record is received after the > > > D flag marked > > > record because they did experience different delay in their > > way to the > > > server. For this reason it is necessary for the server to > > buffer the D > > > flag marked records for a short time period, as an > example 10 or 15 > > > minutes, and check every record received within this time > > > period against > > > the buffered D flag marked records." > > > > > > The problem is that failover can cause the accounting record > > > to be sent to > > > *another* server. For example, if a proxy fails, the Diameter > > > client may > > > go to another proxy, and the new proxy may set up a > connection to a > > > different accounting server. The approach described in the > > > last sentence > > > appears to assume that the duplicate arrives at the *same* > > > server as the > > > original record. > > > > > > I'd suggest that the last sentence say: > > > > > > "As a result, a simple approach is not foolproof, and may > result in > > > occasional duplicates being accepted by the system. If occasional > > > duplicate records are not acceptable, then it may be difficult to > > > retain realtime performance. If the server cannot locate > > the original > > > record corresponding to the D flag marked record, it is still > > > possible for > > > the original to arrive later. To ensure that the duplicate is > > > detected, it > > > is necessary to delay processing of the D flag marked > record until > > > the original record can be assured to have been received. > > > This corresponds > > > approximately to TIME_WAIT." > > > > > > My question is whether the above defeats the purpose of realtime > > > processing. > > > > > > > > > > ------_=_NextPart_001_01C27461.54B73DE0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: issue: real-time duplicate detection and proposed = change.

Hello Marco,
I am not sure why would the reasonable search window = be 1 day (the example you mentioned). In your email reply to Pat you = are saying that 30-120 sec for delay of D=3D1 processing is OK. If the = assumption is that the packets get delayed only for a few seconds in = the path, then we can safely narrow down the search window for = duplicates to say a couple of minutes.

I think the kind of debit/credit system you have in = mind is prepaid SMS. However there can be other session based prepaid = systems e.g. VoIP for which each session won't last more than few = minutes (normally) or a few hours (max). The search windows for these = session based prepaid systems will be much narrow.

The search window can be Timestamp of the Beginning = of the session (Account start) to present time. The search in the = server will only trigger if the received message sequence number is out = of order ( i.e. received 3 when 4 is expected).

Regards,
Kuntal



> -----Original Message-----
> From: marco.stura@nokia.com [mailto:marco.stura@nokia.com] =
> Sent: Tuesday, October 15, 2002 4:57 AM
> To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; = aboba@internaut.com;
> john.loughney@nokia.com
> Cc: aaa-wg@merit.edu
> Subject: RE: [AAA-WG]: issue: real-time = duplicate detection
> and proposed change.
>
>
> Hi,
> 
> sequence number is not the same as Session-Id = and record
> number? If we consider the case of "one = time event" direct
> debiting, the ACR[event, Session-Id, = Record-number] is sent
> to the server and the server loop back the same = Session-Id
> and Record-number in the ACA. am I = right?
> 
> When the server receives the ACR money are = deducted from the
> user's account, If the server doesn't know if = the ACR is a
> possible duplicate, it needs to perform = database search among
> at least all the records received by this = particular client
> within a reasonable time window (e.g. a day) to = avoid double
> debiting, database searchthis is what we try to = avoid.
> 
> Hashing may do it with certain memory = requirements, D flag
> may do it with less memory requirements.
> 
> Br
> Marco
> 
>  -----Original Message-----
> From: ext Kuntal Chowdhury [mailto:chowdury@nortelnetwor= ks.com]
> Sent: 14. October 2002 22:44
> To: Stura Marco (NET/Helsinki); = aboba@internaut.com; Loughney
> John (NRC/Helsinki)
> Cc: aaa-wg@merit.edu
> Subject: RE: [AAA-WG]: issue: real-time = duplicate detection
> and proposed change.
>
>
>
> Hello,
> As I understand the issue: we are trying to = make sure that
> the (near)real-time accounting systems (e.g. = pre-paid) do not
> debit/credit users accounts multiple times when = the same
> message is re-transmitted. Can't this be solved = by appending
> a message sequence number (string) with every = request? The
> client will send the same sequence number as = long as it does
> not receive a response containing the same = sequence number.
> The server should loop back the same sequence = number in the
> reply. If the same message sequence was = received at the
> server before (a reasonable time window for = real-time
> service) then the server replicates the earlier = message and
> send back a response w/o crediting/debiting the = user's
> account. upon receiving the response with a = previously
> generated and acknowledged sequence number the = recipient
> ignores the message.
>
> I am not against the D-bit idea, however I = think the message
> sequence numbers provide a good protection = mechanism for
> avoiding erroneous accounting due to duplicate = requests.
>
> Regards,
> Kuntal
>
>
> > -----Original Message-----
> > From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com] =
> > Sent: Monday, October 14, 2002 11:07 AM =
> > To: aboba@internaut.com; = john.loughney@nokia.com
> > Cc: aaa-wg@merit.edu
> > Subject: RE: [AAA-WG]: issue: real-time = duplicate detection
> > and proposed change.
> >
> >
> > Hi Bernard,
> >
> > thanks for considering the issue.
> >
> > Actually the real benefits of the D flag = is that duplicate
> > happen very seldom, so for all the D=3D0 = records (say 90-95% of
> > the records) the server can immediately = process the request
> > and answer to the client e.g. service = granted or no money.
> >
> > D=3D1 records are statistically very few = and duplicate search
> > only for those records do not affect the = overall performance
> > of the system.
> >
> > Finally, your proposed text seems better = than my original
> > proposal. However, I'm not yet fully sure = it is acceptable to
> > delay the processing of all the D=3D1 = records and don't have
> > time to think now since I have to harry on = and go back home,
> > I'll come back tomorrow. I guess Time_Wait = may be couple of
> > seconds, am I right?
> >
> > However proposal#2 could be just to = replace the text I
> > proposed in Annex C that state that D falg = may be used by
> > server implementation and specified in = diameter application
> etc..etc
> >
> > John could you make some proposal to = replace my text?
> >
> >
> > Br
> > Marco
> >
> > > -----Original Message-----
> > > From: ext Bernard Aboba [ mailto:aboba@internaut.com] =
> > > Sent: 14. October 2002 16:17
> > > To: Loughney John (NRC/Helsinki) =
> > > Cc: aaa-wg@merit.edu
> > > Subject: RE: [AAA-WG]: issue: = real-time duplicate detection
> > > and proposed
> > > change.
> > >
> > >
> > > > The alternatives I see = are:
> > > >
> > > >   1) Not supporting = the d-bit.
> > > >   2) Allow the setting = of the d-bit, but either making
> > > the response
> > > = >           = implementation specific or dependent on futher
> > > specification.
> > > >   3) Supporting the = d-bit and the behavior of responding
> > > to messages
> > > = >           with = the bit set.
> > >
> > > We have an issue filed (372). = Approach #1 would be to reject
> > > the issue.
> > > Approach #3 appears to accept the = changes requested in
> > Issue 372. What
> > > does approach #2 do?
> > >
> > > The text for Appendix C says:
> > >
> > > "Diameter server MAY check the D = flag of the received message
> > > to determine
> > > if this record is a possible = duplicate. If the D flag is
> set in the
> > > request message, the server search = for the duplicate within
> > the above
> > > mentioned time window. This way = database search is only
> > > required for those
> > > received records whose the D flag is = set. Since in today
> > > networks link failures, server =
> > > breakdown or other similar events are = very rare, this
> > simple approach
> > > efficiently optimize performances of = the duplicate
> > detection process.
> > > It may happen that the original = record is received after the
> > > D flag marked
> > > record because they did experience = different delay in their
> > way to the
> > > server. For this reason it is = necessary for the server to
> > buffer the D
> > > flag marked records for a short time = period, as an
> example 10 or 15
> > > minutes, and check every record = received within this time
> > > period against
> > > the buffered D flag marked = records."
> > >
> > > The problem is that failover can = cause the accounting record
> > > to be sent to
> > > *another* server. For example, if a = proxy fails, the Diameter
> > > client may
> > > go to another proxy, and the new = proxy may set up a
> connection to a
> > > different accounting server. The = approach described in the
> > > last sentence
> > > appears to assume that the duplicate = arrives at the *same*
> > > server as the
> > > original record.
> > >
> > > I'd suggest that the last sentence = say:
> > >
> > > "As a result, a simple approach = is not foolproof, and may
> result in
> > > occasional duplicates being accepted = by the system. If occasional
> > > duplicate records are not acceptable, = then it may be difficult to
> > > retain realtime performance. If the = server cannot locate
> > the original
> > > record corresponding to the D flag = marked record, it is still
> > > possible for
> > > the original to arrive later. To = ensure that the duplicate is
> > > detected, it
> > > is necessary to delay processing of = the D flag marked
> record until
> > > the original record can be assured to = have been received.
> > > This corresponds
> > > approximately to TIME_WAIT." =
> > >
> > > My question is whether the above = defeats the purpose of realtime
> > > processing.
> > >
> > >
> >
>
>

------_=_NextPart_001_01C27461.54B73DE0-- From owner-aaa-wg@merit.edu Tue Oct 15 12:42: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 MAA07144 for ; Tue, 15 Oct 2002 12:42:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A56C89120E; Tue, 15 Oct 2002 12:44:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 670B491251; Tue, 15 Oct 2002 12:44:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 468E89120E for ; Tue, 15 Oct 2002 12:44:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18BC45DF8F; Tue, 15 Oct 2002 12:44:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by segue.merit.edu (Postfix) with ESMTP id 8060E5DF8A for ; Tue, 15 Oct 2002 12:44:02 -0400 (EDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id MAA06585 for ; Tue, 15 Oct 2002 12:44:01 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [AAA-WG]: MIP-Session-Key Date: Tue, 15 Oct 2002 09:42:10 -0700 Message-ID: <000301c27469$cfb6d890$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Frederik, no that is exactly what is used. IPSec and TLS are totally different protocols and it is not necessary for Diameter MIP Application to set up point-to-point encrypted links as they do. Setting up these point-to-point links would be a nightmare and frankly no one is probably going to use that approach in a large network with many subnets. Take a look at the Diameter Mobile IP application, see how many hops are there. A better approach is what I suggested, encrypt MIP-Session-Keys with security associations between a AAA agent and the entity. I am not sure CMS handles this issue. It is not about end-to-end vs. point-to-point, it is more about how many shared secrets needs to be deployed per session - in case of Diameter Mobile IP application that number is 3 if you include FA-HA in addition to MN-FA, MN-HA. The number would double if a unidirectional key is used. Also, keep in mind as Diameter Mobile IP Application is a key distribution mechanism, there could be other keys that it would have distribute in the very near future. Subrata -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Fredrik Johansson Sent: Tuesday, October 15, 2002 2:18 AM To: Subrata Goswami; aaa-wg@merit.edu Subject: RE: [AAA-WG]: MIP-Session-Key > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > Of Subrata Goswami > Sent: den 14 oktober 2002 17:28 > To: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > Fredrik, so you are saying each of the different pair of entities > would have to be provisioned with a distinct key or a private > key/certificate. How is situation > handled when there is no existing security association ? There MUST be a hop-by-hop security mechanism, either ipsec or tls according to the protocol > Also, if you > look into > the following 3 AVP that I mentioned, there is no SPI specified for > the MIP-HA-to-FA-Key and the MIP-HA-to-MN-Key. Would not it be better > to have a security association > between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt the > MIP-Session-Keys ? that's exactly what's used, since the whole message between the FA-AAAF and HA-AAAH is encrypted with the hop-by-hop security mechanism the keys are encrypted, if there are several hops between each node a end-to-end security mechanism should be used (e.g. cms) /fredrik > > Subrata > > > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of Fredrik Johansson > Sent: Sunday, October 13, 2002 11:38 PM > To: Subrata Goswami; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > Hi Subrata, > > The MIP-Session-Key is encrypted by the hop-by-hop security mechanism > (i.e. ipsec or tls) or if there is more than one hop between any of > the nodes end-to-end encryption may be used if deemed necessary (e.g. > CMS when it becoms standarized). > > How you set up the hop-by-hop security like ipsec is out of the scope > of the diameter protocol > > /fredrik > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > > Behalf Of Subrata Goswami > > Sent: den 14 oktober 2002 05:20 > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: MIP-Session-Key > > > > > > A simple question, the MIP-Session-Key AVP is used in the following > > AVP's. > > > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-FA-to-MN-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > It is not very clear how { MIP-Session-Key } are encrypted to > > provide privacy in transit, what type of keys are used and how are > > these key's > > > distributed to the > > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > > > > Subrata > > From owner-aaa-wg@merit.edu Tue Oct 15 13:07: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 NAA07744 for ; Tue, 15 Oct 2002 13:07:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D02709120F; Tue, 15 Oct 2002 13:08:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A204591251; Tue, 15 Oct 2002 13:08:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83DBE9120F for ; Tue, 15 Oct 2002 13:08:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E14F5DF8F; Tue, 15 Oct 2002 13:08:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id EC8335DE66 for ; Tue, 15 Oct 2002 13:08:56 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9FH8PPk010881; Tue, 15 Oct 2002 13:08:25 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA16249; Tue, 15 Oct 2002 13:08:57 -0400 (EDT) Date: Tue, 15 Oct 2002 13:08:22 -0400 To: marco.stura@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, pcalhoun@bstormnetworks.com, john.loughney@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. Message-ID: <20021015170822.GB686@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1DA3ED25@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1DA3ED25@esebe016.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 135 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Marco, My point is that even if the discussion based on the performance point of view is valid, it is weired that all Diameter clients and agents mandatory support something that Diameter servers may not use. Instead of defining a new flag in the Diameter header, I think it would be better to define a new accounting application (i.e., realtime or debit accounting) with defining a new AVP (with 'M'-bit set) that is equivalent as D-bit in your proposal. All Diameter clients, intermediate agents, and servers that support the accounting application MUST support the D-bit equivalent AVP. The new accounting application document can contain detailed processing rules instead of describing it in the base specification. What do you think? Yoshihiro Ohba On Tue, Oct 15, 2002 at 05:40:02PM +0300, marco.stura@nokia.com wrote: > Hi, > > I'm not sure my previous mail went through, so I re-send. > > > > It seems that there is an assumption that _all_ Diameter clients and > > agents mandatory support 'D' bit set when failover/failback occurs. > > Otherwise, the scheme will not work as is expected when > > failover/failback occurs at some node that does not set 'D' bit while > > the server supports D-bit handling, resulting in duplicated accounting > > request undetected. > > Yes, the proposal is for diameter base (client and agents) to set the D flag when > failover/failback occur or, only for client, when a stored record is re-sent. > The server may support this scheme or other schemes as already mentioned > in the Annex C. > I guess setting this flag is really minor change. > > > If the assumption is correct, I'm not sure if the scheme is worth > > being defined in the base specification while other accounting > > application does not require this scheme and more generic scheme > > (i.e., hashing) may be able to solve the problem without changing the > > specification. > > I guess hashing is placing additional memory requirement to implementation, here is some > rough number I drafted as an example in some other mail, how much those numbers are accurate > I don't know but they give an idea. The point is that not all the implementations are willing to > use this memory size just to cover cases that happen very seldom , which also translate in cost > for your product. > > I don't know what it could be the hashing function but let's try to analyze what size > the hashing table might be considering the multimedia messaging use case. > Currently in GSM networks people send in average 1 SMS per hour. > If your server need to handle 4 millions of prepaid subscribers it means that in 24 > hours it will get 4*24=96 millions requests. If we consider a Key of 32-bits(4 bytes) > the hashing table should be 96*4= around 370MB. Now if we want to limit the risk of collision > we may double the size to reduce to load factor 370*2=740MB. But I just considered one > service, if we consider other services as well we can safely assume 2 or even 3 requests > per hour per subscriber. > Just with 2 requests per hour the size would double to 740*2= aroun 1.5GB in addition to the > disk database and the memory to run the other server SW. > > Br > Marco > > > -----Original Message----- > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > Sent: 14. October 2002 22:25 > > To: Bernard Aboba > > Cc: Pat Calhoun; Stura Marco (NET/Helsinki); Loughney John > > (NRC/Helsinki); aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > > and proposed > > change. > > > > > > It seems that there is an assumption that _all_ Diameter clients and > > agents mandatory support 'D' bit set when failover/failback occurs. > > Otherwise, the scheme will not work as is expected when > > failover/failback occurs at some node that does not set 'D' bit while > > the server supports D-bit handling, resulting in duplicated accounting > > request undetected. > > > > If the assumption is correct, I'm not sure if the scheme is worth > > being defined in the base specification while other accounting > > application does not require this scheme and more generic scheme > > (i.e., hashing) may be able to solve the problem without changing the > > specification. > > > > Yoshihiro Ohba > > > > > > On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > > > But what would happen if two packets were received by a > > Diameter server > > > > out of order, so the first packet received had the 'D' > > bit set, while > > > > the second packet did not. > > > > > > > > PatC > > > > > > That's where delaying by TIME_WAIT comes in, so that the > > second packet > > > could be processed. > > > > > > > D=1 records are statistically very few and duplicate search > > > > only for those records do not affect the overall performance > > > > of the system. > > > > > > Question: so it wouldn't be an issue if some delay were required in > > > processing those records? > > > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > > > It varies between 30 seconds and 2 minutes. > > > > > > > However proposal #2 could be just to replace the text I proposed > > > > in Annex C that state that D flag may be used by server > > implementation > > > > and specified in diameter application etc. > > > > > > If we're only talking about a few paragraphs in Appendix C, then I'd > > > suggest that we should probably try to hammer this out now. > > However, if > > > using the "D" bit requires more than this, it might need to wait for > > > another application. > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 13: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 NAA08051 for ; Tue, 15 Oct 2002 13:17:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5F58791251; Tue, 15 Oct 2002 13:19:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 28E9291252; Tue, 15 Oct 2002 13:19:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1EEEF91251 for ; Tue, 15 Oct 2002 13:19:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05F645DF92; Tue, 15 Oct 2002 13:19:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id B139A5DF90 for ; Tue, 15 Oct 2002 13:19:04 -0400 (EDT) Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. From: Pat Calhoun To: Yoshihiro Ohba Cc: marco.stura@nokia.com, aboba@internaut.com, john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: <20021015170822.GB686@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1DA3ED25@esebe016.ntc.nokia.com> <20021015170822.GB686@catfish> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 10:19:09 +0000 Message-Id: <1034677149.1678.7.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If one assumes that a Diameter application is modular and "applications" don't need to worry about the base (transport) of messages, then I think that having an application specify the usage of a bit in the message header is misguided. PatC On Tue, 2002-10-15 at 17:08, Yoshihiro Ohba wrote: > Marco, > > My point is that even if the discussion based on the performance point > of view is valid, it is weired that all Diameter clients and agents > mandatory support something that Diameter servers may not use. > > Instead of defining a new flag in the Diameter header, I think it > would be better to define a new accounting application (i.e., realtime > or debit accounting) with defining a new AVP (with 'M'-bit set) that > is equivalent as D-bit in your proposal. All Diameter clients, > intermediate agents, and servers that support the accounting > application MUST support the D-bit equivalent AVP. The new accounting > application document can contain detailed processing rules instead of > describing it in the base specification. > > What do you think? > > Yoshihiro Ohba > > > On Tue, Oct 15, 2002 at 05:40:02PM +0300, marco.stura@nokia.com wrote: > > Hi, > > > > I'm not sure my previous mail went through, so I re-send. > > > > > > > It seems that there is an assumption that _all_ Diameter clients and > > > agents mandatory support 'D' bit set when failover/failback occurs. > > > Otherwise, the scheme will not work as is expected when > > > failover/failback occurs at some node that does not set 'D' bit while > > > the server supports D-bit handling, resulting in duplicated accounting > > > request undetected. > > > > Yes, the proposal is for diameter base (client and agents) to set the D flag when > > failover/failback occur or, only for client, when a stored record is re-sent. > > The server may support this scheme or other schemes as already mentioned > > in the Annex C. > > I guess setting this flag is really minor change. > > > > > If the assumption is correct, I'm not sure if the scheme is worth > > > being defined in the base specification while other accounting > > > application does not require this scheme and more generic scheme > > > (i.e., hashing) may be able to solve the problem without changing the > > > specification. > > > > I guess hashing is placing additional memory requirement to implementation, here is some > > rough number I drafted as an example in some other mail, how much those numbers are accurate > > I don't know but they give an idea. The point is that not all the implementations are willing to > > use this memory size just to cover cases that happen very seldom , which also translate in cost > > for your product. > > > > I don't know what it could be the hashing function but let's try to analyze what size > > the hashing table might be considering the multimedia messaging use case. > > Currently in GSM networks people send in average 1 SMS per hour. > > If your server need to handle 4 millions of prepaid subscribers it means that in 24 > > hours it will get 4*24=96 millions requests. If we consider a Key of 32-bits(4 bytes) > > the hashing table should be 96*4= around 370MB. Now if we want to limit the risk of collision > > we may double the size to reduce to load factor 370*2=740MB. But I just considered one > > service, if we consider other services as well we can safely assume 2 or even 3 requests > > per hour per subscriber. > > Just with 2 requests per hour the size would double to 740*2= aroun 1.5GB in addition to the > > disk database and the memory to run the other server SW. > > > > Br > > Marco > > > > > -----Original Message----- > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > Sent: 14. October 2002 22:25 > > > To: Bernard Aboba > > > Cc: Pat Calhoun; Stura Marco (NET/Helsinki); Loughney John > > > (NRC/Helsinki); aaa-wg@merit.edu > > > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > > > and proposed > > > change. > > > > > > > > > It seems that there is an assumption that _all_ Diameter clients and > > > agents mandatory support 'D' bit set when failover/failback occurs. > > > Otherwise, the scheme will not work as is expected when > > > failover/failback occurs at some node that does not set 'D' bit while > > > the server supports D-bit handling, resulting in duplicated accounting > > > request undetected. > > > > > > If the assumption is correct, I'm not sure if the scheme is worth > > > being defined in the base specification while other accounting > > > application does not require this scheme and more generic scheme > > > (i.e., hashing) may be able to solve the problem without changing the > > > specification. > > > > > > Yoshihiro Ohba > > > > > > > > > On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > > > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > > > > > But what would happen if two packets were received by a > > > Diameter server > > > > > out of order, so the first packet received had the 'D' > > > bit set, while > > > > > the second packet did not. > > > > > > > > > > PatC > > > > > > > > That's where delaying by TIME_WAIT comes in, so that the > > > second packet > > > > could be processed. > > > > > > > > > D=1 records are statistically very few and duplicate search > > > > > only for those records do not affect the overall performance > > > > > of the system. > > > > > > > > Question: so it wouldn't be an issue if some delay were required in > > > > processing those records? > > > > > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > > > > > It varies between 30 seconds and 2 minutes. > > > > > > > > > However proposal #2 could be just to replace the text I proposed > > > > > in Annex C that state that D flag may be used by server > > > implementation > > > > > and specified in diameter application etc. > > > > > > > > If we're only talking about a few paragraphs in Appendix C, then I'd > > > > suggest that we should probably try to hammer this out now. > > > However, if > > > > using the "D" bit requires more than this, it might need to wait for > > > > another application. > > > > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 13:39: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 NAA08786 for ; Tue, 15 Oct 2002 13:39:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8E5C91252; Tue, 15 Oct 2002 13:41:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7895F91253; Tue, 15 Oct 2002 13:41:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 646D191252 for ; Tue, 15 Oct 2002 13:41:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 43A355DF94; Tue, 15 Oct 2002 13:41:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from oak.iea-software.com (mail.iea-software.com [65.103.138.250]) by segue.merit.edu (Postfix) with ESMTP id D5C415DE66 for ; Tue, 15 Oct 2002 13:41:06 -0400 (EDT) Received: from littlesmurf.internal.iea-software.com (littlesmurf.internal.iea-software.com [10.0.0.39]) by iea-software.com (Rockliffe SMTPRA 5.2.5) with ESMTP id ; Tue, 15 Oct 2002 10:22:58 -0700 Date: Tue, 15 Oct 2002 10:41:52 -0700 (Pacific Daylight Time) From: Peter Deacon To: Yoshihiro Ohba Cc: marco.stura@nokia.com, , , , Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. In-Reply-To: <20021015170822.GB686@catfish> Message-ID: X-X-Sender: peterd@mail.internal.iea-software.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, 15 Oct 2002, Yoshihiro Ohba wrote: > Marco, > My point is that even if the discussion based on the performance point > of view is valid, it is weired that all Diameter clients and agents > mandatory support something that Diameter servers may not use. So anything that is retransmitted due to a lack of an application level ack/nak gets the 'D' bit set.... If that's all it is ..seems pretty reasonable to me. Could make it optional but require the 'D' bit always set for servers not supporting the hint. Then folks would just need to keep a short-lived list to dupe check against to handle the out of order senarios. Have Fun! Peter From owner-aaa-wg@merit.edu Tue Oct 15 13:57: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 NAA09729 for ; Tue, 15 Oct 2002 13:57:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 46A4A91220; Tue, 15 Oct 2002 13:59:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 167A791253; Tue, 15 Oct 2002 13:59:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 209E391220 for ; Tue, 15 Oct 2002 13:59:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07B935DF96; Tue, 15 Oct 2002 13:59:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8644C5DF95 for ; Tue, 15 Oct 2002 13:59:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9FGvBx18821; Tue, 15 Oct 2002 09:57:11 -0700 Date: Tue, 15 Oct 2002 09:57:11 -0700 (PDT) From: Bernard Aboba To: Peter Deacon Cc: Yoshihiro Ohba , , , , Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > Could make it optional but require the 'D' bit always set for servers not > supporting the hint. Yes, that's a good point. Do all Diameter implementations need to support this? I think that's the proposal in Issue 372. From owner-aaa-wg@merit.edu Tue Oct 15 13:59: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 NAA09851 for ; Tue, 15 Oct 2002 13:59:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 66DE091253; Tue, 15 Oct 2002 14:01:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 388D391254; Tue, 15 Oct 2002 14:01:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 183E591253 for ; Tue, 15 Oct 2002 14:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3B875DF92; Tue, 15 Oct 2002 14:01:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id AE60F5DD8E for ; Tue, 15 Oct 2002 14:01:41 -0400 (EDT) Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposed change. From: Pat Calhoun To: Bernard Aboba Cc: Peter Deacon , Yoshihiro Ohba , marco.stura@nokia.com, john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 11:01:46 +0000 Message-Id: <1034679706.1701.18.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit optional != useful. I'd argue mandatory on clients, but optionally supported on servers. PatC On Tue, 2002-10-15 at 16:57, Bernard Aboba wrote: > > Could make it optional but require the 'D' bit always set for servers not > > supporting the hint. > > Yes, that's a good point. Do all Diameter implementations need to support > this? I think that's the proposal in Issue 372. > > From owner-aaa-wg@merit.edu Tue Oct 15 14:15: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 OAA10281 for ; Tue, 15 Oct 2002 14:15:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A742A91254; Tue, 15 Oct 2002 14:17:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 70E2C91255; Tue, 15 Oct 2002 14:17:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58A3191254 for ; Tue, 15 Oct 2002 14:17:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 433765DF8F; Tue, 15 Oct 2002 14:17:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 4EE9F5DF76 for ; Tue, 15 Oct 2002 14:17:48 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FIHVw12014 for ; Tue, 15 Oct 2002 21:17:31 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 21:17:46 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 21:17:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Date: Tue, 15 Oct 2002 21:17:46 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Thread-Index: AcJ0dOyCeswT+f+6SQmAvUPMrS1P8gAAeAzA From: To: , Cc: , , , X-OriginalArrivalTime: 15 Oct 2002 18:17:47.0011 (UTC) FILETIME=[29BF0530:01C27477] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10281 Hi all, > optional != useful. I'd argue mandatory on clients, but optionally > supported on servers. > > PatC > On Tue, 2002-10-15 at 16:57, Bernard Aboba wrote: > > > So anything that is retransmitted due to a lack of an application level > > > ack/nak gets the 'D' bit set.... If that's all it is ..seems pretty > > > reasonable to me. > > > > > > Could make it optional but require the 'D' bit always set > > > for servers not supporting the hint. > > > > Yes, that's a good point. Do all Diameter implementations > > need to support this? I think that's the proposal in Issue 372. This is a good compromise. Could we like with this? John From owner-aaa-wg@merit.edu Tue Oct 15 14:25: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 OAA10759 for ; Tue, 15 Oct 2002 14:25:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D26BD91255; Tue, 15 Oct 2002 14:27:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A01AF91256; Tue, 15 Oct 2002 14:27:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77A3791255 for ; Tue, 15 Oct 2002 14:27:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53E235DF96; Tue, 15 Oct 2002 14:27:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 87CB85DF8F for ; Tue, 15 Oct 2002 14:27:34 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9FIRXH14500 for ; Tue, 15 Oct 2002 21:27:33 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 15 Oct 2002 15:55:20 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 15:55:19 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 15 Oct 2002 15:55:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Tue, 15 Oct 2002 15:55:18 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4381@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposed change. Thread-Index: AcJzt31oy7btETifRcCi6WJrgz/G2AAkGAUA From: To: , Cc: , , X-OriginalArrivalTime: 15 Oct 2002 12:55:19.0396 (UTC) FILETIME=[1DAB4240:01C2744A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, > It seems that there is an assumption that _all_ Diameter clients and > agents mandatory support 'D' bit set when failover/failback occurs. > Otherwise, the scheme will not work as is expected when > failover/failback occurs at some node that does not set 'D' bit while > the server supports D-bit handling, resulting in duplicated accounting > request undetected. Yes, the proposal is for diameter base (client and agents) to set the D flag when failover/failback occur or, only for client, when a stored record is re-sent. The server may support this scheme or other schemes as already mentioned in the Annex C. I guess setting this flag is really minor change. > If the assumption is correct, I'm not sure if the scheme is worth > being defined in the base specification while other accounting > application does not require this scheme and more generic scheme > (i.e., hashing) may be able to solve the problem without changing the > specification. I guess hashing is placing additional memory requirement to implementation, here is some rough number I drafted as an example in some other mail, how much those numbers are accurate I don't know but they give an idea. The point is that not all the implementations are willing to use this memory size, which also translate in cost for your product. I don't know what it could be the hashing function but let's try to analyze what size the hashing table might be considering the multimedia messaging use case. Currently in GSM networks people send in average 1 SMS per hour. If your server need to handle 4 millions of prepaid subscribers it means that in 24 hours it will get 4*24=96 millions requests. If we consider a Key of 32-bits(4 bytes) the hashing table should be 96*4= around 370MB. Now if we want to limit the risk of collision we may double the size to reduce to load factor 370*2=740MB. But I just considered one service, if we consider other services as well we can safely assume 2 or even 3 requests per hour per subscriber. Just with 2 requests per hour the size would double to 740*2= aroun 1.5GB in addition to the disk database and the memory to run the other server SW. Br Marco > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 14. October 2002 22:25 > To: Bernard Aboba > Cc: Pat Calhoun; Stura Marco (NET/Helsinki); Loughney John > (NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > and proposed > change. > > > It seems that there is an assumption that _all_ Diameter clients and > agents mandatory support 'D' bit set when failover/failback occurs. > Otherwise, the scheme will not work as is expected when > failover/failback occurs at some node that does not set 'D' bit while > the server supports D-bit handling, resulting in duplicated accounting > request undetected. > > If the assumption is correct, I'm not sure if the scheme is worth > being defined in the base specification while other accounting > application does not require this scheme and more generic scheme > (i.e., hashing) may be able to solve the problem without changing the > specification. > > Yoshihiro Ohba > > > On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > But what would happen if two packets were received by a > Diameter server > > > out of order, so the first packet received had the 'D' > bit set, while > > > the second packet did not. > > > > > > PatC > > > > That's where delaying by TIME_WAIT comes in, so that the > second packet > > could be processed. > > > > > D=1 records are statistically very few and duplicate search > > > only for those records do not affect the overall performance > > > of the system. > > > > Question: so it wouldn't be an issue if some delay were required in > > processing those records? > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > It varies between 30 seconds and 2 minutes. > > > > > However proposal #2 could be just to replace the text I proposed > > > in Annex C that state that D flag may be used by server > implementation > > > and specified in diameter application etc. > > > > If we're only talking about a few paragraphs in Appendix C, then I'd > > suggest that we should probably try to hammer this out now. > However, if > > using the "D" bit requires more than this, it might need to wait for > > another application. > > > > > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 14:27: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 OAA10809 for ; Tue, 15 Oct 2002 14:27:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0ABC91256; Tue, 15 Oct 2002 14:29:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C51891257; Tue, 15 Oct 2002 14:29:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A07E191256 for ; Tue, 15 Oct 2002 14:29:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 88BBC5DF8F; Tue, 15 Oct 2002 14:29:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 454845DF76 for ; Tue, 15 Oct 2002 14:29:37 -0400 (EDT) Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. From: Pat Calhoun To: marco.stura@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E4381@esebe016.ntc.nokia.com> References: <142DC466081D9B409AAD1DDCA4B21E1D9E4381@esebe016.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 11:29:41 +0000 Message-Id: <1034681381.1678.23.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Yes, the proposal is for diameter base (client and agents) to set the D flag when > failover/failback occur or, only for client, when a stored record is re-sent. > The server may support this scheme or other schemes as already mentioned > in the Annex C. > I guess setting this flag is really minor change. Actually, it really isn't that small a change. It will require that everyone now recompute any security hashes on retransmitted packets. Not something that was previously required. (unless the bit is considered a muteable field). PatC From owner-aaa-wg@merit.edu Tue Oct 15 15:06: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 PAA12309 for ; Tue, 15 Oct 2002 15:06:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DE94091257; Tue, 15 Oct 2002 15:08:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A824791258; Tue, 15 Oct 2002 15:08:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83C7991257 for ; Tue, 15 Oct 2002 15:08:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 642355DE66; Tue, 15 Oct 2002 15:08:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id E31E25DE4E for ; Tue, 15 Oct 2002 15:08:44 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9FJ8DPk020539; Tue, 15 Oct 2002 15:08:13 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA16661; Tue, 15 Oct 2002 15:08:45 -0400 (EDT) Date: Tue, 15 Oct 2002 15:08:10 -0400 To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, aboba@internaut.com, peterd@iea-software.com, yohba@tari.toshiba.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Message-ID: <20021015190810.GD686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 52 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Making it mandatory for client only might be better than the original proposal. See my additional comments. The End-to-End Identifier in the header (plus Origin-Host AVP can be also used for duplicate detection, except for the case in which a duplicate accounting record is sent from a rebooted Diameter client with a new End-to-End Identifier. This means that there are basically two cases for duplications: (a) duplication due to a change in diameter message routing, and (b) duplication due to rebooting at a Diameter client. The original D-bit proposal seems to deal with those two cases equally without distinction. Making it mandatory for client only is actually considering separation of the two cases, where case (b) is can be dealt with D-bit set by clients and case (a) can be dealt with E-E ID and Origin-Host AVP. I think this is a better direction to go. On the other hand, we can still argue for defining a new AVP (e.g., Duplication-Indicatation AVP) instead of defining D-bit in the Diameter header, because case (b) is not common to all applications and I think Diameter header should contain information only common to all applications. The new AVP is inserted only by a client which has experianced rebooting and have stored unACK'ed accounting records in a non-volatile memory. Yoshihiro Ohba On Tue, Oct 15, 2002 at 09:17:46PM +0300, john.loughney@nokia.com wrote: > Hi all, > > > optional != useful. I'd argue mandatory on clients, but optionally > > supported on servers. > > > > PatC > > On Tue, 2002-10-15 at 16:57, Bernard Aboba wrote: > > > > So anything that is retransmitted due to a lack of an application level > > > > ack/nak gets the 'D' bit set.... If that's all it is ..seems pretty > > > > reasonable to me. > > > > > > > > Could make it optional but require the 'D' bit always set > > > > for servers not supporting the hint. > > > > > > Yes, that's a good point. Do all Diameter implementations > > > need to support this? I think that's the proposal in Issue 372. > > This is a good compromise. Could we like with this? > > John > From owner-aaa-wg@merit.edu Tue Oct 15 15:20: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 PAA12787 for ; Tue, 15 Oct 2002 15:20:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E9A091258; Tue, 15 Oct 2002 15:22:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E3A691259; Tue, 15 Oct 2002 15:22:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5A21091258 for ; Tue, 15 Oct 2002 15:22:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C1EF5DF44; Tue, 15 Oct 2002 15:22:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id E47FD5DE4E for ; Tue, 15 Oct 2002 15:22:22 -0400 (EDT) Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. From: Pat Calhoun To: Yoshihiro Ohba Cc: john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu In-Reply-To: <20021015190810.GD686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 12:22:27 +0000 Message-Id: <1034684547.1701.31.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit A new AVP may be a better approach, but now requires that the application be involved in the message retransmission engine... not a great idea. However, your point on end-to-end made me think that if an intermediate agent retransmits the packet, it must set the 'D' bit, and this could break e2e packet hash/signature. PatC On Tue, 2002-10-15 at 19:08, Yoshihiro Ohba wrote: > Making it mandatory for client only might be better than the original > proposal. > > See my additional comments. > > The End-to-End Identifier in the header (plus Origin-Host AVP can > be also used for duplicate detection, except for the case in which > a duplicate accounting record is sent from a rebooted Diameter > client with a new End-to-End Identifier. This means that there > are basically two cases for duplications: (a) duplication due to a > change in diameter message routing, and (b) duplication due to > rebooting at a Diameter client. The original D-bit proposal seems > to deal with those two cases equally without distinction. > > Making it mandatory for client only is actually considering > separation of the two cases, where case (b) is can be dealt > with D-bit set by clients and case (a) can be dealt with E-E ID and > Origin-Host AVP. I think this is a better direction to go. > > On the other hand, we can still argue for defining a new AVP (e.g., > Duplication-Indicatation AVP) instead of defining D-bit in the > Diameter header, because case (b) is not common to all applications > and I think Diameter header should contain information only common to > all applications. The new AVP is inserted only by a client which has > experianced rebooting and have stored unACK'ed accounting records in a > non-volatile memory. > > Yoshihiro Ohba > > > On Tue, Oct 15, 2002 at 09:17:46PM +0300, john.loughney@nokia.com wrote: > > Hi all, > > > > > optional != useful. I'd argue mandatory on clients, but optionally > > > supported on servers. > > > > > > PatC > > > On Tue, 2002-10-15 at 16:57, Bernard Aboba wrote: > > > > > So anything that is retransmitted due to a lack of an application level > > > > > ack/nak gets the 'D' bit set.... If that's all it is ..seems pretty > > > > > reasonable to me. > > > > > > > > > > Could make it optional but require the 'D' bit always set > > > > > for servers not supporting the hint. > > > > > > > > Yes, that's a good point. Do all Diameter implementations > > > > need to support this? I think that's the proposal in Issue 372. > > > > This is a good compromise. Could we like with this? > > > > John > > From owner-aaa-wg@merit.edu Tue Oct 15 15:49: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 PAA13401 for ; Tue, 15 Oct 2002 15:48:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E86CD91259; Tue, 15 Oct 2002 15:50:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABEDC9125A; Tue, 15 Oct 2002 15:50:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7340091259 for ; Tue, 15 Oct 2002 15:50:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 530E95DF78; Tue, 15 Oct 2002 15:50:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id D97995DF64 for ; Tue, 15 Oct 2002 15:50:20 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9FJnvPk023927; Tue, 15 Oct 2002 15:49:58 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA16825; Tue, 15 Oct 2002 15:50:30 -0400 (EDT) Date: Tue, 15 Oct 2002 15:49:55 -0400 To: Pat Calhoun Cc: Yoshihiro Ohba , john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Message-ID: <20021015194955.GG686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <1034684547.1701.31.camel@dhcp-229-243> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 78 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 15, 2002 at 12:22:27PM +0000, Pat Calhoun wrote: > A new AVP may be a better approach, but now requires that the > application be involved in the message retransmission engine... not a > great idea. I think retransmission after rebooting based on stored unacknowlegded accounting records is a task of the application (the diameter engine should process them as new requests for which new End-to-End Identifiers are to be assigned), while retransmission after _normal_ failover/failback is a task of the retransmission engine. Better to make a distinction between those two cases. > However, your point on end-to-end made me think that if an > intermediate agent retransmits the packet, it must set the 'D' bit, and > this could break e2e packet hash/signature. By dealing the two duplication cases separately, intermediate agent does not have to set 'D'-bit or insert a new AVP. Yoshihiro Ohba > > PatC > On Tue, 2002-10-15 at 19:08, Yoshihiro Ohba wrote: > > Making it mandatory for client only might be better than the original > > proposal. > > > > See my additional comments. > > > > The End-to-End Identifier in the header (plus Origin-Host AVP can > > be also used for duplicate detection, except for the case in which > > a duplicate accounting record is sent from a rebooted Diameter > > client with a new End-to-End Identifier. This means that there > > are basically two cases for duplications: (a) duplication due to a > > change in diameter message routing, and (b) duplication due to > > rebooting at a Diameter client. The original D-bit proposal seems > > to deal with those two cases equally without distinction. > > > > Making it mandatory for client only is actually considering > > separation of the two cases, where case (b) is can be dealt > > with D-bit set by clients and case (a) can be dealt with E-E ID and > > Origin-Host AVP. I think this is a better direction to go. > > > > On the other hand, we can still argue for defining a new AVP (e.g., > > Duplication-Indicatation AVP) instead of defining D-bit in the > > Diameter header, because case (b) is not common to all applications > > and I think Diameter header should contain information only common to > > all applications. The new AVP is inserted only by a client which has > > experianced rebooting and have stored unACK'ed accounting records in a > > non-volatile memory. > > > > Yoshihiro Ohba > > > > > > On Tue, Oct 15, 2002 at 09:17:46PM +0300, john.loughney@nokia.com wrote: > > > Hi all, > > > > > > > optional != useful. I'd argue mandatory on clients, but optionally > > > > supported on servers. > > > > > > > > PatC > > > > On Tue, 2002-10-15 at 16:57, Bernard Aboba wrote: > > > > > > So anything that is retransmitted due to a lack of an application level > > > > > > ack/nak gets the 'D' bit set.... If that's all it is ..seems pretty > > > > > > reasonable to me. > > > > > > > > > > > > Could make it optional but require the 'D' bit always set > > > > > > for servers not supporting the hint. > > > > > > > > > > Yes, that's a good point. Do all Diameter implementations > > > > > need to support this? I think that's the proposal in Issue 372. > > > > > > This is a good compromise. Could we like with this? > > > > > > John > > > > > From owner-aaa-wg@merit.edu Tue Oct 15 15:56: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 PAA13763 for ; Tue, 15 Oct 2002 15:56:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67A279125A; Tue, 15 Oct 2002 15:58:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B5949125B; Tue, 15 Oct 2002 15:58:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 397CF9125A for ; Tue, 15 Oct 2002 15:58:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E66C5DF64; Tue, 15 Oct 2002 15:58:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id CE5A45DF4F for ; Tue, 15 Oct 2002 15:58:43 -0400 (EDT) Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. From: Pat Calhoun To: Yoshihiro Ohba Cc: john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu In-Reply-To: <20021015194955.GG686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> <20021015194955.GG686@catfish> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 12:58:48 +0000 Message-Id: <1034686728.1678.33.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think retransmission after rebooting based on stored > unacknowlegded accounting records is a task of the application > (the diameter engine should process them as new requests for which > new End-to-End Identifiers are to be assigned), while retransmission > after _normal_ failover/failback is a task of the retransmission > engine. Better to make a distinction between those two cases. fair enough > > However, your point on end-to-end made me think that if an > > intermediate agent retransmits the packet, it must set the 'D' bit, and > > this could break e2e packet hash/signature. > > By dealing the two duplication cases separately, intermediate agent > does not have to set 'D'-bit or insert a new AVP. Not sure I completely understand. Since each intermediate hop is responsible for ack and retransmission, how could it get away with not setting the 'D' bit (or the new AVP for that matter)? PatC From owner-aaa-wg@merit.edu Tue Oct 15 16:26: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 QAA14708 for ; Tue, 15 Oct 2002 16:26:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58C4091221; Tue, 15 Oct 2002 16:28:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E3189125B; Tue, 15 Oct 2002 16:28:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBC6891221 for ; Tue, 15 Oct 2002 16:28:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCABC5DF95; Tue, 15 Oct 2002 16:28:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 5D54D5DF4F for ; Tue, 15 Oct 2002 16:28:18 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9FKS0Pk026218; Tue, 15 Oct 2002 16:28:00 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id QAA16993; Tue, 15 Oct 2002 16:28:32 -0400 (EDT) Date: Tue, 15 Oct 2002 16:27:53 -0400 To: Pat Calhoun Cc: Yoshihiro Ohba , john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Message-ID: <20021015202753.GI686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> <20021015194955.GG686@catfish> <1034686728.1678.33.camel@dhcp-229-243> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <1034686728.1678.33.camel@dhcp-229-243> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 15, 2002 at 12:58:48PM +0000, Pat Calhoun wrote: > > I think retransmission after rebooting based on stored > > unacknowlegded accounting records is a task of the application > > (the diameter engine should process them as new requests for which > > new End-to-End Identifiers are to be assigned), while retransmission > > after _normal_ failover/failback is a task of the retransmission > > engine. Better to make a distinction between those two cases. > fair enough OK. > > > > However, your point on end-to-end made me think that if an > > > intermediate agent retransmits the packet, it must set the 'D' bit, and > > > this could break e2e packet hash/signature. > > > > By dealing the two duplication cases separately, intermediate agent > > does not have to set 'D'-bit or insert a new AVP. > > Not sure I completely understand. Since each intermediate hop is > responsible for ack and retransmission, how could it get away with not > setting the 'D' bit (or the new AVP for that matter)? That part (i.e., duplicated requests based on normal failover/failback) can be detected based solely on the combination of End-to-End Identifier and Origin-Host AVP (perhaps with using either time-based window or hash table at Diameter servers, but without D-bit in the header). > > PatC > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Oct 15 16:48: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 QAA15420 for ; Tue, 15 Oct 2002 16:48:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 910319125B; Tue, 15 Oct 2002 16:50:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60AB29125C; Tue, 15 Oct 2002 16:50:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 509F59125B for ; Tue, 15 Oct 2002 16:50:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C74D5DF24; Tue, 15 Oct 2002 16:50:51 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id EE6AE5DF1D for ; Tue, 15 Oct 2002 16:50:50 -0400 (EDT) Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. From: Pat Calhoun To: Yoshihiro Ohba Cc: john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu In-Reply-To: <20021015202753.GI686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> <20021015194955.GG686@catfish> <1034686728.1678.33.camel@dhcp-229-243> <20021015202753.GI686@catfish> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 15 Oct 2002 13:50:54 +0000 Message-Id: <1034689854.1678.40.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > That part (i.e., duplicated requests based on normal > failover/failback) can be detected based solely on the combination of > End-to-End Identifier and Origin-Host AVP (perhaps with using either > time-based window or hash table at Diameter servers, but without > D-bit in the header). But the comment made earlier is that this scheme doesn't scale when dealing with thousands of messages per minute. I believe you are still arguing the fact that the 'D' bit is really unnecessary, correct? PatC From owner-aaa-wg@merit.edu Tue Oct 15 17:07: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 RAA16057 for ; Tue, 15 Oct 2002 17:07:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 190159125D; Tue, 15 Oct 2002 17:09:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8C5C9125E; Tue, 15 Oct 2002 17:09:25 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D4DA59125D for ; Tue, 15 Oct 2002 17:09:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE4855DF53; Tue, 15 Oct 2002 17:09:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 83DFB5DF24 for ; Tue, 15 Oct 2002 17:09:24 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3ED566A901; Wed, 16 Oct 2002 00:09:14 +0300 (EEST) Message-ID: <3DAC8571.7010101@kolumbus.fi> Date: Wed, 16 Oct 2002 00:15:29 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yoshihiro Ohba Cc: Pat Calhoun , john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> <20021015194955.GG686@catfish> <1034686728.1678.33.camel@dhcp-229-243> <20021015202753.GI686@catfish> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba wrote: >>>By dealing the two duplication cases separately, intermediate agent >>>does not have to set 'D'-bit or insert a new AVP. >> >>Not sure I completely understand. Since each intermediate hop is >>responsible for ack and retransmission, how could it get away with not >>setting the 'D' bit (or the new AVP for that matter)? > > > That part (i.e., duplicated requests based on normal > failover/failback) can be detected based solely on the combination of > End-to-End Identifier and Origin-Host AVP (perhaps with using either > time-based window or hash table at Diameter servers, but without > D-bit in the header). *All* duplication can be detected based on server implementations. Some known methods: - full search every time through a db index - hash table based methods - keeping the last session ids for a user in the user "account" object at the server - heuristic methods, such as tracking correct order and checking duplicates only if we appear to get out-of-order records The current debate is about the speed and efficiency of various ways of doing this, and whether the D-bit helps the server in making the duplicate-or-not decision. There's two kinds of duplicate detection, based on end-to-end id and session id, and based on the session-id and accounting-record-number. Same techniques can be applied to both, however. I believe that if we are to adopt D-bit, then it should be informative, and its setting be made mandatory for clients and agents, and use optional for servers. Question: for all apps, or just for the one that needs this? All duplicate detection should also cover the following cases: - Regular failover duplicate from a client. - Failover from an agent to the server. And here we need to worry about invalidating any signatures; cmssec isn't done yet but I think we need to sign not just the AVPs but also include the command code and the bits. - Reboot and then resend acct records from nvm. This needs care with the d-bit, since the rebooted server must not send d=0 records as they may have been already sent. In general, methods based on protocol information (such as the d-bit) provide duplicate detection that relies on the client and agents to perform it correctly. Implementation and configuration problems, for instance, can't be fixed on the server side in this case. It is debatable, however, whether this is a requirement. (Server-only approaches to duplicate detection do not rely on the other nodes.) Jari From owner-aaa-wg@merit.edu Tue Oct 15 17:21: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 RAA16329 for ; Tue, 15 Oct 2002 17:21:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C6D79125E; Tue, 15 Oct 2002 17:23:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C831A91260; Tue, 15 Oct 2002 17:23:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABDA69125E for ; Tue, 15 Oct 2002 17:23:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 917785DF1D; Tue, 15 Oct 2002 17:23:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 13CB45DE4E for ; Tue, 15 Oct 2002 17:23:33 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9FLN7Pk000859; Tue, 15 Oct 2002 17:23:08 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id RAA17227; Tue, 15 Oct 2002 17:23:35 -0400 (EDT) Date: Tue, 15 Oct 2002 17:22:56 -0400 To: Pat Calhoun Cc: Yoshihiro Ohba , john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Message-ID: <20021015212256.GJ686@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5820@esebe004.ntc.nokia.com> <20021015190810.GD686@catfish> <1034684547.1701.31.camel@dhcp-229-243> <20021015194955.GG686@catfish> <1034686728.1678.33.camel@dhcp-229-243> <20021015202753.GI686@catfish> <1034689854.1678.40.camel@dhcp-229-243> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <1034689854.1678.40.camel@dhcp-229-243> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 25 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Oct 15, 2002 at 01:50:54PM +0000, Pat Calhoun wrote: > > That part (i.e., duplicated requests based on normal > > failover/failback) can be detected based solely on the combination of > > End-to-End Identifier and Origin-Host AVP (perhaps with using either > > time-based window or hash table at Diameter servers, but without > > D-bit in the header). > > But the comment made earlier is that this scheme doesn't scale when > dealing with thousands of messages per minute. I believe you are still > arguing the fact that the 'D' bit is really unnecessary, correct? Might be. As far as I understand, D-bit scheme still needs time-based window. If there is an alternative that will(can) also use time-based window but does not require a new flag in the Diameter header, the alternative should be considered _unless_ the alternative requires much more time window than the other. Introducing a new flag in the common header should be the last resort. > > PatC > > Yoshihiro Ohba From owner-aaa-wg@merit.edu Tue Oct 15 23:54: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 XAA23107 for ; Tue, 15 Oct 2002 23:54:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 35C8B91211; Tue, 15 Oct 2002 23:56:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F169D9121F; Tue, 15 Oct 2002 23:56:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E11B391211 for ; Tue, 15 Oct 2002 23:56:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8D9D5DFC4; Tue, 15 Oct 2002 23:56:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id D32AD5DFBC for ; Tue, 15 Oct 2002 23:56:49 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G3uWw23102 for ; Wed, 16 Oct 2002 06:56:32 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 06:56:48 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 06:56:48 +0300 Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 16 Oct 2002 06:56:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ0gDF1rjYFSWX2TCeylCn4Xf3RdwAR6tLg From: To: , Cc: , , , X-OriginalArrivalTime: 16 Oct 2002 03:56:48.0398 (UTC) FILETIME=[0D39FAE0:01C274C8] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA23107 Hi Pat, > A new AVP may be a better approach, but now requires that the > application be involved in the message retransmission engine... not a > great idea. As I understood, there had been discussion that an AVP could be used, but the same concern that the application would be involved in the retransmission was thought to be an ugly hack. > However, your point on end-to-end made me think that if an > intermediate agent retransmits the packet, it must set the > 'D' bit, and this could break e2e packet hash/signature. So it needs to be done end-to-end or not at all? John From owner-aaa-wg@merit.edu Wed Oct 16 00: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 AAA23615 for ; Wed, 16 Oct 2002 00:19:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5271E9121F; Wed, 16 Oct 2002 00:21:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2051E91267; Wed, 16 Oct 2002 00:21:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 307F09121F for ; Wed, 16 Oct 2002 00:21:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12F2E5DFC2; Wed, 16 Oct 2002 00:21:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 8D33A5DFBB for ; Wed, 16 Oct 2002 00:21:12 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9G3Jah24429; Tue, 15 Oct 2002 20:19:36 -0700 Date: Tue, 15 Oct 2002 20:19:35 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > However, your point on end-to-end made me think that if an > > intermediate agent retransmits the packet, it must set the > > 'D' bit, and this could break e2e packet hash/signature. > > So it needs to be done end-to-end or not at all? I think Pat's point was that the "D" but would need to be considered mutable in any MICs calculated E2E. Transmission layer security is not an issue since this doesn't prevent an agent from setting the "D" bit. My reading of the CMS Security application (correct me if I'm wrong) is that none of the MICs would cover the "D" bit, so it seems to me that this is not an issue. Or am I missing something? If so, can someone point out the specific section and page # (and draft) that describes what would be broken by setting the "D" bit in an intermediate agent? From owner-aaa-wg@merit.edu Wed Oct 16 00:39: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 AAA24920 for ; Wed, 16 Oct 2002 00:39:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A79AE91268; Wed, 16 Oct 2002 00:41:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7132991269; Wed, 16 Oct 2002 00:41:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7770991268 for ; Wed, 16 Oct 2002 00:41:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 51F095DFD6; Wed, 16 Oct 2002 00:41:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 050315DFB8 for ; Wed, 16 Oct 2002 00:41:44 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5FF786A901; Wed, 16 Oct 2002 07:41:37 +0300 (EEST) Message-ID: <3DACEF79.9040604@kolumbus.fi> Date: Wed, 16 Oct 2002 07:47:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection andproposedchange. 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: >>>However, your point on end-to-end made me think that if an >>>intermediate agent retransmits the packet, it must set the >>>'D' bit, and this could break e2e packet hash/signature. >> >>So it needs to be done end-to-end or not at all? > > > I think Pat's point was that the "D" but would need to be considered > mutable in any MICs calculated E2E. Transmission layer security is not an > issue since this doesn't prevent an agent from setting the "D" bit. > > My reading of the CMS Security application (correct me if I'm wrong) is > that none of the MICs would cover the "D" bit, so it seems to me that this > is not an issue. > > Or am I missing something? If so, can someone point out the specific > section and page # (and draft) that describes what would be broken by > setting the "D" bit in an intermediate agent? That page doesn't exist. I think that the CMS application, when ready, should include the command code and other stuff from the header (otherwise you'll see attacks where you have the same protected AVPs, but replace resource allocation request with accounting request etc). As this text in the CMS application is being developed, we could take care of not including the D bit there. John wrote: > So it needs to be done end-to-end or not at all? Duplicates can happen end-to-end and middle-to-end. For the D-bit to be useful, it has to be set in all places that can generate duplicates. So, we really need to handle it even in proxies (if at all)! Jari From owner-aaa-wg@merit.edu Wed Oct 16 01:06: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 BAA25277 for ; Wed, 16 Oct 2002 01:06:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 480D69126A; Wed, 16 Oct 2002 01:08:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 119DA9126B; Wed, 16 Oct 2002 01:08:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19E889126A for ; Wed, 16 Oct 2002 01:08:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 01FEA5DFD4; Wed, 16 Oct 2002 01:08:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 848A55DFD0 for ; Wed, 16 Oct 2002 01:08:08 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9G46T824838; Tue, 15 Oct 2002 21:06:29 -0700 Date: Tue, 15 Oct 2002 21:06:29 -0700 (PDT) From: Bernard Aboba To: Jari Arkko Cc: john.loughney@nokia.com, , Subject: Re: [AAA-WG]: issue: real-time duplicate detection andproposedchange. In-Reply-To: <3DACEF79.9040604@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > That page doesn't exist. OK. I thought I was missing something. > I think that the CMS application, when ready, should include the command > code and other stuff from the header (otherwise you'll see attacks where > you have the same protected AVPs, but replace resource allocation request with > accounting request etc). As this text in the CMS application is being > developed, we could take care of not including the D bit there. Sure, because it's mutable. So does that mean that no existing functionality if broken by the "D" bit? From owner-aaa-wg@merit.edu Wed Oct 16 02:10: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 CAA02951 for ; Wed, 16 Oct 2002 02:10:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B72D9126B; Wed, 16 Oct 2002 02:12:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 550BA9126C; Wed, 16 Oct 2002 02:12:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 184889126B for ; Wed, 16 Oct 2002 02:12:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EB2AF5DFD0; Wed, 16 Oct 2002 02:12:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 045AF5DFCC for ; Wed, 16 Oct 2002 02:12:35 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G6CiM27392 for ; Wed, 16 Oct 2002 09:12:44 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 09:12:33 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 09:12:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Date: Wed, 16 Oct 2002 09:12:33 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED29@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Thread-Index: AcJ0bvhbUJoEUVcZQ12zhKuW5Oh7dgAa+hcw From: To: , Cc: , , X-OriginalArrivalTime: 16 Oct 2002 06:12:33.0733 (UTC) FILETIME=[04397750:01C274DB] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA02951 Hi, I agree with Pat. Also, Bernard already given very good explanation why the AVP approach woudn't work in all the cases etc. Br Marco > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@bstormnetworks.com] > Sent: 15. October 2002 13:19 > To: Yoshihiro Ohba > Cc: Stura Marco (NET/Helsinki); aboba@internaut.com; Loughney John > (NRC/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection and > proposedchange. > > > If one assumes that a Diameter application is modular and > "applications" > don't need to worry about the base (transport) of messages, > then I think > that having an application specify the usage of a bit in the message > header is misguided. > > PatC > > On Tue, 2002-10-15 at 17:08, Yoshihiro Ohba wrote: > > Marco, > > > > My point is that even if the discussion based on the > performance point > > of view is valid, it is weired that all Diameter clients and agents > > mandatory support something that Diameter servers may not use. > > > > Instead of defining a new flag in the Diameter header, I think it > > would be better to define a new accounting application > (i.e., realtime > > or debit accounting) with defining a new AVP (with 'M'-bit set) that > > is equivalent as D-bit in your proposal. All Diameter clients, > > intermediate agents, and servers that support the accounting > > application MUST support the D-bit equivalent AVP. The new > accounting > > application document can contain detailed processing rules > instead of > > describing it in the base specification. > > > > What do you think? > > > > Yoshihiro Ohba > > > > > > On Tue, Oct 15, 2002 at 05:40:02PM +0300, > marco.stura@nokia.com wrote: > > > Hi, > > > > > > I'm not sure my previous mail went through, so I re-send. > > > > > > > > > > It seems that there is an assumption that _all_ > Diameter clients and > > > > agents mandatory support 'D' bit set when > failover/failback occurs. > > > > Otherwise, the scheme will not work as is expected when > > > > failover/failback occurs at some node that does not set > 'D' bit while > > > > the server supports D-bit handling, resulting in > duplicated accounting > > > > request undetected. > > > > > > Yes, the proposal is for diameter base (client and > agents) to set the D flag when > > > failover/failback occur or, only for client, when a > stored record is re-sent. > > > The server may support this scheme or other schemes as > already mentioned > > > in the Annex C. > > > I guess setting this flag is really minor change. > > > > > > > If the assumption is correct, I'm not sure if the > scheme is worth > > > > being defined in the base specification while other accounting > > > > application does not require this scheme and more generic scheme > > > > (i.e., hashing) may be able to solve the problem > without changing the > > > > specification. > > > > > > I guess hashing is placing additional memory requirement > to implementation, here is some > > > rough number I drafted as an example in some other mail, > how much those numbers are accurate > > > I don't know but they give an idea. The point is that not > all the implementations are willing to > > > use this memory size just to cover cases that happen very > seldom , which also translate in cost > > > for your product. > > > > > > I don't know what it could be the hashing function but > let's try to analyze what size > > > the hashing table might be considering the multimedia > messaging use case. > > > Currently in GSM networks people send in average 1 SMS per hour. > > > If your server need to handle 4 millions of prepaid > subscribers it means that in 24 > > > hours it will get 4*24=96 millions requests. If we > consider a Key of 32-bits(4 bytes) > > > the hashing table should be 96*4= around 370MB. Now if we > want to limit the risk of collision > > > we may double the size to reduce to load factor > 370*2=740MB. But I just considered one > > > service, if we consider other services as well we can > safely assume 2 or even 3 requests > > > per hour per subscriber. > > > Just with 2 requests per hour the size would double to > 740*2= aroun 1.5GB in addition to the > > > disk database and the memory to run the other server SW. > > > > > > Br > > > Marco > > > > > > > -----Original Message----- > > > > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > > > > Sent: 14. October 2002 22:25 > > > > To: Bernard Aboba > > > > Cc: Pat Calhoun; Stura Marco (NET/Helsinki); Loughney John > > > > (NRC/Helsinki); aaa-wg@merit.edu > > > > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > > > > and proposed > > > > change. > > > > > > > > > > > > It seems that there is an assumption that _all_ > Diameter clients and > > > > agents mandatory support 'D' bit set when > failover/failback occurs. > > > > Otherwise, the scheme will not work as is expected when > > > > failover/failback occurs at some node that does not set > 'D' bit while > > > > the server supports D-bit handling, resulting in > duplicated accounting > > > > request undetected. > > > > > > > > If the assumption is correct, I'm not sure if the > scheme is worth > > > > being defined in the base specification while other accounting > > > > application does not require this scheme and more generic scheme > > > > (i.e., hashing) may be able to solve the problem > without changing the > > > > specification. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Mon, Oct 14, 2002 at 09:54:44AM -0700, Bernard Aboba wrote: > > > > > On 14 Oct 2002, Pat Calhoun wrote: > > > > > > > > > > > But what would happen if two packets were received by a > > > > Diameter server > > > > > > out of order, so the first packet received had the 'D' > > > > bit set, while > > > > > > the second packet did not. > > > > > > > > > > > > PatC > > > > > > > > > > That's where delaying by TIME_WAIT comes in, so that the > > > > second packet > > > > > could be processed. > > > > > > > > > > > D=1 records are statistically very few and duplicate search > > > > > > only for those records do not affect the overall performance > > > > > > of the system. > > > > > > > > > > Question: so it wouldn't be an issue if some delay > were required in > > > > > processing those records? > > > > > > > > > > > I guess Time_Wait may be couple of seconds, am I right? > > > > > > > > > > It varies between 30 seconds and 2 minutes. > > > > > > > > > > > However proposal #2 could be just to replace the > text I proposed > > > > > > in Annex C that state that D flag may be used by server > > > > implementation > > > > > > and specified in diameter application etc. > > > > > > > > > > If we're only talking about a few paragraphs in > Appendix C, then I'd > > > > > suggest that we should probably try to hammer this out now. > > > > However, if > > > > > using the "D" bit requires more than this, it might > need to wait for > > > > > another application. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-aaa-wg@merit.edu Wed Oct 16 03:02: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 DAA20469 for ; Wed, 16 Oct 2002 03:02:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC1689126C; Wed, 16 Oct 2002 03:04:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A7AA79126D; Wed, 16 Oct 2002 03:04:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 60CD39126C for ; Wed, 16 Oct 2002 03:04:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AD625DFDF; Wed, 16 Oct 2002 03:04:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id 485DF5DFC5 for ; Wed, 16 Oct 2002 03:04:08 -0400 (EDT) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G74HM22945 for ; Wed, 16 Oct 2002 10:04:17 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 10:04:03 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 10:04:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Date: Wed, 16 Oct 2002 10:04:02 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4388@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ00hpYJ2IKQYjnQwaxk7JLgR58IwADbrEQ From: To: , Cc: , , X-OriginalArrivalTime: 16 Oct 2002 07:04:03.0044 (UTC) FILETIME=[3598EA40:01C274E2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20469 Hi, > I think that the CMS application, when ready, should include > the command > code and other stuff from the header (otherwise you'll see > attacks where > you have the same protected AVPs, but replace resource > allocation request with > accounting request etc). As this text in the CMS application is being > developed, we could take care of not including the D bit there. I think what Jari say should be possible, it could be that D bit is not included. > Duplicates can happen end-to-end and middle-to-end. For the > D-bit to be > useful, it has to be set in all places that can generate > duplicates. So, > we really need to handle it even in proxies (if at all)! I also agree with this, D flag to be useful need to be handled even in Diameter agents (proxy, relay..). Br Marco > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 16. October 2002 7:48 > To: Bernard Aboba > Cc: Loughney John (NRC/Helsinki); pcalhoun@bstormnetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > andproposedchange. > > > Bernard Aboba wrote: > >>>However, your point on end-to-end made me think that if an > >>>intermediate agent retransmits the packet, it must set the > >>>'D' bit, and this could break e2e packet hash/signature. > >> > >>So it needs to be done end-to-end or not at all? > > > > > > I think Pat's point was that the "D" but would need to be considered > > mutable in any MICs calculated E2E. Transmission layer > security is not an > > issue since this doesn't prevent an agent from setting the "D" bit. > > > > My reading of the CMS Security application (correct me if > I'm wrong) is > > that none of the MICs would cover the "D" bit, so it seems > to me that this > > is not an issue. > > > > Or am I missing something? If so, can someone point out the specific > > section and page # (and draft) that describes what would be > broken by > > setting the "D" bit in an intermediate agent? > > That page doesn't exist. > > I think that the CMS application, when ready, should include > the command > code and other stuff from the header (otherwise you'll see > attacks where > you have the same protected AVPs, but replace resource > allocation request with > accounting request etc). As this text in the CMS application is being > developed, we could take care of not including the D bit there. > > John wrote: > > > So it needs to be done end-to-end or not at all? > > Duplicates can happen end-to-end and middle-to-end. For the > D-bit to be > useful, it has to be set in all places that can generate > duplicates. So, > we really need to handle it even in proxies (if at all)! > > Jari > > > From owner-aaa-wg@merit.edu Wed Oct 16 03:04: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 DAA20518 for ; Wed, 16 Oct 2002 03:04:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 095689126D; Wed, 16 Oct 2002 03:06:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD1609126E; Wed, 16 Oct 2002 03:06:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 808069126D for ; Wed, 16 Oct 2002 03:06:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 626335DFDF; Wed, 16 Oct 2002 03:06:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id ABF6E5DFC5 for ; Wed, 16 Oct 2002 03:06:09 -0400 (EDT) Received: from fmorn1dcode948i (a12.local.ipunplugged.com [192.168.4.182]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g9G75i24030955; Wed, 16 Oct 2002 09:05:44 +0200 From: "Fredrik Johansson" To: "Subrata Goswami" , Subject: RE: [AAA-WG]: MIP-Session-Key Date: Wed, 16 Oct 2002 09:07:07 +0200 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 In-Reply-To: <000301c27469$cfb6d890$c900a8c0@SGOSWAMIPCL> Importance: Normal X-RAVMilter-Version: 8.4.1(snapshot 20020919) (mailgw) Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subrata, > > Frederik, no that is exactly what is used. IPSec and TLS are totally > different > protocols and it is not necessary for Diameter MIP Application to set up > > point-to-point encrypted links as they do. taken from the base draft. "2.2 Securing Diameter Messages Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec). 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. See sections 13.1 and 13.2 for more details on IPsec and TLS usage." So why should you encrypt the mip-session-keys again if the transport is secured? The only case where you need to encrypt the mip-session-keys would be if there are several hops between the sender and receiver, if so use CMS /fredrik Setting up these > point-to-point > links would be a nightmare and frankly no one is probably going to use > that > approach in a large network with many subnets. Take a look at the > Diameter > Mobile IP application, see how many hops are there. > > A better approach is what I suggested, encrypt MIP-Session-Keys with > security > associations between a AAA agent and the entity. I am not sure CMS > handles this > issue. It is not about end-to-end vs. point-to-point, it is more about > how many > shared secrets needs to be deployed per session - in case of Diameter > Mobile IP > application that number is 3 if you include FA-HA in addition to MN-FA, > MN-HA. The > number would double if a unidirectional key is used. Also, keep in mind > as Diameter Mobile IP Application is a key distribution mechanism, there > could be > other keys that it would have distribute in the very near future. > > Subrata > > > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of Fredrik Johansson > Sent: Tuesday, October 15, 2002 2:18 AM > To: Subrata Goswami; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf > > Of Subrata Goswami > > Sent: den 14 oktober 2002 17:28 > > To: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > Fredrik, so you are saying each of the different pair of entities > > would have to be provisioned with a distinct key or a private > > key/certificate. How is situation > > handled when there is no existing security association ? > > There MUST be a hop-by-hop security mechanism, either ipsec or tls > according to the protocol > > > Also, if you > > look into > > the following 3 AVP that I mentioned, there is no SPI specified for > > the MIP-HA-to-FA-Key and the MIP-HA-to-MN-Key. Would not it be better > > > to have a security association > > between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt the > > MIP-Session-Keys ? > > that's exactly what's used, since the whole message between the FA-AAAF > and HA-AAAH is encrypted with the hop-by-hop security mechanism the keys > are encrypted, if there are several hops between each node a end-to-end > security mechanism should be used (e.g. cms) > > /fredrik > > > > > Subrata > > > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > > > Of Fredrik Johansson > > Sent: Sunday, October 13, 2002 11:38 PM > > To: Subrata Goswami; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > Hi Subrata, > > > > The MIP-Session-Key is encrypted by the hop-by-hop security mechanism > > (i.e. ipsec or tls) or if there is more than one hop between any of > > the nodes end-to-end encryption may be used if deemed necessary (e.g. > > CMS when it becoms standarized). > > > > How you set up the hop-by-hop security like ipsec is out of the scope > > of the diameter protocol > > > > /fredrik > > > > > -----Original Message----- > > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > > > Behalf Of Subrata Goswami > > > Sent: den 14 oktober 2002 05:20 > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: MIP-Session-Key > > > > > > > > > A simple question, the MIP-Session-Key AVP is used in the following > > > AVP's. > > > > > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > { MIP-FA-to-MN-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > It is not very clear how { MIP-Session-Key } are encrypted to > > > provide privacy in transit, what type of keys are used and how are > > > these key's > > > > > distributed to the > > > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > > > > > > > Subrata > > > From owner-aaa-wg@merit.edu Wed Oct 16 03:16: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 DAA20753 for ; Wed, 16 Oct 2002 03:16:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 442849126F; Wed, 16 Oct 2002 03:18:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0599991270; Wed, 16 Oct 2002 03:18:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CF4B39126F for ; Wed, 16 Oct 2002 03:18:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADFB55DFDF; Wed, 16 Oct 2002 03:18:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id ADAD65DFC5 for ; Wed, 16 Oct 2002 03:18:43 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G7IgH23576 for ; Wed, 16 Oct 2002 10:18:43 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 10:18:42 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 10:18:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Date: Wed, 16 Oct 2002 10:18:17 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4389@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection and proposedchange. Thread-Index: AcJ0jyIi+ua/GQenRYCbNG4DyJC64QAU2iPA From: To: , Cc: , , , , X-OriginalArrivalTime: 16 Oct 2002 07:18:18.0121 (UTC) FILETIME=[33434F90:01C274E4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jari wrote >I believe that if we are to adopt D-bit, then it should be informative, >and its setting be made mandatory for clients and agents, and use optional >for servers. Question: for all apps, or just for the one that needs >this? I guess all applications may use the D flag scheme as any other scheme you mentioned. > - full search every time through a db index > - hash table based methods > - keeping the last session ids for a user in the user > "account" object at the > server > - heuristic methods, such as tracking correct order and checking > duplicates only if we appear to get out-of-order records Would it be acceptable that all apllication may use this scheme and actually may be defined in the application which scheme to use? Br Marco > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: 16. October 2002 0:15 > To: Yoshihiro Ohba > Cc: Pat Calhoun; Loughney John (NRC/Helsinki); aboba@internaut.com; > peterd@iea-software.com; Stura Marco (NET/Helsinki); aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection and > proposedchange. > > > Yoshihiro Ohba wrote: > > >>>By dealing the two duplication cases separately, intermediate agent > >>>does not have to set 'D'-bit or insert a new AVP. > >> > >>Not sure I completely understand. Since each intermediate hop is > >>responsible for ack and retransmission, how could it get > away with not > >>setting the 'D' bit (or the new AVP for that matter)? > > > > > > That part (i.e., duplicated requests based on normal > > failover/failback) can be detected based solely on the > combination of > > End-to-End Identifier and Origin-Host AVP (perhaps with using either > > time-based window or hash table at Diameter servers, but without > > D-bit in the header). > > *All* duplication can be detected based on server implementations. > Some known methods: > - full search every time through a db index > - hash table based methods > - keeping the last session ids for a user in the user > "account" object at the > server > - heuristic methods, such as tracking correct order and checking > duplicates only if we appear to get out-of-order records > The current debate is about the speed and efficiency of various > ways of doing this, and whether the D-bit helps the server in making > the duplicate-or-not decision. > > There's two kinds of duplicate detection, based on end-to-end id and > session id, and based on the session-id and accounting-record-number. > Same techniques can be applied to both, however. > > I believe that if we are to adopt D-bit, then it should be > informative, > and its setting be made mandatory for clients and agents, and > use optional > for servers. Question: for all apps, or just for the one that needs > this? > > All duplicate detection should also cover the following cases: > - Regular failover duplicate from a client. > - Failover from an agent to the server. And here we need > to worry about invalidating any signatures; cmssec isn't > done yet but I think we need to sign not just the AVPs > but also include the command code and the bits. > - Reboot and then resend acct records from nvm. This needs > care with the d-bit, since the rebooted server must not > send d=0 records as they may have been already sent. > > In general, methods based on protocol information (such as the d-bit) > provide duplicate detection that relies on the client and agents > to perform it correctly. Implementation and configuration problems, > for instance, can't be fixed on the server side in this case. It is > debatable, however, whether this is a requirement. > (Server-only approaches > to duplicate detection do not rely on the other nodes.) > > Jari > > From owner-aaa-wg@merit.edu Wed Oct 16 04:27: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 EAA22108 for ; Wed, 16 Oct 2002 04:27:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE96C91226; Wed, 16 Oct 2002 04:29:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 907C591271; Wed, 16 Oct 2002 04:29:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E2CB91226 for ; Wed, 16 Oct 2002 04:29:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65B175DE10; Wed, 16 Oct 2002 04:29:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 9FCCF5DFE7 for ; Wed, 16 Oct 2002 04:29:24 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9G8TNH20830 for ; Wed, 16 Oct 2002 11:29:24 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 11:29:23 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 11:29:23 +0300 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 16 Oct 2002 11:29:22 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A583E@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ00gPYx2Ur3FGjQUmdum+VcFB1zgAHA5Mw From: To: , Cc: , X-OriginalArrivalTime: 16 Oct 2002 08:29:23.0591 (UTC) FILETIME=[21AE6170:01C274EE] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA22108 Hi Bernard, > So does that mean that no existing functionality if broken by > the "D" bit? That is my understanding - no existing function is broken by the D bit. John From owner-aaa-wg@merit.edu Wed Oct 16 06:45: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 GAA24208 for ; Wed, 16 Oct 2002 06:45:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8C3219120A; Wed, 16 Oct 2002 06:47:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C0F991227; Wed, 16 Oct 2002 06:47:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3D9279120A for ; Wed, 16 Oct 2002 06:47:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 236755DFF4; Wed, 16 Oct 2002 06:47:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id DCD6D5DE10 for ; Wed, 16 Oct 2002 06:47:20 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F28996A908; Wed, 16 Oct 2002 13:47:15 +0300 (EEST) Message-ID: <3DAD452C.6090904@kolumbus.fi> Date: Wed, 16 Oct 2002 13:53:32 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marco.stura@nokia.com Cc: yohba@tari.toshiba.com, pcalhoun@bstormnetworks.com, john.loughney@nokia.com, aboba@internaut.com, peterd@iea-software.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection and proposedchange. References: <142DC466081D9B409AAD1DDCA4B21E1D9E4389@esebe016.ntc.nokia.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com wrote: >>- full search every time through a db index >>- hash table based methods >>- keeping the last session ids for a user in the user >>"account" object at the >> server >>- heuristic methods, such as tracking correct order and checking >> duplicates only if we appear to get out-of-order records > > > Would it be acceptable that all apllication may use this scheme and actually may be > defined in the application which scheme to use? I view this rather as an implementation decision on the server side (I would use something else but that's just my own preference). I can agree, however, that the clients & agents can set an informative bit on when they (a) know that this is an app-layer retransmission or (b) don't know if this has been transmitted before. We also need to be careful about the semantics of of the bit defined in the document; perhaps we shouldn't say much more than (a) & (b) above. And maybe we need to warn the reader that they can't detect duplicates only based on the bit (also need to look for D=1, D=0 order; configuration errors, etc). If there's a need to say more, maybe that's up to implementations or profiles in e.g. 3GPP specifications. Jari From owner-aaa-wg@merit.edu Wed Oct 16 06:59: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 GAA24334 for ; Wed, 16 Oct 2002 06:59:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 120F891227; Wed, 16 Oct 2002 07:00:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D20A191271; Wed, 16 Oct 2002 07:00:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A551891227 for ; Wed, 16 Oct 2002 07:00:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6945D5DFFB; Wed, 16 Oct 2002 07:00:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 4F9115DFFF for ; Wed, 16 Oct 2002 07:00:14 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9GB08H23102 for ; Wed, 16 Oct 2002 14:00:13 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 14:00:07 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 14:00:07 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 14:00:07 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Date: Wed, 16 Oct 2002 14:00:06 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED32@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ004su6qmIHhXzQy28Zs2Swc7VZQAL4a6g From: To: , Cc: , , X-OriginalArrivalTime: 16 Oct 2002 11:00:07.0327 (UTC) FILETIME=[302AFAF0:01C27503] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA24334 Hi Bernard, > So does that mean that no existing functionality if broken by > the "D" bit? My understanding is that no existing functinality is broken unless I'm missing something, can someone correct me if I'm wrong? Also I have to admit that I never mentioned how the server may use this D flag, and that the title of the issue is somehow misleading as well as better explanation "why D-bit" is missed. Probably a better title would have been "duplicate detection for real-time accounting application" and I try a better explanation in a sperate mail, which follows this mail. thanks, Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 16. October 2002 7:06 > To: Jari Arkko > Cc: Loughney John (NRC/Helsinki); pcalhoun@bstormnetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: issue: real-time duplicate detection > andproposedchange. > > > > That page doesn't exist. > > OK. I thought I was missing something. > > > I think that the CMS application, when ready, should > include the command > > code and other stuff from the header (otherwise you'll see > attacks where > > you have the same protected AVPs, but replace resource > allocation request with > > accounting request etc). As this text in the CMS > application is being > > developed, we could take care of not including the D bit there. > > Sure, because it's mutable. > > So does that mean that no existing functionality if broken by > the "D" bit? > > > From owner-aaa-wg@merit.edu Wed Oct 16 07:48: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 HAA25388 for ; Wed, 16 Oct 2002 07:48:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0587191271; Wed, 16 Oct 2002 07:50:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B71DA91272; Wed, 16 Oct 2002 07:50:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92AE991271 for ; Wed, 16 Oct 2002 07:50:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 772EF5DF8E; Wed, 16 Oct 2002 07:50:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 0600A5DE10 for ; Wed, 16 Oct 2002 07:50:10 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9GBnqw12345 for ; Wed, 16 Oct 2002 14:49:52 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 14:50:08 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 14:50:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 14:50:08 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E438C@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ004su6qmIHhXzQy28Zs2Swc7VZQAL4a6gAAFt1mA= From: To: , Cc: , , X-OriginalArrivalTime: 16 Oct 2002 11:50:08.0488 (UTC) FILETIME=[2CFFCE80:01C2750A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA25388 Hi again, here the mail that try better explanation of the D-bit. For real-time accounting applications, such as the Diameter Credit Control draft, it is important to immediately process the original request (D=0) since action by the client (action to the user) will be taken if the answer doesn't come within a certain time. As the user cannot wait for the service to be granted for 20 or 30 seconds, usually a real-time accounting application defines a "waiting timer" after which expiration the service is granted or not granted to the end user. A value of the timer is about 10sec. The client behavior is usually controlled by some "failure handling" parameter. For example the failure handling for "one time event" direct debiting in case "waiting timer" expires could be "grant the service and store the request" or "grant the service and forget the request", this is configurable by the service provider. Storing the request is a sort of back-up to give a chance to the service provider that the used service may be debited to the user's account later and revenue is not lost. If a duplicate happens to reach the server, the "waiting timer" is normally expired and proper action to the end user already been taken. This "one time event" direct debiting could be applicable to messaging services, for example. For session based services e.g. VoIP or data services the one time event approach is likely not applicable since online monitoring of the ongoing session is needed. In this cases start/interim/stop approach where money is reserved first and debited only when consumed by the service is the best solution. A stateful server would be used and also in this case is important to immediately process the original request (D=0). Sice stateful server would be used, moving the accounting data stream to alternate server shouldn't be possible. However duplicate may happen also in this case. In all cases when duplicate happen to reach the server, the client application "waiting timer" is normally expired and proper action to the end user already been taken. Conclusion of the above is: 1- original request (D=0) must be processed immediately. 2- no hurry to process the duplicate (D=1) When D=0, no checking is needed in the Server and the record is immediately processed. Only when a D=1 accounting record is encountered, then the checkings are done (its AVP pair against the other Session-ID & Accounting-record-Number AVP pairs of the +/- time window). When D=1, its Session-ID & Accounting-Record-Number AVP pair is buffered for a possible future check, but no check is needed in normal case. A link failover procedure (causing the D-bit to be used for the last few yet unacknowledged accounting records, the amount being in maximum the protocol window size of records only) occurs e.g. during 2-3 days per year, so the rareness of the D=1 case causes that 1- most of the time there are no extra checkings at all (when using the D-bit). 2- when there are checkings the search is done just for the few D=1 and only within the configurable time window to the future & past. (Of course, the checks can be Session-ID based). 3- only limited amount of resourses for duplicate detection are required in the Server. Out of order records shouldn't be an issue because of the +/- time window. The key is that once a record arriving from Diameter client to a Diameter server and is marked with D=1, then ***if the original is not found in the +- time window (e.g. TIME_WAIT),then the D=1 mark is not removed*** from the accounting record when sending it further towards the end system. The network's accounting end system can be understood and implemented as a _central logical entity_(no matter if it would physically consist of several servers). It could then be left to the end system to compare the possible still existing (very, very few!) D=1 marked records against others in a configurable +- time window. I hope the above clarify some of the discussed topics. Br Marco From owner-aaa-wg@merit.edu Wed Oct 16 08:29: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 IAA26877 for ; Wed, 16 Oct 2002 08:29:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A39391229; Wed, 16 Oct 2002 08:30:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0407291272; Wed, 16 Oct 2002 08:30:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1024891229 for ; Wed, 16 Oct 2002 08:30:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A66CC5DFFC; Wed, 16 Oct 2002 08:30:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id EE6E65DFEE for ; Wed, 16 Oct 2002 08:30:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9GBSoO29400 for ; Wed, 16 Oct 2002 04:28:50 -0700 Date: Wed, 16 Oct 2002 04:28:50 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-diameter-mobileip-13.txt to IETF last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Tue, 15 Oct 2002 23:52:50 -0700 From: Randy Bush To: Bernard Aboba Cc: ietf-secretariat@ietf.org Subject: draft-ietf-aaa-diameter-mobileip-13.txt > The AAA WG has now completed working group last call on the Diameter > Mobile IPv4 application document with 3 comments: Issues 351, 368 and 369. > > Comments received during this and previous AAA WG last calls are available > for inspection at: > > http://www.drizzle.com/~aboba/AAA/issues.html > > AAA WG last call comments have been resolved and reflected in a new > document version posted on the IETF archive: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt > > As a result, the AAA WG recommends that the IESG begin IETF last call on > this document, in order to consider it for adoption as an IETF Proposed > Standard. secretariat, please issue ietf last call for proposed. thank you. randy From owner-aaa-wg@merit.edu Wed Oct 16 08:29: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 IAA26950 for ; Wed, 16 Oct 2002 08:29:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0578391277; Wed, 16 Oct 2002 08:31:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6953391273; Wed, 16 Oct 2002 08:31:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8967791272 for ; Wed, 16 Oct 2002 08:31:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 439435E027; Wed, 16 Oct 2002 08:30:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BDBAB5DFFD for ; Wed, 16 Oct 2002 08:30:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9GBT6M29404 for ; Wed, 16 Oct 2002 04:29:06 -0700 Date: Wed, 16 Oct 2002 04:29:06 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-transport-08.txt to IETF last call Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk ---------- Forwarded message ---------- Date: Tue, 15 Oct 2002 23:54:56 -0700 From: Randy Bush To: Bernard Aboba Cc: IESG Secretary Subject: draft-ietf-aaa-transport-08.txt > The AAA WG has now completed working group last call on the AAA > Transport Profile document with no comments. > > Comments received during this and previous AAA WG last calls are available > for inspection at: > > http://www.drizzle.com/~aboba/AAA/issues.html > > The latest version of the document posted on the IETF archive is: > > http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt > > As a result, the AAA WG recommends that the IESG begin IETF last call on > this document, in order to consider it for adoption as an IETF Proposed > Standard. secretariat, please issue ietf last call on draft-ietf-aaa-transport-08.txt thank you randy From owner-aaa-wg@merit.edu Wed Oct 16 08:44: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 IAA27339 for ; Wed, 16 Oct 2002 08:44:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4BB8291275; Wed, 16 Oct 2002 08:46:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E6E6491278; Wed, 16 Oct 2002 08:46:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC32C91275 for ; Wed, 16 Oct 2002 08:46:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8FBDC5E05F; Wed, 16 Oct 2002 08:45:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id 44E6A5DFFD for ; Wed, 16 Oct 2002 08:45:53 -0400 (EDT) Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. From: Pat Calhoun To: john.loughney@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 05:45:58 +0000 Message-Id: <1034747158.24526.4.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > > A new AVP may be a better approach, but now requires that the > > application be involved in the message retransmission engine... not a > > great idea. > > As I understood, there had been discussion that an AVP could > be used, but the same concern that the application would > be involved in the retransmission was thought to be an ugly > hack. correct. So my preference is to have the base protocol handle this feature. > > > However, your point on end-to-end made me think that if an > > intermediate agent retransmits the packet, it must set the > > 'D' bit, and this could break e2e packet hash/signature. > > So it needs to be done end-to-end or not at all? Not if the bit is defined as a muteable (sp?) field, meaning that it is always set to zero prior to any form of hashing. PatC From owner-aaa-wg@merit.edu Wed Oct 16 08:45: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 IAA27370 for ; Wed, 16 Oct 2002 08:45:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5CA5B91276; Wed, 16 Oct 2002 08:47:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 283E891278; Wed, 16 Oct 2002 08:47:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C3CA91276 for ; Wed, 16 Oct 2002 08:47:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F02AC5DFFF; Wed, 16 Oct 2002 08:47:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from bsn-mail-01.bstormnetworks.com (unknown [209.11.156.50]) by segue.merit.edu (Postfix) with ESMTP id A5DB25DFFD for ; Wed, 16 Oct 2002 08:47:16 -0400 (EDT) Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. From: Pat Calhoun To: Bernard Aboba Cc: john.loughney@nokia.com, aaa-wg@merit.edu In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Date: 16 Oct 2002 05:47:22 +0000 Message-Id: <1034747243.24544.6.camel@dhcp-229-243> Mime-Version: 1.0 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I think Pat's point was that the "D" but would need to be considered > mutable in any MICs calculated E2E. Transmission layer security is not an > issue since this doesn't prevent an agent from setting the "D" bit. Correct. > My reading of the CMS Security application (correct me if I'm wrong) is > that none of the MICs would cover the "D" bit, so it seems to me that this > is not an issue. > > Or am I missing something? If so, can someone point out the specific > section and page # (and draft) that describes what would be broken by > setting the "D" bit in an intermediate agent? Ah, perhaps I've been away for too long, and the CMS draft doesn't cover the message header. In which case, I slowly crawl back under my rock. PatC From owner-aaa-wg@merit.edu Wed Oct 16 08:49: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 IAA27572 for ; Wed, 16 Oct 2002 08:49:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1BD091278; Wed, 16 Oct 2002 08:51:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BD55291279; Wed, 16 Oct 2002 08:51:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D9EB691278 for ; Wed, 16 Oct 2002 08:51:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C07B25DFFD; Wed, 16 Oct 2002 08:51:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 490E75DFEE for ; Wed, 16 Oct 2002 08:51:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9GBnWJ29679; Wed, 16 Oct 2002 04:49:32 -0700 Date: Wed, 16 Oct 2002 04:49:32 -0700 (PDT) From: Bernard Aboba To: Pat Calhoun Cc: john.loughney@nokia.com, Subject: RE: [AAA-WG]: issue: real-time duplicate detection andproposedchange. In-Reply-To: <1034747243.24544.6.camel@dhcp-229-243> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > My reading of the CMS Security application (correct me if I'm wrong) is > > that none of the MICs would cover the "D" bit, so it seems to me that this > > is not an issue. > > > > Or am I missing something? If so, can someone point out the specific > > section and page # (and draft) that describes what would be broken by > > setting the "D" bit in an intermediate agent? > > Ah, perhaps I've been away for too long, and the CMS draft doesn't cover > the message header. In which case, I slowly crawl back under my rock. Thanks for crawling out -- you helped us find a bug in CMS :) The CMS draft SHOULD cover portions of the header (to avoid cut and paste attack) but does not. I will file an issue on this. From owner-aaa-wg@merit.edu Wed Oct 16 09: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 JAA28870 for ; Wed, 16 Oct 2002 09:33:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD6719127B; Wed, 16 Oct 2002 09:35:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F1639127C; Wed, 16 Oct 2002 09:35:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86E7C9127B for ; Wed, 16 Oct 2002 09:35:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 638F35E003; Wed, 16 Oct 2002 09:35:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id BEADA5E002 for ; Wed, 16 Oct 2002 09:35:44 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9GDZDPk025518; Wed, 16 Oct 2002 09:35:17 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA18772; Wed, 16 Oct 2002 09:35:44 -0400 (EDT) Date: Wed, 16 Oct 2002 09:35:08 -0400 To: john.loughney@nokia.com Cc: pcalhoun@bstormnetworks.com, yohba@tari.toshiba.com, aboba@internaut.com, peterd@iea-software.com, marco.stura@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Message-ID: <20021016133508.GA1307@catfish> References: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A582C@esebe004.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 16, 2002 at 06:56:47AM +0300, john.loughney@nokia.com wrote: > Hi Pat, > > > A new AVP may be a better approach, but now requires that the > > application be involved in the message retransmission engine... not a > > great idea. > > As I understood, there had been discussion that an AVP could > be used, but the same concern that the application would > be involved in the retransmission was thought to be an ugly > hack. > Please see my reply to Pat: I think retransmission after rebooting based on stored unacknowlegded accounting records is a task of the application (the diameter engine should process them as new requests for which new End-to-End Identifiers are to be assigned), while retransmission after _normal_ failover/failback is a task of the retransmission engine. Better to make a distinction between those two cases. In the former case, the application would have to involve the retransmission and AVP could cover this case. The latter case is covered by using the combination of End-to-End Identifiers and Origin-Host AVP, which is the detection scheme that is mandatory used for all applications. If performance is the concern, the time-based window scheme that is also used in the D-bit scheme can also be used. Based on this analysis, I still wondor why D-bit is needed in the header. Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 16 10:49: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 KAA01758 for ; Wed, 16 Oct 2002 10:49:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2674C9127C; Wed, 16 Oct 2002 10:51:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E438E9127E; Wed, 16 Oct 2002 10:51:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C9D09127C for ; Wed, 16 Oct 2002 10:51:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE9FA5E004; Wed, 16 Oct 2002 10:51:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7F7215DFFD for ; Wed, 16 Oct 2002 10:51:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9GDngO30744 for ; Wed, 16 Oct 2002 06:49:42 -0700 Date: Wed, 16 Oct 2002 06:49:41 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 374: CMS cut and paste attack Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 374: CMS cut and paste attack Submitter name: Jari Arkko Submitter email address: jari.arkko@kolumbus.fi Date first submitted: 11/15/2002 Document: draft-ietf-aaa-diameter-cms-sec-04.txt Comment type: T Priority: S Section: several Rationale/Explanation of issue: I think that the CMS application, when ready, should include the command code and other stuff from the header (otherwise you'll see attacks where you have the same protected AVPs, but replace resource allocation request with accounting request etc). As this text in the CMS application is being developed, we could take care of not including the D bit there. From owner-aaa-wg@merit.edu Wed Oct 16 11:17: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 LAA02851 for ; Wed, 16 Oct 2002 11:17:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0A7CE9127F; Wed, 16 Oct 2002 11:19:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA40E91280; Wed, 16 Oct 2002 11:19:42 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9FC639127F for ; Wed, 16 Oct 2002 11:19:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 862885E000; Wed, 16 Oct 2002 11:19:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 752CA5DF7A for ; Wed, 16 Oct 2002 11:19:40 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9GFJMw21333 for ; Wed, 16 Oct 2002 18:19:22 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 18:19:38 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 18:19:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: issue 372 proposed text Date: Wed, 16 Oct 2002 18:19:37 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED39@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue 372 proposed text Thread-Index: AcJ1J3C3+9ypo8aRT9mB9pldBqt2kA== From: To: , Cc: , , X-OriginalArrivalTime: 16 Oct 2002 15:19:38.0887 (UTC) FILETIME=[718A7970:01C27527] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02851 Hi Bernard (and others), I would propose the following text for your consideration. Br Marco I guess we need more clear explanation when D flag should be set than the one currently proposed in issue 372, then the following text could be used instead: (possible) D(uplicate) - This flag is defined only for Accounting Requests sent by a Diameter client or agents. If set, the message is a possible duplicate and a recipient node MAY later check if it really is a duplicate. If sending a message for first time, this flag MUST be cleared. It can be used only in cases where no answer has been got from the Server for a message and the message is sent again (e.g. due to a failover to an alternate agent, due to a recovered primary peer node or due to a client re-sendind a stored record). This flag MUST NOT be set if an error 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 Server for a message and the message is sent again (e.g. due to a failover to an alternate agent, due to a recovered primary peer node or due to a client re-sendind a stored record). This flag MUST NOT be set in answer messages. And here is the proposal for AnnexC. A better example how the server may use the D-flag is given as well as worning proposed by Jari, the proposal is to change the last two paragraph with the following text. "The following is an example of how the D-flag may be used by the server to detect duplicate records. Implementers are advised, however, that configuration errors in the network or software errors cannot be detected solely by using the D-flag. Diameter server MAY check the D-flag of the received message to determine if the record is a possible duplicate. With the D-flag usage, the checking is based on tracking Session-ID and possibly Accounting-Record-Number AVPs. That tracking may be done for a configurable time window to future and to past for the corresponding AVP pairs, per a certain accounting record arriving to a recipient Diameter node. Only when a D-flag marked (i.e. D-flag set) accounting record is countered, its Session-ID and possibly Accounting-Record-Number AVP pair is buffered for a possible future check, but no check is needed immediately. The checking is done, Session-Id and possibly Accounting-Record-Number AVPs of the D-flag marked record against the other Session-ID and possibly Accounting-Record-Number AVP pairs of the time windows. If the duplicate record is not found in the backward and forward (e.g. 2 * TIME_WAIT) time windows, then the D-flag mark is not removed from the accounting record when sending it further towards the end system. The network's accounting end system can be understood and implemented as a central logical entity (no matter if it would physically consist of several servers). It could then be left to the end system to compare the possible still existing D-flag marked records against others in a configurable backward and forward (e.g. 2* TIME_WAIT) time windows. Since backward and forward time windows are used to check if the D-fag marked record is really a duplicate, out of order accounting records is not an issue." From owner-aaa-wg@merit.edu Wed Oct 16 11:31: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 LAA03510 for ; Wed, 16 Oct 2002 11:31:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9C90C91280; Wed, 16 Oct 2002 11:33:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65FEC91281; Wed, 16 Oct 2002 11:33:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4C28F91280 for ; Wed, 16 Oct 2002 11:33:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 37CC25DF67; Wed, 16 Oct 2002 11:33:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id BFC3F5DE90 for ; Wed, 16 Oct 2002 11:33:53 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9GFXOPk004782; Wed, 16 Oct 2002 11:33:24 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA19208; Wed, 16 Oct 2002 11:33:57 -0400 (EDT) Date: Wed, 16 Oct 2002 11:33:22 -0400 To: marco.stura@nokia.com Cc: aboba@internaut.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification Message-ID: <20021016153322.GI1307@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1D9E438C@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E438C@esebe016.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 117 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Marco, I come to think that the D-bit scheme would be useful for duplication detection not only for real-time accounting applications but also for other applications, and having D-bit in Diameter header would make sense (but with additional consideration, please see my comments inline). On Wed, Oct 16, 2002 at 02:50:08PM +0300, marco.stura@nokia.com wrote: > Hi again, > > here the mail that try better explanation of the D-bit. > > For real-time accounting applications, such as the Diameter Credit Control > draft, it is important to immediately process the original request (D=0) > since action by the client (action to the user) will be > taken if the answer doesn't come within a certain time. As the user > cannot wait for the service to be granted for 20 or 30 seconds, usually > a real-time accounting application defines a "waiting timer" after which > expiration the service is granted or not granted to the end user. A > value of the timer is about 10sec. > > The client behavior is usually controlled by some "failure handling" > parameter. For example the failure handling for "one time event" > direct debiting in case "waiting timer" expires could be "grant the > service and store the request" or "grant the service and forget the > request", this is configurable by the service provider. > > Storing the request is a sort of back-up to give a chance to the > service provider that the used service may be debited to the > user's account later and revenue is not lost. > > If a duplicate happens to reach the server, the "waiting timer" is normally > expired and proper action to the end user already been taken. > > This "one time event" direct debiting could be applicable to messaging > services, for example. For session based services e.g. VoIP or data services the one > time event approach is likely not applicable since online monitoring of the ongoing > session is needed. In this cases start/interim/stop approach where money > is reserved first and debited only when consumed by the service is the best solution. > A stateful server would be used and also in this case is important to immediately > process the original request (D=0). Sice stateful server would be used, moving the > accounting data stream to alternate server shouldn't be possible. > However duplicate may happen also in this case. > > In all cases when duplicate happen to reach the server, the client application > "waiting timer" is normally expired and proper action to the end user already been taken. > > Conclusion of the above is: > > 1- original request (D=0) must be processed immediately. > 2- no hurry to process the duplicate (D=1) > > When D=0, no checking is needed in the Server and the record is immediately > processed. I think checking is needed if the current time is within + time window started from the last reception of D=1. > > Only when a D=1 accounting record is encountered, then the checkings are done > (its AVP pair against the other Session-ID & Accounting-record-Number AVP pairs > of the +/- time window). For a class of retransmisstion that happened due to normal failover/failback, it is not necessary to look Session-ID & Accounting-record-Number AVP pairs. Instead, looking End-to-End Identifier and Origin-Host AVP in the Diameter server engine (without bringing up to the application) is enough for such a class of retransmission and if doing this way, the detection scheme can be generic to be applicable to other applications also. On the other hand, there is other class of retransmission that happened at a Diameter client due to rebooting. For this class, Session-ID & Accounting-record-Number AVP pairs should be used for detecting duplication in the application, since different E-E ID will be used for the same accounting record in this case. So, I would suggest treating the two classes of retransmission separatedly. > When D=1, its Session-ID & Accounting-Record-Number AVP pair > is buffered for a possible future check, but no check is needed in normal case. > A link failover procedure (causing the D-bit to be used for the last few yet > unacknowledged accounting records, the amount being in maximum the protocol > window size of records only) occurs e.g. during 2-3 days per year, so the rareness > of the D=1 case causes that > 1- most of the time there are no extra checkings at all > (when using the D-bit). > 2- when there are checkings the search is done just for the few D=1 > and only within the configurable time window to the future & past. > (Of course, the checks can be Session-ID based). > 3- only limited amount of resourses for duplicate detection are required > in the Server. > > Out of order records shouldn't be an issue because of the +/- time window. > > The key is that once a record arriving from Diameter client to > a Diameter server and is marked with D=1, then ***if the original is not found > in the +- time window (e.g. TIME_WAIT),then the D=1 mark is not removed*** > from the accounting record when sending it further towards the end system. > The network's accounting end system can be understood and implemented as > a _central logical entity_(no matter if it would physically consist of several servers). > It could then be left to the end system to compare the possible > still existing (very, very few!) D=1 marked records against others > in a configurable +- time window. > > I hope the above clarify some of the discussed topics. > > Br > Marco > > > Regards, Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 16 12:25: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 MAA04848 for ; Wed, 16 Oct 2002 12:25:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0C77291281; Wed, 16 Oct 2002 12:27:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C5F9E91282; Wed, 16 Oct 2002 12:27:14 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8595B91281 for ; Wed, 16 Oct 2002 12:27:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 64B8A5E00A; Wed, 16 Oct 2002 12:27:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 1D44F5E001 for ; Wed, 16 Oct 2002 12:27:12 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9GGQsw25721 for ; Wed, 16 Oct 2002 19:26:54 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 19:27:08 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 19:26:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 19:26:13 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E438F@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ1KYACph1dl7ksTz+ulwrhvXBA8gAAFV+g From: To: Cc: , , , , X-OriginalArrivalTime: 16 Oct 2002 16:26:13.0898 (UTC) FILETIME=[BEC0C6A0:01C27530] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ohba, > I come to think that the D-bit scheme would be useful for duplication > detection not only for real-time accounting applications but also for > other applications, and having D-bit in Diameter header would make > sense (but with additional consideration, please see my comments > inline). I agree with you that D-bit scheme is very usefull also for other applications. > I think checking is needed if the current time is within + time window > started from the last reception of D=1. Actually checking for D=0 is never needed, probably you are thinking to the case when D=1 is received before D=0, out of order. Am I right? D=1 is stored for later processing but doesn't need to be processed immediately, no harry. Checking of the last received D=1 can safely be postponed (e.g. according to the current available resources in the server etc.) and should, however, always start with sufficient delay to be sure that possibly out of order record have been received. For example, if checking is delayed >= 2 * TIME_WAIT (e.g. 5 min.) you are sure that TIME_WAIT is over and possibly out of order record should have been received. When checking, a forward (+) time window of e.g. 2 * TIME_WAIT can be used to be sure that you catch the possible out of order record. Usually backward and forward time windows are configurable in the server. > For a class of retransmisstion that happened due to normal > failover/failback, it is not necessary to look Session-ID & > Accounting-record-Number AVP pairs. Instead, looking End-to-End > Identifier and Origin-Host AVP in the Diameter server engine (without > bringing up to the application) is enough for such a class of > retransmission and if doing this way, the detection scheme > can be generic to be applicable to other applications also. > > On the other hand, there is other class of retransmission that > happened at a Diameter client due to rebooting. For this class, > Session-ID & Accounting-record-Number AVP pairs should be used for > detecting duplication in the application, since different E-E ID > will be used for the same accounting record in this case. > > So, I would suggest treating the two classes of retransmission > separatedly. I'm just wondering that the server doesn't know the reason of the re-transmission, failover/failback or application re-transmission. I guess a better approach would be a generic scheme applicable to all the cases. My feeling is that Session-Id and Accounting-Record-Number is a good generic scheme applicable in any case. Br Marco From owner-aaa-wg@merit.edu Wed Oct 16 12:33: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 MAA04987 for ; Wed, 16 Oct 2002 12:33:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E2A91282; Wed, 16 Oct 2002 12:35:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5C85E91283; Wed, 16 Oct 2002 12:35:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4A81E91282 for ; Wed, 16 Oct 2002 12:35:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 390935E004; Wed, 16 Oct 2002 12:35:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by segue.merit.edu (Postfix) with ESMTP id 8D8885DE82 for ; Wed, 16 Oct 2002 12:35:20 -0400 (EDT) Received: from SGOSWAMIPCL (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with ESMTP id MAA13125 for ; Wed, 16 Oct 2002 12:35:19 -0400 (EDT) From: "Subrata Goswami" To: Subject: RE: [AAA-WG]: MIP-Session-Key Date: Wed, 16 Oct 2002 09:33:18 -0700 Message-ID: <001501c27531$bd7f5080$c900a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Frederik, I am looking at the problem from a different angle. Setting up these TLS/IPSec associations do not scale to large number of nodes. If there are n AAA nodes, then it is n*n manual configuation. Whereas what I am suggestin would reduce that to n or linear. Subrata -----Original Message----- From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] Sent: Wednesday, October 16, 2002 12:07 AM To: Subrata Goswami; aaa-wg@merit.edu Subject: RE: [AAA-WG]: MIP-Session-Key Subrata, > > Frederik, no that is exactly what is used. IPSec and TLS are totally > different protocols and it is not necessary for Diameter MIP > Application to set up > > point-to-point encrypted links as they do. taken from the base draft. "2.2 Securing Diameter Messages Diameter clients, such as Network Access Servers (NASes) and Mobility Agents MUST support IP Security [SECARCH], and MAY support TLS [TLS]. Diameter servers MUST support TLS and IPsec. The Diameter protocol MUST NOT be used without any security mechanism (TLS or IPsec). 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. See sections 13.1 and 13.2 for more details on IPsec and TLS usage." So why should you encrypt the mip-session-keys again if the transport is secured? The only case where you need to encrypt the mip-session-keys would be if there are several hops between the sender and receiver, if so use CMS /fredrik Setting up these > point-to-point > links would be a nightmare and frankly no one is probably going to > use that approach in a large network with many subnets. Take a look at > the Diameter > Mobile IP application, see how many hops are there. > > A better approach is what I suggested, encrypt MIP-Session-Keys with > security associations between a AAA agent and the entity. I am not > sure CMS handles this > issue. It is not about end-to-end vs. point-to-point, it is more about > how many > shared secrets needs to be deployed per session - in case of Diameter > Mobile IP > application that number is 3 if you include FA-HA in addition to MN-FA, > MN-HA. The > number would double if a unidirectional key is used. Also, keep in mind > as Diameter Mobile IP Application is a key distribution mechanism, there > could be > other keys that it would have distribute in the very near future. > > Subrata > > > -----Original Message----- > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf > Of Fredrik Johansson > Sent: Tuesday, October 15, 2002 2:18 AM > To: Subrata Goswami; aaa-wg@merit.edu > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > > Behalf Of Subrata Goswami > > Sent: den 14 oktober 2002 17:28 > > To: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > Fredrik, so you are saying each of the different pair of entities > > would have to be provisioned with a distinct key or a private > > key/certificate. How is situation handled when there is no existing > > security association ? > > There MUST be a hop-by-hop security mechanism, either ipsec or tls > according to the protocol > > > Also, if you > > look into > > the following 3 AVP that I mentioned, there is no SPI specified for > > the MIP-HA-to-FA-Key and the MIP-HA-to-MN-Key. Would not it be > > better > > > to have a security association > > between FA-AAAF, HA-AAAH, and AAAF-AAAH use these keys to encrypt > > the MIP-Session-Keys ? > > that's exactly what's used, since the whole message between the > FA-AAAF and HA-AAAH is encrypted with the hop-by-hop security > mechanism the keys are encrypted, if there are several hops between > each node a end-to-end security mechanism should be used (e.g. cms) > > /fredrik > > > > > Subrata > > > > > > -----Original Message----- > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On > > Behalf > > > Of Fredrik Johansson > > Sent: Sunday, October 13, 2002 11:38 PM > > To: Subrata Goswami; aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: MIP-Session-Key > > > > > > Hi Subrata, > > > > The MIP-Session-Key is encrypted by the hop-by-hop security > > mechanism (i.e. ipsec or tls) or if there is more than one hop > > between any of the nodes end-to-end encryption may be used if deemed > > necessary (e.g. CMS when it becoms standarized). > > > > How you set up the hop-by-hop security like ipsec is out of the > > scope of the diameter protocol > > > > /fredrik > > > > > -----Original Message----- > > > From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On > > > Behalf Of Subrata Goswami > > > Sent: den 14 oktober 2002 05:20 > > > To: aaa-wg@merit.edu > > > Subject: [AAA-WG]: MIP-Session-Key > > > > > > > > > A simple question, the MIP-Session-Key AVP is used in the > > > following AVP's. > > > > > > 1. MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > > { MIP-FA-to-MN-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > 2. MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > 3. MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Session-Key } > > > * [ AVP ] > > > > > > It is not very clear how { MIP-Session-Key } are encrypted to > > > provide privacy in transit, what type of keys are used and how are > > > these key's > > > > > distributed to the > > > AAH, HA and FA. Sharing with MN is handled by the MN-AAA key. > > > > > > > > > Subrata > > > From owner-aaa-wg@merit.edu Wed Oct 16 12:44:47 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 MAA05293 for ; Wed, 16 Oct 2002 12:44:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B54A91283; Wed, 16 Oct 2002 12:46:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 08AB991285; Wed, 16 Oct 2002 12:46:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DAFC91283 for ; Wed, 16 Oct 2002 12:46:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8CD445E00A; Wed, 16 Oct 2002 12:45:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 38D175DE6B for ; Wed, 16 Oct 2002 12:45:49 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9GGjHPk010001; Wed, 16 Oct 2002 12:45:18 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id MAA19437; Wed, 16 Oct 2002 12:45:49 -0400 (EDT) Date: Wed, 16 Oct 2002 12:45:14 -0400 To: marco.stura@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification Message-ID: <20021016164514.GL1307@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1D9E438F@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E438F@esebe016.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 74 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 16, 2002 at 07:26:13PM +0300, marco.stura@nokia.com wrote: > Hi Ohba, > > > I come to think that the D-bit scheme would be useful for duplication > > detection not only for real-time accounting applications but also for > > other applications, and having D-bit in Diameter header would make > > sense (but with additional consideration, please see my comments > > inline). > > I agree with you that D-bit scheme is very usefull also for other applications. > > > I think checking is needed if the current time is within + time window > > started from the last reception of D=1. > > Actually checking for D=0 is never needed, probably you are thinking to the case > when D=1 is received before D=0, out of order. Am I right? Yes. > D=1 is stored for later processing but doesn't need to be processed immediately, no > harry. Checking of the last received D=1 can safely be postponed (e.g. according to the current > available resources in the server etc.) and should, however, always start with sufficient > delay to be sure that possibly out of order record have been received. > For example, if checking is delayed >= 2 * TIME_WAIT (e.g. 5 min.) you are sure that TIME_WAIT is > over and possibly out of order record should have been received. When checking, a forward (+) > time window of e.g. 2 * TIME_WAIT can be used to be sure that you catch the > possible out of order record. Usually backward and forward time windows are configurable > in the server. OK. I unstadant that there are several implementation design choices on the scheme. > > > For a class of retransmisstion that happened due to normal > > failover/failback, it is not necessary to look Session-ID & > > Accounting-record-Number AVP pairs. Instead, looking End-to-End > > Identifier and Origin-Host AVP in the Diameter server engine (without > > bringing up to the application) is enough for such a class of > > retransmission and if doing this way, the detection scheme > > can be generic to be applicable to other applications also. > > > > On the other hand, there is other class of retransmission that > > happened at a Diameter client due to rebooting. For this class, > > Session-ID & Accounting-record-Number AVP pairs should be used for > > detecting duplication in the application, since different E-E ID > > will be used for the same accounting record in this case. > > > > So, I would suggest treating the two classes of retransmission > > separatedly. > > I'm just wondering that the server doesn't know the reason of the re-transmission, failover/failback > or application re-transmission. It does not have to know actually. Duplicated messages that are not detected based on End-to-End ID and Origin Host will be automatically passed to the application, and the application can do another detection (application-specific duplication detection) based on Session-ID and Acct-Record-Number. > I guess a better approach would be a generic scheme applicable to > all the cases. > My feeling is that Session-Id and Accounting-Record-Number is a good generic scheme > applicable in any case. I meant to be generic to all authentication and accounting applications, not only to all accounting applications. Authentication applications do not have Accounting-Record-Number. > > Br > Marco > Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 16 13:05: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 NAA05829 for ; Wed, 16 Oct 2002 13:05:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 649A491285; Wed, 16 Oct 2002 13:07:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E08091286; Wed, 16 Oct 2002 13:07:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07CA591285 for ; Wed, 16 Oct 2002 13:07:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D5DF55E012; Wed, 16 Oct 2002 13:07:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id D138B5E001 for ; Wed, 16 Oct 2002 13:07:25 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9GH7OH21356 for ; Wed, 16 Oct 2002 20:07:24 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 16 Oct 2002 20:07:23 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 20:06:39 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 16 Oct 2002 20:06:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 20:06:39 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4391@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ1M5mZbjTbJxmmQUWkrQoobiytdQAAZtXw From: To: Cc: , , , , X-OriginalArrivalTime: 16 Oct 2002 17:06:39.0521 (UTC) FILETIME=[64897910:01C27536] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Ohba, > I meant to be generic to all authentication and accounting > applications, not only to all accounting applications. > Authentication applications do not have Accounting-Record-Number the focus was only to accounting applications. Do you think the D-flag would be useful for authentication application too? However, is It not better approach to leave the detailed solution specification to the application definition? Br Marco > -----Original Message----- > From: ext Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: 16. October 2002 19:45 > To: Stura Marco (NET/Helsinki) > Cc: yohba@tari.toshiba.com; aboba@internaut.com; > jari.arkko@kolumbus.fi; > Loughney John (NRC/Helsinki); pcalhoun@bstormnetworks.com; > aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Use of the D-Bit clarification > > > On Wed, Oct 16, 2002 at 07:26:13PM +0300, marco.stura@nokia.com wrote: > > Hi Ohba, > > > > > I come to think that the D-bit scheme would be useful for > duplication > > > detection not only for real-time accounting applications > but also for > > > other applications, and having D-bit in Diameter header would make > > > sense (but with additional consideration, please see my comments > > > inline). > > > > I agree with you that D-bit scheme is very usefull also for > other applications. > > > > > I think checking is needed if the current time is within > + time window > > > started from the last reception of D=1. > > > > Actually checking for D=0 is never needed, probably you are > thinking to the case > > when D=1 is received before D=0, out of order. Am I right? > > Yes. > > > D=1 is stored for later processing but doesn't need to be > processed immediately, no > > harry. Checking of the last received D=1 can safely be > postponed (e.g. according to the current > > available resources in the server etc.) and should, > however, always start with sufficient > > delay to be sure that possibly out of order record have > been received. > > For example, if checking is delayed >= 2 * TIME_WAIT (e.g. > 5 min.) you are sure that TIME_WAIT is > > over and possibly out of order record should have been > received. When checking, a forward (+) > > time window of e.g. 2 * TIME_WAIT can be used to be sure > that you catch the > > possible out of order record. Usually backward and forward > time windows are configurable > > in the server. > > OK. I unstadant that there are several implementation design choices > on the scheme. > > > > > > For a class of retransmisstion that happened due to normal > > > failover/failback, it is not necessary to look Session-ID & > > > Accounting-record-Number AVP pairs. Instead, looking End-to-End > > > Identifier and Origin-Host AVP in the Diameter server > engine (without > > > bringing up to the application) is enough for such a class of > > > retransmission and if doing this way, the detection scheme > > > can be generic to be applicable to other applications also. > > > > > > On the other hand, there is other class of retransmission that > > > happened at a Diameter client due to rebooting. For this class, > > > Session-ID & Accounting-record-Number AVP pairs should be used for > > > detecting duplication in the application, since different E-E ID > > > will be used for the same accounting record in this case. > > > > > > So, I would suggest treating the two classes of retransmission > > > separatedly. > > > > I'm just wondering that the server doesn't know the reason > of the re-transmission, failover/failback > > or application re-transmission. > > It does not have to know actually. Duplicated messages that are not > detected based on End-to-End ID and Origin Host will be automatically > passed to the application, and the application can do another > detection (application-specific duplication detection) based on > Session-ID and Acct-Record-Number. > > > I guess a better approach would be a generic scheme applicable to > > all the cases. > > My feeling is that Session-Id and Accounting-Record-Number > is a good generic scheme > > applicable in any case. > > I meant to be generic to all authentication and accounting > applications, not only to all accounting applications. > Authentication applications do not have Accounting-Record-Number. > > > > > Br > > Marco > > > > Yoshihiro Ohba > From owner-aaa-wg@merit.edu Wed Oct 16 14:25: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 OAA08251 for ; Wed, 16 Oct 2002 14:25:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEBC09128A; Wed, 16 Oct 2002 14:27:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9431C9128B; Wed, 16 Oct 2002 14:27:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 75F909128A for ; Wed, 16 Oct 2002 14:27:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C4AD5DEEB; Wed, 16 Oct 2002 14:27:14 -0400 (EDT) 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 BA4875DE32 for ; Wed, 16 Oct 2002 14:27:13 -0400 (EDT) Received: from gwzw2k (rtp-vpn1-912.cisco.com [10.82.227.144]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA15911; Wed, 16 Oct 2002 11:26:47 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , , , Cc: Subject: RE: [AAA-WG]: issue: real-time duplicate detection and proposed change. Date: Wed, 16 Oct 2002 11:26:41 -0700 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) Importance: Normal In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E437F@esebe016.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com writes: > Hi, > > sequence number is not the same as Session-Id and record number? > If we consider the case of "one time event" direct debiting, the > ACR[event, Session-Id, Record-number] is sent to > the server and the server loop back the same Session-Id and > Record-number in the ACA. > am I right? > > When the server receives the ACR money are deducted from the > user's account, If the server doesn't know if the ACR is > a possible duplicate, it needs to perform database search among > at least all the records received by this particular client > within a reasonable time window (e.g. a day) This part has me confused. We're talking about (near) real-time accounting here and others have suggested that a delay in response of even 120 seconds is too long. So why are you going to search a day's worth of records for a duplicate? For that matter, couldn't you simply flag the requests that have been replyed to in your database (you are keeping the requests, no?). > to avoid double > debiting, database searchthis is what we try to avoid. > > Hashing may do it with certain memory requirements, D flag may do > it with less memory requirements. > > Br > Marco > > -----Original Message----- > From: ext Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com] > Sent: 14. October 2002 22:44 > To: Stura Marco (NET/Helsinki); aboba@internaut.com; Loughney > John (NRC/Helsinki) > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: issue: real-time duplicate detection and > proposed change. > > > > Hello, > As I understand the issue: we are trying to make sure that the > (near)real-time accounting systems (e.g. pre-paid) do not > debit/credit users accounts multiple times when the same message > is re-transmitted. Can't this be solved by appending a message > sequence number (string) with every request? The client will send > the same sequence number as long as it does not receive a > response containing the same sequence number. The server should > loop back the same sequence number in the reply. If the same > message sequence was received at the server before (a reasonable > time window for real-time service) then the server replicates the > earlier message and send back a response w/o crediting/debiting > the user's account. upon receiving the response with a previously > generated and acknowledged sequence number the recipient ignores > the message. > > I am not against the D-bit idea, however I think the message > sequence numbers provide a good protection mechanism for avoiding > erroneous accounting due to duplicate requests. > > Regards, > Kuntal > > > > -----Original Message----- > > From: marco.stura@nokia.com [ mailto:marco.stura@nokia.com] > > Sent: Monday, October 14, 2002 11:07 AM > > To: aboba@internaut.com; john.loughney@nokia.com > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > and proposed change. > > > > > > Hi Bernard, > > > > thanks for considering the issue. > > > > Actually the real benefits of the D flag is that duplicate > > happen very seldom, so for all the D=0 records (say 90-95% of > > the records) the server can immediately process the request > > and answer to the client e.g. service granted or no money. > > > > D=1 records are statistically very few and duplicate search > > only for those records do not affect the overall performance > > of the system. > > > > Finally, your proposed text seems better than my original > > proposal. However, I'm not yet fully sure it is acceptable to > > delay the processing of all the D=1 records and don't have > > time to think now since I have to harry on and go back home, > > I'll come back tomorrow. I guess Time_Wait may be couple of > > seconds, am I right? > > > > However proposal#2 could be just to replace the text I > > proposed in Annex C that state that D falg may be used by > > server implementation and specified in diameter application etc..etc > > > > John could you make some proposal to replace my text? > > > > > > Br > > Marco > > > > > -----Original Message----- > > > From: ext Bernard Aboba [ mailto:aboba@internaut.com] > > > Sent: 14. October 2002 16:17 > > > To: Loughney John (NRC/Helsinki) > > > Cc: aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: issue: real-time duplicate detection > > > and proposed > > > change. > > > > > > > > > > The alternatives I see are: > > > > > > > > 1) Not supporting the d-bit. > > > > 2) Allow the setting of the d-bit, but either making > > > the response > > > > implementation specific or dependent on futher > > > specification. > > > > 3) Supporting the d-bit and the behavior of responding > > > to messages > > > > with the bit set. > > > > > > We have an issue filed (372). Approach #1 would be to reject > > > the issue. > > > Approach #3 appears to accept the changes requested in > > Issue 372. What > > > does approach #2 do? > > > > > > The text for Appendix C says: > > > > > > "Diameter server MAY check the D flag of the received message > > > to determine > > > if this record is a possible duplicate. If the D flag is set in the > > > request message, the server search for the duplicate within > > the above > > > mentioned time window. This way database search is only > > > required for those > > > received records whose the D flag is set. Since in today > > > networks link failures, server > > > breakdown or other similar events are very rare, this > > simple approach > > > efficiently optimize performances of the duplicate > > detection process. > > > It may happen that the original record is received after the > > > D flag marked > > > record because they did experience different delay in their > > way to the > > > server. For this reason it is necessary for the server to > > buffer the D > > > flag marked records for a short time period, as an example 10 or 15 > > > minutes, and check every record received within this time > > > period against > > > the buffered D flag marked records." > > > > > > The problem is that failover can cause the accounting record > > > to be sent to > > > *another* server. For example, if a proxy fails, the Diameter > > > client may > > > go to another proxy, and the new proxy may set up a connection to a > > > different accounting server. The approach described in the > > > last sentence > > > appears to assume that the duplicate arrives at the *same* > > > server as the > > > original record. > > > > > > I'd suggest that the last sentence say: > > > > > > "As a result, a simple approach is not foolproof, and may result in > > > occasional duplicates being accepted by the system. If occasional > > > duplicate records are not acceptable, then it may be difficult to > > > retain realtime performance. If the server cannot locate > > the original > > > record corresponding to the D flag marked record, it is still > > > possible for > > > the original to arrive later. To ensure that the duplicate is > > > detected, it > > > is necessary to delay processing of the D flag marked record until > > > the original record can be assured to have been received. > > > This corresponds > > > approximately to TIME_WAIT." > > > > > > My question is whether the above defeats the purpose of realtime > > > processing. > > > > > > > > > > > From owner-aaa-wg@merit.edu Wed Oct 16 14: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 OAA08596 for ; Wed, 16 Oct 2002 14:39:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C68099128D; Wed, 16 Oct 2002 14:41:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 940619128E; Wed, 16 Oct 2002 14:41:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79E9A9128D for ; Wed, 16 Oct 2002 14:41:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5C8725DEF1; Wed, 16 Oct 2002 14:41:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id DAD535DEEB for ; Wed, 16 Oct 2002 14:41:28 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9GIfEPk019069; Wed, 16 Oct 2002 14:41:14 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA19750; Wed, 16 Oct 2002 14:41:47 -0400 (EDT) Date: Wed, 16 Oct 2002 14:41:12 -0400 To: marco.stura@nokia.com Cc: yohba@tari.toshiba.com, aboba@internaut.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification Message-ID: <20021016184112.GN1307@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1D9E4391@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E4391@esebe016.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Marco, On Wed, Oct 16, 2002 at 08:06:39PM +0300, marco.stura@nokia.com wrote: > Hi Ohba, > > > I meant to be generic to all authentication and accounting > > applications, not only to all accounting applications. > > Authentication applications do not have Accounting-Record-Number > > the focus was only to accounting applications. > Do you think the D-flag would be useful for authentication application too? Based on my analysis, yes. I just thought that it can also enhance the performance of duplication detection performed in the Diameter base engine by using the E-E ID and Origin-Host AVP regardless of application types, in that servers do not have to check for every received request message, right? (But the D-bit indication might be informative, as Jari mentioned.) > > However, is It not better approach to leave the detailed solution specification > to the application definition? That's why I'm suggesting the separation of the duplication detection schemes into two. D-bit scheme based on E-E ID+Origin-Host AVP, which would be common to all applications, could be described in the base spec. D-bit scheme specific to realtime accounting application based on Session-ID+Acct-Record-Number can be described in either the base spec (if the realtime accounting application is supported as base accounting application) or separated document (if the realtime accounting application is supported as a new accounting application). Those two schemes are essentially identical except for which header field and/or AVP are used as the search key for duplication detection. Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 16 14:59: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 OAA09313 for ; Wed, 16 Oct 2002 14:59:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C98A9128E; Wed, 16 Oct 2002 15:01:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 262419128F; Wed, 16 Oct 2002 15:01:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4556B9128E for ; Wed, 16 Oct 2002 15:01:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 667305E004; Wed, 16 Oct 2002 15:01:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from donkeykong.gpcc.itd.umich.edu (donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by segue.merit.edu (Postfix) with ESMTP id 520FA5E001 for ; Wed, 16 Oct 2002 15:01:08 -0400 (EDT) Received: from zektor.gpcc.itd.umich.edu (zektor.gpcc.itd.umich.edu [141.211.2.203]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id PAA08054 for ; Wed, 16 Oct 2002 15:01:07 -0400 (EDT) Received: from localhost (sgoswami@localhost) by zektor.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id PAA07002 for ; Wed, 16 Oct 2002 15:01:06 -0400 (EDT) Date: Wed, 16 Oct 2002 15:01:06 -0400 (EDT) From: "s. goswami" X-X-Sender: sgoswami@zektor.gpcc.itd.umich.edu To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: MIP-Session-Key In-Reply-To: <1877830.1034764174@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, 16 Oct 2002, Paul Krumviede wrote: > --On Wednesday, 16 October, 2002 09:33 -0700 Subrata Goswami > wrote: > > > Frederik, I am looking at the problem from a different angle. Setting > > up these TLS/IPSec associations do not scale to large number of nodes. > > If there are n AAA nodes, then it is n*n manual configuation. Whereas > > what I am suggestin would reduce that to n or linear. > > huh? why can't you use IPsec with certificates? then one might need > to configure servers within an administrative domain to establish IPsec > security associations based on a common CA (sub-linear), and to > configure security associations with other administrative domains > by doing something like configuring a CA cert for each such domain > (at worst, linear in the number of domains). > Lt us see if I understand what you are saying. You use certificates for each node from a common CA. Then you establish an IPSec SA ( say with IKE). This happens with AMA and HAA. So there is an IPSec SA from FA to AAAF, from AAAF to AAAH, from AAAH to HA. Thus there is an additional requirement on the FA and HA to be IPSec terminations. Moreover the CA chain for PKI need to be setup. Further more these messages are essentially one time signalling messages, do we need to keep IPSec sessions open for such sporadic messages ? We are already using a shared secret between MN-AAAH, so why not use the same approach for FA-AAAF, HA-AAAH. The AAAF-AAAH might be better serverd by a certificate approach, as it is not possible to say a priori when they need to have an association. > there has been a fair amount of work to allow IPsec, at least, to > scale to large numbers of nodes. Can you please cite one refernce ? I would certainly love to find out about the biggest IPSec network. > > -paul > From owner-aaa-wg@merit.edu Wed Oct 16 16:53: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 QAA11932 for ; Wed, 16 Oct 2002 16:53:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7044991290; Wed, 16 Oct 2002 16:55:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37C0C91292; Wed, 16 Oct 2002 16:55:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C10491290 for ; Wed, 16 Oct 2002 16:55:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 249775DFD5; Wed, 16 Oct 2002 16:55:46 -0400 (EDT) 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 885985DFBF for ; Wed, 16 Oct 2002 16:55:45 -0400 (EDT) Received: from gwzw2k (rtp-vpn2-5.cisco.com [10.82.240.5]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA02079; Wed, 16 Oct 2002 13:54:57 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Yoshihiro Ohba" , Cc: , , , , Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 13:54:55 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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: <20021016184112.GN1307@catfish> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > Marco, > > On Wed, Oct 16, 2002 at 08:06:39PM +0300, marco.stura@nokia.com wrote: > > Hi Ohba, > > > > > I meant to be generic to all authentication and accounting > > > applications, not only to all accounting applications. > > > Authentication applications do not have Accounting-Record-Number > > > > the focus was only to accounting applications. > > Do you think the D-flag would be useful for authentication > application too? > > Based on my analysis, yes. I just thought that it can also enhance > the performance of duplication detection performed in the Diameter > base engine by using the E-E ID and Origin-Host AVP regardless of > application types, in that servers do not have to check > for every received request message, right? (But the D-bit indication > might be informative, as Jari mentioned.) But duplicate detection is not required (in general) in Diameter, right? Even for accounting, duplicate detection/removal can very often be left to a back-end processor. > > > > > However, is It not better approach to leave the detailed > solution specification > > to the application definition? > > That's why I'm suggesting the separation of the duplication detection > schemes into two. D-bit scheme based on E-E ID+Origin-Host AVP, which > would be common to all applications, could be described in the base > spec. D-bit scheme specific to realtime accounting application based > on Session-ID+Acct-Record-Number can be described in either the base > spec (if the realtime accounting application is supported as base > accounting application) or separated document (if the realtime > accounting application is supported as a new accounting application). > > Those two schemes are essentially identical except for which header > field and/or AVP are used as the search key for duplication detection. Right, and since neither of these schemes are actually necessary for the correct operation of the protocol (as opposed to the correct processing of the _data_ carried _by_ the protocol, and that only in certain special situatons), I would prefer to leave any description of any processing out of the base protocol document. I suggest that the 'D' bit be renamed the 'T' for reTransmission bit, to be set on any retransmission of a Diameter message. > > Yoshihiro Ohba > > From owner-aaa-wg@merit.edu Wed Oct 16 21:08: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 VAA17261 for ; Wed, 16 Oct 2002 21:08:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D2A191295; Wed, 16 Oct 2002 21:10:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA8BE91297; Wed, 16 Oct 2002 21:10:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CEA2391295 for ; Wed, 16 Oct 2002 21:10:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD1DC5E022; Wed, 16 Oct 2002 21:10:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from nycsmtp2out.rdc-nyc.rr.com (nycsmtp2out.rdc-nyc.rr.com [24.29.99.227]) by segue.merit.edu (Postfix) with ESMTP id 29A815E020 for ; Wed, 16 Oct 2002 21:10:52 -0400 (EDT) Received: from localhost (24-90-172-230.nj.rr.com [24.90.172.230]) by nycsmtp2out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g9H17VlY019710; Wed, 16 Oct 2002 21:07:32 -0400 (EDT) Date: Wed, 16 Oct 2002 21:10:44 -0400 To: Glen Zorn Cc: Yoshihiro Ohba , marco.stura@nokia.com, aboba@internaut.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification Message-ID: <20021017011044.GB962@catfish> References: <20021016184112.GN1307@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 24 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Oct 16, 2002 at 01:54:55PM -0700, Glen Zorn wrote: > Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > > But duplicate detection is not required (in general) in Diameter, right? > Even for accounting, duplicate detection/removal can very often be left to a > back-end processor. Yes. > > Those two schemes are essentially identical except for which header > > field and/or AVP are used as the search key for duplication detection. > > Right, and since neither of these schemes are actually necessary for the > correct operation of the protocol (as opposed to the correct processing of > the _data_ carried _by_ the protocol, and that only in certain special > situatons), I would prefer to leave any description of any processing out of > the base protocol document. I suggest that the 'D' bit be renamed the 'T' > for reTransmission bit, to be set on any retransmission of a Diameter > message. Agreed, as long as it does not preclude the generic usage I suggested as well as the original usage for realtime accounting application. Yoshihiro Ohba From owner-aaa-wg@merit.edu Wed Oct 16 22: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 WAA18381 for ; Wed, 16 Oct 2002 22:01:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE41D91298; Wed, 16 Oct 2002 22:03:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 65D7891296; Wed, 16 Oct 2002 22:03:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61A7A9122B for ; Wed, 16 Oct 2002 22:03:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 457395E030; Wed, 16 Oct 2002 22:03:31 -0400 (EDT) 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 B52475DDB2 for ; Wed, 16 Oct 2002 22:03:30 -0400 (EDT) Received: from gwzw2k (rtp-vpn2-352.cisco.com [10.82.241.96]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA09042; Wed, 16 Oct 2002 19:02:44 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Yoshihiro Ohba" Cc: , , , , , Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 19:02:35 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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.4910.0300 In-reply-to: <20021017011044.GB962@catfish> Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > On Wed, Oct 16, 2002 at 01:54:55PM -0700, Glen Zorn wrote: > > Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: > > > > But duplicate detection is not required (in general) in Diameter, right? > > Even for accounting, duplicate detection/removal can very often > be left to a > > back-end processor. > > Yes. > > > > Those two schemes are essentially identical except for which header > > > field and/or AVP are used as the search key for duplication detection. > > > > Right, and since neither of these schemes are actually necessary for the > > correct operation of the protocol (as opposed to the correct > processing of > > the _data_ carried _by_ the protocol, and that only in certain special > > situatons), I would prefer to leave any description of any > processing out of > > the base protocol document. I suggest that the 'D' bit be > renamed the 'T' > > for reTransmission bit, to be set on any retransmission of a Diameter > > message. > > Agreed, as long as it does not preclude the generic usage I suggested > as well as the original usage for realtime accounting application. I think that the bit could be used in (non protocol-related) processing in whatever way one might wish. > > Yoshihiro Ohba > > From owner-aaa-wg@merit.edu Thu Oct 17 00:40: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 AAA21139 for ; Thu, 17 Oct 2002 00:40:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 737FC9122B; Thu, 17 Oct 2002 00:42:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 456BE91299; Thu, 17 Oct 2002 00:42:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 372809122B for ; Thu, 17 Oct 2002 00:42:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1863F5E040; Thu, 17 Oct 2002 00:42:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from roam.psg.com (unknown [147.28.4.2]) by segue.merit.edu (Postfix) with ESMTP id 788BB5DDEB for ; Thu, 17 Oct 2002 00:42:41 -0400 (EDT) Received: from localhost ([127.0.0.1] helo=roam.psg.com.psg.com ident=randy) by roam.psg.com with esmtp (Exim 4.05) id 1822Ua-00014I-00; Wed, 16 Oct 2002 21:42:40 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yoshihiro Ohba Cc: Glen Zorn , marco.stura@nokia.com, aboba@internaut.com, jari.arkko@kolumbus.fi, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification References: <20021016184112.GN1307@catfish> <20021017011044.GB962@catfish> Message-Id: Date: Wed, 16 Oct 2002 21:42:40 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> But duplicate detection is not required (in general) in Diameter, right? >> Even for accounting, duplicate detection/removal can very often be left >> to a back-end processor. > Yes. so, please remind me why we need to make things more complicated? randy From owner-aaa-wg@merit.edu Thu Oct 17 01:56: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 BAA22076 for ; Thu, 17 Oct 2002 01:56:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A3C6E91299; Thu, 17 Oct 2002 01:58:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CFB59129A; Thu, 17 Oct 2002 01:58:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4ED2591299 for ; Thu, 17 Oct 2002 01:58:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F91C5E040; Thu, 17 Oct 2002 01:58:37 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 58BF05DF40 for ; Thu, 17 Oct 2002 01:58:36 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H5wIw18057 for ; Thu, 17 Oct 2002 08:58:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 08:58:35 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 08:58:35 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 08:58:34 +0300 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Use of the D-Bit clarification MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 17 Oct 2002 08:58:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38F9C@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ1l6TFjh5wZ3YdQDmDQJ6dYXmy3AACFJFA From: To: Cc: X-OriginalArrivalTime: 17 Oct 2002 05:58:34.0678 (UTC) FILETIME=[3A859560:01C275A2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA22076 Hi Randy, > so, please remind me why we need to make things more complicated? As I understand, the proposal is to set a bit for retransmitted message requests: D(uplicate) - If set, the message is a possible duplicate request due to failover/failback or re-sending of a record in storage. This flag MUST NOT be set in answer messages. That is all. This, in my mind, is not so very complicated. Some text is added to an appendix, suggesting what the receiver should do with the d-bit, but let me outline a possible use of this. I am an end user with a certain amount of tokens on my account, for using with services. Whenever I make a service request, my account is debitted a token, in real time. If, because of some network problems, an accounting request is retransmitted, there stands the chance that my account will be doubly debitted, and if I am low on tokens, then I may be wrongly denied the service. In the real world, this is a good way to piss off customers. The proposal is to use the d-bit with real-time accounting to assign a priority to all accounting requests where the D-bit = 0, as we can safely assume this message is not a duplicate request. With out it, we can never assume that an accounting request is not a duplicate. For an accounting request where the d-bit = 1, then the proposal is not to process the messsage in real-time, but to have an optimized duplicate detection algorithm and/or configurable based on service provider's needs. With any luck, messages with the d-bit = 1 should an extremely small number. This type of mechanism is already in use in some GPRS networks and shown that the mechanism is effective. Of course, one could suggest having a hashed-based look-up to perform the duplicate check, but that may increase the delay to the user; as well as cause additionally hardware needs (memory & processor) to the service provider to ensure that they are able to perform the duplicate check in real-time. I understand that this type of functionality may not be needed in traditional IP-style accounting practices; but for cellular packet services, where heavy use of pre-paid services is common, this is needed. So, my proposal is that we accept setting of the D-bit, as proposed in issue 372. Setting of this bit does not seem to break anything. Further more, the Credit Based Charging Diameter Application has been brought to the IETF, for standardization consideration. My recommendation is that this draft is the place where to handle the duplicate-detection mechanism. Does this sound reasonable? John From owner-aaa-wg@merit.edu Thu Oct 17 02:03: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 CAA26268 for ; Thu, 17 Oct 2002 02:03:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABBC59129A; Thu, 17 Oct 2002 02:05:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 794329129B; Thu, 17 Oct 2002 02:05:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7B8E29129A for ; Thu, 17 Oct 2002 02:05:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 656675E041; Thu, 17 Oct 2002 02:05:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id ABB105E043 for ; Thu, 17 Oct 2002 02:04:59 -0400 (EDT) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H64fw23842 for ; Thu, 17 Oct 2002 09:04:41 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 17 Oct 2002 09:04:58 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 09:04:58 +0300 content-class: urn:content-classes:message Subject: [AAA-WG]: Issue 373 - closed MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Date: Thu, 17 Oct 2002 09:04:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5866@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ1M5op8/5KpHEPQ+WKwp5MncuLtgAb0rFA From: To: X-OriginalArrivalTime: 17 Oct 2002 06:04:58.0456 (UTC) FILETIME=[1F457580:01C275A3] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, I have made the changes as outlined below. John Issue 373: Some NITs in -14 Submitter name: Allison Mankin Submitter email address: mankin@isi.edu Date first submitted: 11/15/2002 Document: draft-ietf-aaa-diameter-14.txt Comment type: T Priority: S Section: 1.2, 2.1 Rationale/Explanation of issue: I found these bits, little fixes, that could get tucked into -15. 1.2 The Diameter protocol is designed to be extensible, using several mechanisms, including: - Defining new AVP values. - Creating new AVPs - Creating new authentication/authorization applications - Creating new accounting applications - Application authentication procedures Reuse of existing AVP values, AVPs, applications and command codes are strongly recommended. Reuse simplifies standardization and implementation and avoids potential interoperability issues. ### It should no longer say "and command codes" in this context ### because command codes aren't part of the extensibility framework... ### I think the words are hangovers from the past. [John Loughney] I'd propose stating something like this: "Reuse of existing AVP values, AVPs, applications are strongly recommended. Reuse simplifies standardization and implementation and avoids potential interoperability issues. It is expected that command codes are reused; new command codes can only be created by IETF Consensus (see section 11.2.1)." ------- Section 2.1 should normatively ref AAATRANS, as 5.1 does. ------- To save you some round trips: 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. The SEC ADs now require AES in place of 3DES. TLS actually has a finished RFC for AES, rfc3268.txt, so substitute; TLS_RSA_WITH_AES_128_CBC_SHA or 256? All 3DES refs have been pretty much been swapped out of TSV specs, even though none of the specs but TLS are done ;} [John Loughney] So I will add: "Diameter nodes SHOULD be able to negotiate the following TLS cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA " From owner-aaa-wg@merit.edu Thu Oct 17 02:39: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 CAA02303 for ; Thu, 17 Oct 2002 02:39:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FD159129C; Thu, 17 Oct 2002 02:41:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF2919129D; Thu, 17 Oct 2002 02:41:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A0CA09129C for ; Thu, 17 Oct 2002 02:41:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 862DF5DF89; Thu, 17 Oct 2002 02:41:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id CE17A5DDEB for ; Thu, 17 Oct 2002 02:41:47 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H6fTw22646 for ; Thu, 17 Oct 2002 09:41:29 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 09:41:43 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 09:41:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C275A8.41341184" Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Thu, 17 Oct 2002 09:41:42 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED3F@esebe016.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ1l6TFjh5wZ3YdQDmDQJ6dYXmy3AACFJFAAAFV5rA= From: To: , Cc: X-OriginalArrivalTime: 17 Oct 2002 06:41:43.0585 (UTC) FILETIME=[41A17110:01C275A8] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C275A8.41341184 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, John made exactly the point. > So, my proposal is that we accept setting of the D-bit, as proposed > in issue 372. Setting of this bit does not seem to break anything. > Further more, the Credit Based Charging Diameter Application has > been brought to the IETF, for standardization consideration. My > recommendation is that this draft is the place where to handle the > duplicate-detection mechanism. I agree with John that the Diameter application specification is the = place where to provide eventually detailed description of how the Server uses the D-flag, the base probably need to provide just an indicative example. Here follow additional considerations with regards to the end system = discussion. Best Regards Marco I guess that actually the D-flag make things much simpler, that's why=20 the same mechanism is already in use for example in 3GPP GPRS network around the globe (both 2.5G and 3G). If you think of an end system (also the end system may be a Diameter server, or e.g. the account holder in case of prepaid) receiving millions of request, if D=3D0 (say 99% of the requests)the request is immediately processed and answer is sent, if D=3D1 no harry to=20 process the request. (here attached my previous mail with D-bit usage clarification for your information). If D-flag is not in use, the end system doesn't know if the incoming request may be a duplicate thus need to check for every single received request if this is a duplicate or not. For the end system, which is the collector of all the requests generated in the network, is even more critical if D-flag is not in use. Setting the D-flag for the client and agents, is extremely simple as compared to the extra work that the Diameter Sever and end system would need to do if D-flag is not in use. "The key is that once a record arriving from Diameter client to a Diameter server and is marked with D=3D1, then ***if the original is = not found=20 in the +- time window (e.g. TIME_WAIT),then the D=3D1 mark is not = removed***=20 from the accounting record when sending it further towards the end = system.=20 The network's accounting end system can be understood and implemented as = a _central logical entity_(no matter if it would physically consist of = several servers). It could then be left to the end system to compare the possible still existing (very, very few!) D=3D1 marked records against others in a configurable +- time window." > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 17. October 2002 8:59 > To: randy@psg.com > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Use of the D-Bit clarification >=20 >=20 > Hi Randy, >=20 > > so, please remind me why we need to make things more complicated? >=20 > As I understand, the proposal is to set a bit for retransmitted=20 > message requests: >=20 > D(uplicate) - If set, the message is a possible=20 > duplicate request=20 > due to failover/failback or re-sending of a > record in storage. This flag MUST NOT be set in=20 > answer messages. >=20 > That is all. This, in my mind, is not so very complicated. >=20 > Some text is added to an appendix, suggesting what the receiver > should do with the d-bit, but let me outline a possible use of > this. >=20 > I am an end user with a certain amount of tokens on my account, > for using with services. Whenever I make a service request, > my account is debitted a token, in real time. If, because of > some network problems, an accounting request is retransmitted, > there stands the chance that my account will be doubly debitted, > and if I am low on tokens, then I may be wrongly denied the service. > In the real world, this is a good way to piss off customers. >=20 > The proposal is to use the d-bit with real-time accounting to > assign a priority to all accounting requests where the D-bit =3D 0, > as we can safely assume this message is not a duplicate request. > With out it, we can never assume that an accounting request=20 > is not a duplicate. >=20 > For an accounting request where the d-bit =3D 1, then the proposal is > not to process the messsage in real-time, but to have an optimized > duplicate detection algorithm and/or configurable based on service > provider's needs. With any luck, messages with the d-bit =3D 1 should > an extremely small number. This type of mechanism is already > in use in some GPRS networks and shown that the mechanism is > effective. >=20 > Of course, one could suggest having a hashed-based look-up to perform > the duplicate check, but that may increase the delay to the user; as > well as cause additionally hardware needs (memory & processor) to the > service provider to ensure that they are able to perform the duplicate > check in real-time. >=20 > I understand that this type of functionality may not be needed > in traditional IP-style accounting practices; but for cellular > packet services, where heavy use of pre-paid services is common, > this is needed. >=20 > So, my proposal is that we accept setting of the D-bit, as proposed > in issue 372. Setting of this bit does not seem to break anything. > Further more, the Credit Based Charging Diameter Application has > been brought to the IETF, for standardization consideration. My > recommendation is that this draft is the place where to handle the > duplicate-detection mechanism. >=20 > Does this sound reasonable? > John >=20 ------_=_NextPart_001_01C275A8.41341184 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Use of the D-Bit clarification Date: Wed, 16 Oct 2002 14:50:08 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E438C@esebe016.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: issue: real-time duplicate detection andproposedchange. Thread-Index: AcJ004su6qmIHhXzQy28Zs2Swc7VZQAL4a6gAAFt1mA= From: To: , Cc: , , Content-Transfer-Encoding: quoted-printable Hi again, here the mail that try better explanation of the D-bit. For real-time accounting applications, such as the Diameter Credit = Control draft, it is important to immediately process the original request = (D=3D0) since action by the client (action to the user) will be=20 taken if the answer doesn't come within a certain time. As the user cannot wait for the service to be granted for 20 or 30 seconds, usually a real-time accounting application defines a "waiting timer" after which expiration the service is granted or not granted to the end user. A=20 value of the timer is about 10sec.=20 The client behavior is usually controlled by some "failure handling" parameter. For example the failure handling for "one time event" direct debiting in case "waiting timer" expires could be "grant the service and store the request" or "grant the service and forget the request", this is configurable by the service provider. Storing the request is a sort of back-up to give a chance to the=20 service provider that the used service may be debited to the user's account later and revenue is not lost. If a duplicate happens to reach the server, the "waiting timer" is = normally=20 expired and proper action to the end user already been taken. This "one time event" direct debiting could be applicable to messaging services, for example. For session based services e.g. VoIP or data = services the one time event approach is likely not applicable since online monitoring of = the ongoing session is needed. In this cases start/interim/stop approach where money = is reserved first and debited only when consumed by the service is the = best solution.=20 A stateful server would be used and also in this case is important to = immediately=20 process the original request (D=3D0). Sice stateful server would be = used, moving the accounting data stream to alternate server shouldn't be possible.=20 However duplicate may happen also in this case. In all cases when duplicate happen to reach the server, the client = application "waiting timer" is normally expired and proper action to the end user = already been taken. Conclusion of the above is: 1- original request (D=3D0) must be processed immediately. 2- no hurry to process the duplicate (D=3D1) When D=3D0, no checking is needed in the Server and the record is = immediately processed. Only when a D=3D1 accounting record is encountered, then the checkings = are done=20 (its AVP pair against the other Session-ID & Accounting-record-Number = AVP pairs of the +/- time window). When D=3D1, its Session-ID & = Accounting-Record-Number AVP pair is buffered for a possible future check, but no check is needed in = normal case.=20 A link failover procedure (causing the D-bit to be used for the last few = yet=20 unacknowledged accounting records, the amount being in maximum the = protocol=20 window size of records only) occurs e.g. during 2-3 days per year, so = the rareness=20 of the D=3D1 case causes that 1- most of the time there are no extra checkings at all (when using the D-bit). 2- when there are checkings the search is done just for the few = D=3D1 and only within the configurable time window to the future & = past.=20 (Of course, the checks can be Session-ID based). =20 3- only limited amount of resourses for duplicate detection are = required in the Server. Out of order records shouldn't be an issue because of the +/- time = window.=20 The key is that once a record arriving from Diameter client to a Diameter server and is marked with D=3D1, then ***if the original is = not found=20 in the +- time window (e.g. TIME_WAIT),then the D=3D1 mark is not = removed***=20 from the accounting record when sending it further towards the end = system.=20 The network's accounting end system can be understood and implemented as = a _central logical entity_(no matter if it would physically consist of = several servers). It could then be left to the end system to compare the possible still existing (very, very few!) D=3D1 marked records against others in a configurable +- time window. I hope the above clarify some of the discussed topics. Br Marco =20 ------_=_NextPart_001_01C275A8.41341184-- From owner-aaa-wg@merit.edu Thu Oct 17 03:16: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 DAA02804 for ; Thu, 17 Oct 2002 03:16:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D246491208; Thu, 17 Oct 2002 03:17:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99F5D912A1; Thu, 17 Oct 2002 03:17:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5FEB391208 for ; Thu, 17 Oct 2002 03:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1CD6E5DFF5; Thu, 17 Oct 2002 03:17:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id 982BE5DE38 for ; Thu, 17 Oct 2002 03:17:54 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1418B6A904; Thu, 17 Oct 2002 10:17:50 +0300 (EEST) Message-ID: <3DAE6597.2090304@kolumbus.fi> Date: Thu, 17 Oct 2002 10:24:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gwz@cisco.com Cc: Yoshihiro Ohba , marco.stura@nokia.com, aboba@internaut.com, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification References: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn wrote: > the base protocol document. I suggest that the 'D' bit be renamed the 'T' > for reTransmission bit, to be set on any retransmission of a Diameter > message. Agree. I also don't want to see a mandated treatment at the server side, except maybe in a specific accounting extension spec. Jari From owner-aaa-wg@merit.edu Thu Oct 17 03: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 DAA02917 for ; Thu, 17 Oct 2002 03:32:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF3389129E; Thu, 17 Oct 2002 03:34:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC7399129F; Thu, 17 Oct 2002 03:33:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6AD99129E for ; Thu, 17 Oct 2002 03:33:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87CA55DE38; Thu, 17 Oct 2002 03:33:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (unknown [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id B56BD5DDCB for ; Thu, 17 Oct 2002 03:33:57 -0400 (EDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 980196A909; Thu, 17 Oct 2002 10:33:56 +0300 (EEST) Message-ID: <3DAE695E.3060508@kolumbus.fi> Date: Thu, 17 Oct 2002 10:40:14 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: marco.stura@nokia.com Cc: aboba@internaut.com, john.loughney@nokia.com, pcalhoun@bstormnetworks.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: issue 372 proposed text References: <142DC466081D9B409AAD1DDCA4B21E1DA3ED39@esebe016.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com wrote: > (possible) D(uplicate) T, potentially retransmitted message > - This flag is defined only for Accounting Requests all requests > sent by a Diameter client or agents. > If set, the message is a possible duplicate and s/message/request/g and This flag is used as an informative indication of an application layer retransmission event, e.g. due to failover to an alternate server, or due to resending accounting records from non-volatile memory after a reboot of the client. If a Diameter client or agent knows that it is sending this request or accounting record contained in the request for the first time, it MAY reset this flag. If request is either known to be a retransmission or the Diameter client or agent is unable to assure that it is the first such request, it MUST set this flag. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the the first transmitted request arrives at the server after the retransmitted request. > a recipient node MAY later check if it really is a > duplicate. > If sending a message for first time, this flag MUST be > cleared. > It can be used only in cases where no answer has been > got from the Server for a message and the message is > sent again (e.g. due to a failover to an > alternate agent, due to a recovered primary peer > node or due to a client re-sendind a stored record). Delete all of the above. > This flag MUST NOT be set if an error 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 Server for a message > and the message is sent again (e.g. due to a failover to an > alternate agent, due to a recovered primary peer > node or due to a client re-sendind a stored record). > This flag MUST NOT be set in answer messages. Ok. > And here is the proposal for AnnexC. A better example how the server may use > the D-flag is given as well as worning proposed by Jari, the proposal is to > change the last two paragraph with the following text. > > > "The following is an example of how the D-flag may be used by the server to > detect duplicate records. Implementers are advised, however, that configuration > errors in the network or software errors cannot be detected solely by using > the D-flag. Ok. > Diameter server MAY check the D-flag of the received message to determine Let's not use keywrods in the appendix. These are non-normative anyway. > if the record is a possible duplicate. With the D-flag usage, the checking > is based on tracking Session-ID and possibly Accounting-Record-Number AVPs. > That tracking may be done for a configurable time window to future and to > past for the corresponding AVP pairs, per a certain accounting record arriving > to a recipient Diameter node. Only when a D-flag marked (i.e. D-flag set) > accounting record is countered, its Session-ID and possibly > Accounting-Record-Number AVP pair is buffered for a possible future check, > but no check is needed immediately. The checking is done, Session-Id and > possibly Accounting-Record-Number AVPs of the D-flag marked record against > the other Session-ID and possibly Accounting-Record-Number AVP pairs > of the time windows. If the duplicate record is not found in the backward and > forward (e.g. 2 * TIME_WAIT) time windows, then the D-flag mark is not removed > from the accounting record when sending it further towards the end system. > The network's accounting end system can be understood and implemented as > a central logical entity (no matter if it would physically consist of several > servers). It could then be left to the end system to compare the possible > still existing D-flag marked records against others in a configurable > backward and forward (e.g. 2* TIME_WAIT) time windows. > Since backward and forward time windows are used to check if the D-fag marked > record is really a duplicate, out of order accounting records is not an issue." I haven't checked this. Jari From owner-aaa-wg@merit.edu Thu Oct 17 03:37: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 DAA02990 for ; Thu, 17 Oct 2002 03:37:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07F119129F; Thu, 17 Oct 2002 03:39:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C99C1912A0; Thu, 17 Oct 2002 03:39:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CF9A9129F for ; Thu, 17 Oct 2002 03:39:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7479C5DF9B; Thu, 17 Oct 2002 03:39:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B7AD25DDCB for ; Thu, 17 Oct 2002 03:39:10 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H7dAH22619 for ; Thu, 17 Oct 2002 10:39:10 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 10:39:08 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 10:39:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [AAA-WG]: Use of the D-Bit clarification (proposed text to AnnexC etc.) Date: Thu, 17 Oct 2002 10:39:05 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4395@esebe016.ntc.nokia.com> Thread-Topic: Re: [AAA-WG]: Use of the D-Bit clarification (proposed text to AnnexC etc.) Thread-Index: AcJ1sETAboC6iQ20SsWCOWvH/gAVVg== X-Priority: 1 Importance: high From: To: , Cc: , , , , , X-OriginalArrivalTime: 17 Oct 2002 07:39:06.0312 (UTC) FILETIME=[45A7E480:01C275B0] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02990 Hi Bernard (et all), I have attempted a text proposal based on Bernard polishing of the issue 372, to address all the comments done so far. (only the modified text is included in this mail) Bernard do you feel confortable with this proposal? In the text the flag letter is still "D", if your preference is T flag I guess John can change the letter in the final text. Jari, Glen and Ohba could you check if the text is covering all your comments? Best Regards Marco I guess a better description of the flag is probably needed in Chapter 3. " (Possible) D(uplicate) - This flag is defined only for requests messages sent by a Diameter client or agents. If set, the message is a possible duplicate and a recipient node MAY later check if it really is a duplicate. If sending a message for first time, this flag MUST be cleared. It can be used only in cases where no answer has been got from the Server for a message and the message is sent again (e.g. due to a failover to an alternate agent, due to a recovered primary peer node or due to a client re-sendind a stored record). This flag MUST NOT be set if an error 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 Server for a message and the message is sent again (e.g. due to a failover to an alternate agent, due to a recovered primary peer node or due to a client re-sendind a stored record). This flag MUST NOT be set in answer messages." Thi is the proposal for ANNEX C, I think is indicative, generic and doesn't mandate anything at all to Diameter Server. "The following is an indicative example of how the D flag may be used by the server to detect duplicate requests. Implementers are advised, however, that configuration errors in the network or software errors cannot be detected solely by using the D-flag. A Diameter server MAY check the D flag of the received message to determine if the request is a possible duplicate. If the "D" flag is set in the request message, the server searches for a duplicate within a (configurable) duplication time window backward and forward. This limits database searching to those records where the "D" flag is set. In a well run network, network partitions and device faults will presumably be rare events, so this approach represents a substantial optimization of the duplicate detection process. During failover, it is possible for the original record to be received after the "D" flag marked record, due to differences in network delays experienced along the path by the original and duplicate transmission. The likelihood of this occurring increases as the failover interval is decreased. In order to detect with relative assurance the out of order duplicate record, the Diameter server SHOULD use backward and forward time windows when performing duplicate cheching for the "D" flag marked request. The forward time window SHOULD be at least a time period of approximately TIME_WAIT. From owner-aaa-wg@merit.edu Thu Oct 17 04:22: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 EAA03524 for ; Thu, 17 Oct 2002 04:22:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 172CF912A2; Thu, 17 Oct 2002 04:24:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CEA82912A3; Thu, 17 Oct 2002 04:24:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C4D38912A2 for ; Thu, 17 Oct 2002 04:24:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA8AA5E050; Thu, 17 Oct 2002 04:24:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id 019365E04F for ; Thu, 17 Oct 2002 04:24:21 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H8O2w25506 for ; Thu, 17 Oct 2002 11:24:02 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 11:24:19 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 11:24:18 +0300 content-class: urn:content-classes:message Subject: [AAA-WG]: Resolution of issue 372 - proposed text MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 17 Oct 2002 11:24:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FA0@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue 372 proposed text Thread-Index: AcJ1r44B88CBM10gRaG2A+NF/CPZIQABWn2A From: To: Cc: X-OriginalArrivalTime: 17 Oct 2002 08:24:18.0831 (UTC) FILETIME=[967171F0:01C275B6] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA03524 Hi all, So, it seems that we are moving to consensus on this issue. I propose the following text for section 3, based on Jari's mail. Please comment. John 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E T r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- ... some text .... T, potentially retransmitted message This flag is used as an indication of an application layer retransmission event, e.g. due to failover to an alternate server, or due to resending accounting records from non-volatile memory after a reboot of the client. If a Diameter client or agent knows that it is sending this request or accounting record contained in the request for the first time, it MAY reset this flag. If request is either known to be a retransmission or the Diameter client or agent is unable to assure that it is the first such request, it MUST set this flag. Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the the first transmitted request arrives at the server after the retransmitted request. This flag MUST NOT be set if an error answer message (about e.g. a protocol error) has been received for an previous message. It can be used only in cases where no answer has been received from the Server for a message and the message is sent again (e.g. due to a failover to an alternate agent, due to a recovered primary peer node or due to a client re-sendind a stored record). This flag MUST NOT be set in answer messages. Appendix C. The following is an example of how the T-flag may be used by the server to detect duplicate records. Implementers are advised, however, that configuration errors in the network or software errors cannot be detected solely by using the T-flag. Diameter server may check the T-flag of the received message to determine if the record is a possible duplicate. With the T-flag usage, the checking is based on tracking Session-ID and possibly Accounting-Record-Number AVPs. That tracking may be done for a configurable time window to future and to past for the corresponding AVP pairs, per a certain accounting record arriving to a recipient Diameter node. Only when a T-flag marked (i.e. T-flag set) accounting record is countered, its Session-ID and possibly Accounting-Record-Number AVP pair is buffered for a possible future check, but no check is needed immediately. The checking is done, Session-Id and possibly Accounting-Record-Number AVPs of the D-flag marked record against the other Session-ID and possibly Accounting-Record-Number AVP pairs of the time windows. If the duplicate record is not found in the backward and forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag mark is not removed from the accounting record when sending it further towards the end system. The network's accounting end system can be understood and implemented as a central logical entity (no matter if it would physically consist of several servers). It could then be left to the end system to compare the possible still existing D-flag marked records against others in a configurable backward and forward (e.g. 2* TIME_WAIT) time windows. Since backward and forward time windows are used to check if the D-flag marked record is really a duplicate, out of order accounting records is not an issue. From owner-aaa-wg@merit.edu Thu Oct 17 05:03: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 FAA04321 for ; Thu, 17 Oct 2002 05:03:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9D91D912A4; Thu, 17 Oct 2002 05:05:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6907E912A5; Thu, 17 Oct 2002 05:05:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 48DC8912A4 for ; Thu, 17 Oct 2002 05:05:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2E9DC5E0A4; Thu, 17 Oct 2002 05:05:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 462205E086 for ; Thu, 17 Oct 2002 05:05:19 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H95IH06415 for ; Thu, 17 Oct 2002 12:05:18 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 12:05:17 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 12:05:17 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 12:05:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Date: Thu, 17 Oct 2002 12:05:16 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4398@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: issue 372 proposed text Thread-Index: AcJ1r44B88CBM10gRaG2A+NF/CPZIQABWn2AAAF8GoA= From: To: , Cc: , , , X-OriginalArrivalTime: 17 Oct 2002 09:05:17.0683 (UTC) FILETIME=[50087C30:01C275BC] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA04321 Hi, > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request > for the first time, > it MAY reset this flag. I think this should be MUST since if the message is sent for the first time the T flag is not to be set. Also the text in Appendix C should be more generic and shoudn't refer to Session-Id and Accounting_Record_Number pairs as indicated by Ohba. I have collected the full set of changes so as to simplify the checking to all of you. Best Regards Marco 3 Diameter Header Change the header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- To 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E T r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Add the "T" flag description between "E" flag description and "r" flag description. R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed. 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 are commonly referred to as an error messages. This bit MUST NOT be set in request messages. See section 7.2. T(Potentialy re-transmitted message) - This flag is defined only for requests messages sent by a Diameter client or agents. This flag is used as an indication of an application layer retransmission event, (e.g. due to failover to an alternate peer, due to recovery to a primary peer or due to resending accounting records from non-volatile memory for example after a reboot of the client). If a Diameter client or agent knows that it is sending this request or accounting record contained in the request for the first time, it MUST reset this flag. If request is either known to be a retransmission or the Diameter client or agent is unable to assure that it is the first such request,it MUST set this flag. Diameter agents that receive a request with the "T" flag set, MUST keep the "T" flag set in the forwarded request. Diameter servers MAY use the "T" flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the first transmitted request arrives at the server after the retransmitted request. This flag MUST NOT be set if an error 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 Server for a message and the message is sent again, (e.g. due to a failover to an alternate peer, due to a recovered primary peer or due to a client re-sendind a stored record from non-volatile memory for example after a reboot of the client). This flag MUST NOT be set in answer messages. 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. 5.5.4 Failover and Failback Procedures Change the paragraph When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible. .....etc.. to When a transport failure is detected, if possible all messages in the queue are sent to an alternate agent with the "T" flag set. 8.2 Accounting Session State Machine Change the line of CLIENT, ACCOUNTING Idle Records in storage Send PendingB record to Idle Records in storage Send PendingB record with "T" flag set ANNEX C Change paragraph In general, only the duplicate generation at failover case is some- thing that can be reliably detected by the Diameter client. The Diam- eter server is therefore responsible for the duplicate detection pro- cess. When real-time duplicate detection is required, this implies a database-like search functionality to find duplicate records. Imple- mentors 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 ima- ginable network partition, perhaps a day as an example. So only records within this time window need to be looked at. Secondly, hash- ing techniques or other schemes may be used to eliminate the need to do a full search even in this set except for rare cases. to In general, only generation of duplicates due to failover or re-sending of records in non-volatile storage can be reliability detected by Diameter clients or agents. In such cases the Diameter client or agents can mark the message as possible duplicate by setting the "T" flag. Since the Diameter server is responsible for duplicate detection, it can choose to make use of the "T" flag or not, in order to optimize duplicate detection. Since the "T" flag does not affect interoperability, and may not be needed by some servers, generation of the "T" flag is required for Diameter clients and agents, but may be implemented by Diameter servers. As an example, it can be usually be assumed that duplicates appear within a time window of longest recorded network partition or device fault, perhaps a day. So only records within this time window need to be looked at. Secondly, hashing techniques or other schemes, such as the use of the "T" flag in the received messages, may be used to eliminate the need to do a full search even in this set except for rare cases. and ADD The following is an indicative example of how the "T" flag may be used by the server to detect duplicate requests. A Diameter server may check the "T" flag of the received message to determine if the request is a possible duplicate. If the "T" flag is set in the request message, the server searches for a duplicate within a (configurable) duplication time window backward and forward. This limits database searching to those records where the "T" flag is set. In a well run network, network partitions and device faults will presumably be rare events, so this approach represents a substantial optimization of the duplicate detection process. During failover, it is possible for the original record to be received after the "T" flag marked record, due to differences in network delays experienced along the path by the original and duplicate transmission. The likelihood of this occurring increases as the failover interval is decreased. In order to detect with relative assurance the possibly out of order duplicate record, the Diameter server should use backward and forward time windows when performing duplicate checking for the "T" flag marked request. The forward time window should be at least a time period of approximately TIME_WAIT. > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 17. October 2002 11:24 > To: jari.arkko@kolumbus.fi > Cc: aaa-wg@merit.edu > Subject: [AAA-WG]: Resolution of issue 372 - proposed text > > > Hi all, > > So, it seems that we are moving to consensus on this issue. > I propose the following text for section 3, based on Jari's mail. > Please comment. > > John > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E T r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > ... some text .... > > T, potentially retransmitted message > > This flag is used as an indication of an application layer > retransmission event, e.g. due to failover to an alternate > server, or due to resending accounting records from non-volatile > memory after a reboot of the client. > > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request > for the first time, > it MAY reset this flag. > > If request is either known to be a retransmission or > the Diameter > client or agent is unable to assure that it is the > first such request, > it MUST set this flag. > > Diameter agents that receive a request with the T flag set, MUST > keep the T flag set in the forwarded request. > > Diameter servers MAY use the T flag as an aid when > processing requests > and detecting duplicate messages. However, servers that > do this MUST > ensure that duplicates are found even when the the > first transmitted > request arrives at the server after the retransmitted request. > > This flag MUST NOT be set if an error answer message > (about e.g. a protocol error) has been received for an > previous message. It can be used only in cases where no > answer has been received from the Server for a message > and the message is sent again (e.g. due to a failover to an > alternate agent, due to a recovered primary peer > node or due to a client re-sendind a stored record). > This flag MUST NOT be set in answer messages. > > > Appendix C. > > The following is an example of how the T-flag may be used by > the server to > detect duplicate records. Implementers are advised, however, > that configuration > errors in the network or software errors cannot be detected > solely by using > the T-flag. > > Diameter server may check the T-flag of the received message > to determine > if the record is a possible duplicate. With the T-flag > usage, the checking > is based on tracking Session-ID and possibly > Accounting-Record-Number AVPs. > That tracking may be done for a configurable time window to > future and to > past for the corresponding AVP pairs, per a certain > accounting record arriving > to a recipient Diameter node. Only when a T-flag marked > (i.e. T-flag set) > accounting record is countered, its Session-ID and possibly > Accounting-Record-Number AVP pair is buffered for a possible > future check, > but no check is needed immediately. The checking is done, > Session-Id and > possibly Accounting-Record-Number AVPs of the D-flag marked > record against > the other Session-ID and possibly Accounting-Record-Number AVP pairs > of the time windows. If the duplicate record is not found in > the backward and > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag > mark is not removed > from the accounting record when sending it further towards > the end system. > The network's accounting end system can be understood and > implemented as > a central logical entity (no matter if it would physically > consist of several > servers). It could then be left to the end system to compare > the possible > still existing D-flag marked records against others in a > configurable > backward and forward (e.g. 2* TIME_WAIT) time windows. > > Since backward and forward time windows are used to check if > the D-flag marked > record is really a duplicate, out of order accounting > records is not an issue. > From owner-aaa-wg@merit.edu Thu Oct 17 08: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 IAA08312 for ; Thu, 17 Oct 2002 08:42:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CDD3191231; Thu, 17 Oct 2002 08:44:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 93999912A5; Thu, 17 Oct 2002 08:44:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1B9391231 for ; Thu, 17 Oct 2002 08:44:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8F4A95DD9C; Thu, 17 Oct 2002 08:44:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F1E055DD94 for ; Thu, 17 Oct 2002 08:44:15 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9HBgQk10276; Thu, 17 Oct 2002 04:42:26 -0700 Date: Thu, 17 Oct 2002 04:42:26 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, Subject: Re: [AAA-WG]: Resolution of issue 372 - proposed text In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FA0@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > If the duplicate record is not found in the backward and > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag mark is not removed > from the accounting record when sending it further towards the end system. Why would a Diameter agent need to do this check, rather than the accounting server? > It could then be left to the end system to compare the possible > still existing D-flag marked records against others in a configurable > backward and forward (e.g. 2* TIME_WAIT) time windows. This paragraph makes it sound like Diameter supports some kind of clustering capability. It's the *database* that is the single logical entity, not the servers. > Since backward and forward time windows are used to check if the D-flag marked > record is really a duplicate, out of order accounting records is not an issue. Not sure why the window is TIME_WAIT in the backward direction. In the case of a device that had a fault and was subsequently repaired (e.g. power supply went out, ops took several hours to make the repairs), it is possible that the duplicate resulting from the device coming up again and dumping its non-volatile storage could occur *hours* after the original was received. It would be great if all faults were resolved within TIME_WAIT, but I don't think most ops groups would agree to be held to that standard :) I'd also note that in this case, the device would need to be smart enough to know that any accounting records found in non-volatile memory on boot need to be set with the "T" bit. Assuming this is done, in the forward direction, the window can be smaller, because a original should only arrive *before* the duplicate in the case of failover. While the original connection is "suspect", the Diameter client may have switched over to the new server, and according to the transport state machine, the time between going into the "SUSPECT" state and closing the connection is Tw + TIME_WAIT, assuming that no heartbeat is detected. If a heartbeat is detected, then the original connection might remain up for considerably longer than this. So the time to look into the future is really until TIME_WAIT after the old connection is closed. This could be an indeterminate amount of time; to make it determine would require eliminating the SUSPECT state, which is not something that we want to do at this time. From owner-aaa-wg@merit.edu Thu Oct 17 08:50: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 IAA08614 for ; Thu, 17 Oct 2002 08:50:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A254E912A5; Thu, 17 Oct 2002 08:52:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BC2E912A6; Thu, 17 Oct 2002 08:52:41 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A8A9912A5 for ; Thu, 17 Oct 2002 08:52:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 564385E041; Thu, 17 Oct 2002 08:52:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id DD94C5DD9C for ; Thu, 17 Oct 2002 08:52:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9HBosn10395; Thu, 17 Oct 2002 04:50:54 -0700 Date: Thu, 17 Oct 2002 04:50:54 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: jari.arkko@kolumbus.fi, Subject: Re: [AAA-WG]: Resolution of issue 372 - proposed text In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FA0@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk I'd also add that adding the "T" bit to all records sent from storage is not correct. The term "storage" is used in the accounting server whenever there is a failure to transmit -- I don't think that it implies that failover has occurred. So this would cause many, many more records to be sent with the "T" bit set. From owner-aaa-wg@merit.edu Thu Oct 17 08:52: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 IAA08840 for ; Thu, 17 Oct 2002 08:52:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 32C5D912A6; Thu, 17 Oct 2002 08:54:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0228912A7; Thu, 17 Oct 2002 08:54:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C64FC912A6 for ; Thu, 17 Oct 2002 08:54:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B180B5E057; Thu, 17 Oct 2002 08:54:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id C42615E041 for ; Thu, 17 Oct 2002 08:54:33 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9HCsZH14175 for ; Thu, 17 Oct 2002 15:54:35 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 15:54:32 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 15:54:32 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C275DC.5625E1E8" Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text Date: Thu, 17 Oct 2002 15:54:31 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1DA3ED4D@esebe016.ntc.nokia.com> X-MS-Has-Attach: yes Thread-Topic: [AAA-WG]: Resolution of issue 372 - proposed text Thread-Index: AcJ12vcSNEvDHaYjTYOFjiH1FFCBGAAABlRA From: To: , Cc: , X-OriginalArrivalTime: 17 Oct 2002 12:54:32.0430 (UTC) FILETIME=[568050E0:01C275DC] Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C275DC.5625E1E8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, I'm sorry for the big mail "rally" around the proposed text. The result of this mail rally is probably, say confusion. Since the last mail I sent include all the comments received so far, I would propose to forget all *my* previously proposed text and consider for comment the last text I sent in the mail with subject RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set) I attach the mail here for your convenience. Do you agree with the approach? Best Regards Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 17. October 2002 14:42 > To: Loughney John (NRC/Helsinki) > Cc: jari.arkko@kolumbus.fi; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Resolution of issue 372 - proposed text >=20 >=20 > > If the duplicate record is not found in the backward and > > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag=20 > mark is not removed > > from the accounting record when sending it further towards=20 > the end system. >=20 > Why would a Diameter agent need to do this check, rather than the > accounting server? >=20 > > It could then be left to the end system to compare the possible > > still existing D-flag marked records against others in a=20 > configurable > > backward and forward (e.g. 2* TIME_WAIT) time windows. >=20 > This paragraph makes it sound like Diameter supports some kind of > clustering capability. It's the *database* that is the single logical > entity, not the servers. >=20 > > Since backward and forward time windows are used to check=20 > if the D-flag marked > > record is really a duplicate, out of order accounting=20 > records is not an issue. >=20 > Not sure why the window is TIME_WAIT in the backward direction. In the > case of a device that had a fault and was subsequently repaired (e.g. > power supply went out, ops took several hours to make the=20 > repairs), it is > possible that the duplicate resulting from the device coming=20 > up again and > dumping its non-volatile storage could occur *hours* after=20 > the original > was received. It would be great if all faults were resolved within > TIME_WAIT, but I don't think most ops groups would agree to be held to > that standard :) >=20 > I'd also note that in this case, the device would need to be=20 > smart enough > to know that any accounting records found in non-volatile=20 > memory on boot > need to be set with the "T" bit. >=20 > Assuming this is done, in the forward direction, the window can be > smaller, because a original should only arrive *before* the=20 > duplicate in > the case of failover. While the original connection is "suspect", the > Diameter client may have switched over to the new server, and=20 > according to > the transport state machine, the time between going into the "SUSPECT" > state and closing the connection is Tw + TIME_WAIT, assuming that no > heartbeat is detected. If a heartbeat is detected, then the > original connection might remain up for considerably longer=20 > than this. So > the time to look into the future is really until TIME_WAIT after the > old connection is closed. >=20 > This could be an indeterminate amount of time; to make it=20 > determine would > require eliminating the SUSPECT state, which is not something=20 > that we want > to do at this time. >=20 >=20 ------_=_NextPart_001_01C275DC.5625E1E8 Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Received: from esebe014.NOE.Nokia.com ([172.21.138.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 12:16:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Received: from esebh004.NOE.Nokia.com ([172.21.138.84]) by esebe014.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 12:16:08 +0300 Received: from esvir07nok.ntc.nokia.com ([172.21.143.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 12:16:06 +0300 Received: from mgw-x2.nokia.com (unverified) by esvir07nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 12:05:42 +0300 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9H95iM16108; Thu, 17 Oct 2002 12:05:44 +0300 (EET DST) Received: by trapdoor.merit.edu (Postfix) id 9D91D912A4; Thu, 17 Oct 2002 05:05:21 -0400 (EDT) content-class: urn:content-classes:message Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Date: Thu, 17 Oct 2002 12:05:16 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E4398@esebe016.ntc.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AAA-WG]: issue 372 proposed text Thread-Index: AcJ1r44B88CBM10gRaG2A+NF/CPZIQABWn2AAAF8GoA= From: To: , Cc: , , , Content-Transfer-Encoding: quoted-printable Hi, > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request=20 > for the first time, > it MAY reset this flag. I think this should be MUST since if the message is sent for the first time the T flag is not to be set. Also the text in Appendix C should be more generic and shoudn't refer to Session-Id and Accounting_Record_Number pairs as indicated by Ohba. I have collected the full set of changes so as to simplify the checking to all of you. Best Regards Marco 3 Diameter Header Change the header 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E r r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- To 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E T r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Add the "T" flag description between "E" flag description and "r" flag=20 description. R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed. 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 are commonly referred to as an error messages. This bit MUST NOT be set in request messages. See section 7.2. T(Potentialy re-transmitted message) - This flag is defined only for requests messages sent by a Diameter client or agents. This flag is used as an indication of an = application layer=20 retransmission event, (e.g. due to failover to an = alternate=20 peer, due to recovery to a primary peer or due to = resending=20 accounting records from non-volatile memory for = example after a reboot of the client). If a Diameter client or agent knows that it is = sending this request or accounting record contained in the request for=20 the first time, it MUST reset this flag. If request is either known to be a retransmission = or the=20 Diameter client or agent is unable to assure that it = is=20 the first such request,it MUST set this flag. Diameter agents that receive a request with the "T" flag set, MUST keep the "T" flag set in the forwarded = request. Diameter servers MAY use the "T" flag as an aid = when processing=20 requests and detecting duplicate messages. = However, servers=20 that do this MUST ensure that duplicates are = found even when=20 the first transmitted request arrives at the = server after the=20 retransmitted request.=20 This flag MUST NOT be set if an error answer = message (about e.g. a protocol error) has been got for an = earlier=20 similar message. It can be used only in cases = where no=20 answer has been got from the Server for a message = and the message is sent again, (e.g. due to a failover to an = alternate peer, due=20 to a recovered primary peer or due to a client = re-sendind a stored=20 record from non-volatile memory for example after = a reboot of the client). This flag MUST NOT be set in answer messages. r(eserved) - these flag bits are reserved for future use, and = MUST be set to=20 zero, otherwise an error MUST be sent to the = sender. 5.5.4 Failover and Failback Procedures Change the paragraph When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible.=20 .....etc.. to When a transport failure is detected, if possible all messages in the = queue are sent to an alternate agent with the "T" flag set.=20 =20 8.2 Accounting Session State Machine Change the line of CLIENT, ACCOUNTING Idle Records in storage Send PendingB record to Idle Records in storage Send PendingB record with "T" flag set ANNEX C Change paragraph In general, only the duplicate generation at failover case is some- thing that can be reliably detected by the Diameter client. The Diam- eter server is therefore responsible for the duplicate detection pro- cess. When real-time duplicate detection is required, this implies a database-like search functionality to find duplicate records. Imple- mentors 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 ima- ginable network partition, perhaps a day as an example. So only records within this time window need to be looked at. Secondly, hash- ing techniques or other schemes may be used to eliminate the need to do a full search even in this set except for rare cases. to In general, only generation of duplicates due to failover or = re-sending of=20 records in non-volatile storage can be reliability detected by = Diameter=20 clients or agents. In such cases the Diameter client or agents can = mark=20 the message as possible duplicate by setting the "T" flag. Since the=20 Diameter server is responsible for duplicate detection, it can choose = to=20 make use of the "T" flag or not, in order to optimize duplicate = detection.=20 Since the "T" flag does not affect interoperability, and may not be = needed by some servers, generation of the "T" flag is required for Diameter = clients=20 and agents, but may be implemented by Diameter servers.=20 As an example, it can be usually be assumed that duplicates appear within a time window of longest recorded network partition or device = fault,=20 perhaps a day. So only records within this time window need to be looked at. Secondly, hashing techniques or other schemes, such as the = use of the "T" flag in the received messages, may be used to eliminate the = need=20 to do a full search even in this set except for rare cases.=20 and ADD The following is an indicative example of how the "T" flag may be used = by=20 the server to detect duplicate requests. =20 A Diameter server may check the "T" flag of the received message to = determine if the request is a possible duplicate. If the "T" flag is set in the = request=20 message, the server searches for a duplicate within a (configurable) = duplication=20 time window backward and forward. This limits database searching to = those=20 records where the "T" flag is set. In a well run network, network = partitions=20 and device faults will presumably be rare events, so this approach = represents=20 a substantial optimization of the duplicate detection process.=20 During failover, it is possible for the original record to be received = after=20 the "T" flag marked record, due to differences in network delays = experienced=20 along the path by the original and duplicate transmission. The = likelihood of=20 this occurring increases as the failover interval is decreased.=20 In order to detect with relative assurance the possibly out of order = duplicate=20 record, the Diameter server should use backward and forward time = windows when performing duplicate checking for the "T" flag marked request. The forward time window should be at least a time period of = approximately=20 TIME_WAIT. > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 17. October 2002 11:24 > To: jari.arkko@kolumbus.fi > Cc: aaa-wg@merit.edu > Subject: [AAA-WG]: Resolution of issue 372 - proposed text >=20 >=20 > Hi all, >=20 > So, it seems that we are moving to consensus on this issue. > I propose the following text for section 3, based on Jari's mail. > Please comment. >=20 > John >=20 >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E T r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > ... some text .... >=20 > T, potentially retransmitted message >=20 > This flag is used as an indication of an application layer=20 > retransmission event, e.g. due to failover to an alternate > server, or due to resending accounting records from non-volatile > memory after a reboot of the client. >=20 > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request=20 > for the first time, > it MAY reset this flag. >=20 > If request is either known to be a retransmission or=20 > the Diameter > client or agent is unable to assure that it is the=20 > first such request, > it MUST set this flag. >=20 > Diameter agents that receive a request with the T flag set, MUST > keep the T flag set in the forwarded request. >=20 > Diameter servers MAY use the T flag as an aid when=20 > processing requests > and detecting duplicate messages. However, servers that=20 > do this MUST > ensure that duplicates are found even when the the=20 > first transmitted > request arrives at the server after the retransmitted request. >=20 > This flag MUST NOT be set if an error answer message > (about e.g. a protocol error) has been received for an=20 > previous message. It can be used only in cases where no=20 > answer has been received from the Server for a message=20 > and the message is sent again (e.g. due to a failover to an > alternate agent, due to a recovered primary peer > node or due to a client re-sendind a stored record). > This flag MUST NOT be set in answer messages. >=20 >=20 > Appendix C. >=20 > The following is an example of how the T-flag may be used by=20 > the server to=20 > detect duplicate records. Implementers are advised, however,=20 > that configuration=20 > errors in the network or software errors cannot be detected=20 > solely by using=20 > the T-flag. >=20 > Diameter server may check the T-flag of the received message=20 > to determine > if the record is a possible duplicate. With the T-flag=20 > usage, the checking=20 > is based on tracking Session-ID and possibly=20 > Accounting-Record-Number AVPs. > That tracking may be done for a configurable time window to=20 > future and to=20 > past for the corresponding AVP pairs, per a certain=20 > accounting record arriving=20 > to a recipient Diameter node. Only when a T-flag marked=20 > (i.e. T-flag set)=20 > accounting record is countered, its Session-ID and possibly=20 > Accounting-Record-Number AVP pair is buffered for a possible=20 > future check, > but no check is needed immediately. The checking is done,=20 > Session-Id and > possibly Accounting-Record-Number AVPs of the D-flag marked=20 > record against=20 > the other Session-ID and possibly Accounting-Record-Number AVP pairs=20 > of the time windows. If the duplicate record is not found in=20 > the backward and=20 > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag=20 > mark is not removed > from the accounting record when sending it further towards=20 > the end system. > The network's accounting end system can be understood and=20 > implemented as=20 > a central logical entity (no matter if it would physically=20 > consist of several=20 > servers). It could then be left to the end system to compare=20 > the possible > still existing D-flag marked records against others in a=20 > configurable=20 > backward and forward (e.g. 2* TIME_WAIT) time windows. >=20 > Since backward and forward time windows are used to check if=20 > the D-flag marked > record is really a duplicate, out of order accounting=20 > records is not an issue. >=20 ------_=_NextPart_001_01C275DC.5625E1E8-- From owner-aaa-wg@merit.edu Thu Oct 17 09:02: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 JAA09228 for ; Thu, 17 Oct 2002 09:02:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACA1C912A7; Thu, 17 Oct 2002 09:04:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 803D4912A9; Thu, 17 Oct 2002 09:04:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6620C912A7 for ; Thu, 17 Oct 2002 09:04:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CDDB5DD98; Thu, 17 Oct 2002 09:04:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by segue.merit.edu (Postfix) with ESMTP id 7D7515DD94 for ; Thu, 17 Oct 2002 09:04:47 -0400 (EDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g9HD4bPk022648; Thu, 17 Oct 2002 09:04:37 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id JAA21601; Thu, 17 Oct 2002 09:05:09 -0400 (EDT) Date: Thu, 17 Oct 2002 09:04:32 -0400 To: marco.stura@nokia.com Cc: john.loughney@nokia.com, jari.arkko@kolumbus.fi, aaa-wg@merit.edu, gwz@cisco.com, yohba@tari.toshiba.com, pcalhoun@bstormnetworks.com Subject: Re: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Message-ID: <20021017130432.GA1083@catfish> References: <142DC466081D9B409AAD1DDCA4B21E1D9E4398@esebe016.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1D9E4398@esebe016.ntc.nokia.com> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 337 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-aaa-wg@merit.edu Precedence: bulk Marco, On Thu, Oct 17, 2002 at 12:05:16PM +0300, marco.stura@nokia.com wrote: > Hi, > > > If a Diameter client or agent knows that it is sending this > > request or accounting record contained in the request > > for the first time, > > it MAY reset this flag. > > I think this should be MUST since if the message is sent for the > first time the T flag is not to be set. Agreed. > > Also the text in Appendix C should be more generic and shoudn't > refer to Session-Id and Accounting_Record_Number pairs as indicated > by Ohba. I agree. Thanks for the consideration. I have one comment, please see below. > > I have collected the full set of changes so as to simplify the > checking to all of you. > > Best Regards > Marco > > 3 Diameter Header > > Change the header > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E r r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > To > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E T r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Add the "T" flag description between "E" flag description and "r" flag > description. > > R(equest) - If set, the message is a request. If cleared, the > message is an answer. > P(roxiable) - If set, the message MAY be proxied, relayed or > redirected. If cleared, the message MUST be > locally processed. > 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 are commonly referred to as an error > messages. This bit MUST NOT be set in request > messages. See section 7.2. > T(Potentialy re-transmitted message) > - This flag is defined only for requests messages > sent by a Diameter client or agents. > This flag is used as an indication of an application layer > retransmission event, (e.g. due to failover to an alternate > peer, due to recovery to a primary peer or due to resending > accounting records from non-volatile memory for example > after a reboot of the client). > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request for > the first time, it MUST reset this flag. > If request is either known to be a retransmission or the > Diameter client or agent is unable to assure that it is > the first such request,it MUST set this flag. > Diameter agents that receive a request with the "T" flag set, > MUST keep the "T" flag set in the forwarded request. > Diameter servers MAY use the "T" flag as an aid when processing > requests and detecting duplicate messages. > However, servers > that do this MUST ensure that duplicates are found even when > the first transmitted request arrives at the server after the > retransmitted request. I think the above sentense can be moved to the Appendix. Yoshihiro Ohba > This flag MUST NOT be set if an error 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 Server for a message and the message > is sent again, (e.g. due to a failover to an alternate peer, due > to a recovered primary peer or due to a client re-sendind a stored > record from non-volatile memory for example after a reboot of the client). > This flag MUST NOT be set in answer messages. > 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. > > 5.5.4 Failover and Failback Procedures > > Change the paragraph > > When a transport failure is detected, all messages in the queue are > sent to an alternate agent, if possible. > .....etc.. > > to > > When a transport failure is detected, if possible all messages in the queue are > sent to an alternate agent with the "T" flag set. > > > 8.2 Accounting Session State Machine > > Change the line of CLIENT, ACCOUNTING > > Idle Records in storage Send PendingB > record > > to > > Idle Records in storage Send PendingB > record > with "T" > flag set > > ANNEX C > > Change paragraph > > In general, only the duplicate generation at failover case is some- > thing that can be reliably detected by the Diameter client. The Diam- > eter server is therefore responsible for the duplicate detection pro- > cess. When real-time duplicate detection is required, this implies a > database-like search functionality to find duplicate records. Imple- > mentors 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 ima- > ginable network partition, perhaps a day as an example. So only > records within this time window need to be looked at. Secondly, hash- > ing techniques or other schemes may be used to eliminate the need to > do a full search even in this set except for rare cases. > > > to > > In general, only generation of duplicates due to failover or re-sending of > records in non-volatile storage can be reliability detected by Diameter > clients or agents. In such cases the Diameter client or agents can mark > the message as possible duplicate by setting the "T" flag. Since the > Diameter server is responsible for duplicate detection, it can choose to > make use of the "T" flag or not, in order to optimize duplicate detection. > Since the "T" flag does not affect interoperability, and may not be needed > by some servers, generation of the "T" flag is required for Diameter clients > and agents, but may be implemented by Diameter servers. > > As an example, it can be usually be assumed that duplicates appear > within a time window of longest recorded network partition or device fault, > perhaps a day. So only records within this time window need to be > looked at. Secondly, hashing techniques or other schemes, such as the use > of the "T" flag in the received messages, may be used to eliminate the need > to do a full search even in this set except for rare cases. > > and ADD > > The following is an indicative example of how the "T" flag may be used by > the server to detect duplicate requests. > > A Diameter server may check the "T" flag of the received message to determine > if the request is a possible duplicate. If the "T" flag is set in the request > message, the server searches for a duplicate within a (configurable) duplication > time window backward and forward. This limits database searching to those > records where the "T" flag is set. In a well run network, network partitions > and device faults will presumably be rare events, so this approach represents > a substantial optimization of the duplicate detection process. > During failover, it is possible for the original record to be received after > the "T" flag marked record, due to differences in network delays experienced > along the path by the original and duplicate transmission. The likelihood of > this occurring increases as the failover interval is decreased. > In order to detect with relative assurance the possibly out of order duplicate > record, the Diameter server should use backward and forward time windows > when performing duplicate checking for the "T" flag marked request. > The forward time window should be at least a time period of approximately > TIME_WAIT. > > > -----Original Message----- > > From: ext [mailto:john.loughney@nokia.com] > > Sent: 17. October 2002 11:24 > > To: jari.arkko@kolumbus.fi > > Cc: aaa-wg@merit.edu > > Subject: [AAA-WG]: Resolution of issue 372 - proposed text > > > > > > Hi all, > > > > So, it seems that we are moving to consensus on this issue. > > I propose the following text for section 3, based on Jari's mail. > > Please comment. > > > > John > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ver | Message Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E T r r r r| Command-Code | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Application-ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hop-by-Hop Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | End-to-End Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > ... some text .... > > > > T, potentially retransmitted message > > > > This flag is used as an indication of an application layer > > retransmission event, e.g. due to failover to an alternate > > server, or due to resending accounting records from non-volatile > > memory after a reboot of the client. > > > > If a Diameter client or agent knows that it is sending this > > request or accounting record contained in the request > > for the first time, > > it MAY reset this flag. > > > > If request is either known to be a retransmission or > > the Diameter > > client or agent is unable to assure that it is the > > first such request, > > it MUST set this flag. > > > > Diameter agents that receive a request with the T flag set, MUST > > keep the T flag set in the forwarded request. > > > > Diameter servers MAY use the T flag as an aid when > > processing requests > > and detecting duplicate messages. However, servers that > > do this MUST > > ensure that duplicates are found even when the the > > first transmitted > > request arrives at the server after the retransmitted request. > > > > This flag MUST NOT be set if an error answer message > > (about e.g. a protocol error) has been received for an > > previous message. It can be used only in cases where no > > answer has been received from the Server for a message > > and the message is sent again (e.g. due to a failover to an > > alternate agent, due to a recovered primary peer > > node or due to a client re-sendind a stored record). > > This flag MUST NOT be set in answer messages. > > > > > > Appendix C. > > > > The following is an example of how the T-flag may be used by > > the server to > > detect duplicate records. Implementers are advised, however, > > that configuration > > errors in the network or software errors cannot be detected > > solely by using > > the T-flag. > > > > Diameter server may check the T-flag of the received message > > to determine > > if the record is a possible duplicate. With the T-flag > > usage, the checking > > is based on tracking Session-ID and possibly > > Accounting-Record-Number AVPs. > > That tracking may be done for a configurable time window to > > future and to > > past for the corresponding AVP pairs, per a certain > > accounting record arriving > > to a recipient Diameter node. Only when a T-flag marked > > (i.e. T-flag set) > > accounting record is countered, its Session-ID and possibly > > Accounting-Record-Number AVP pair is buffered for a possible > > future check, > > but no check is needed immediately. The checking is done, > > Session-Id and > > possibly Accounting-Record-Number AVPs of the D-flag marked > > record against > > the other Session-ID and possibly Accounting-Record-Number AVP pairs > > of the time windows. If the duplicate record is not found in > > the backward and > > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag > > mark is not removed > > from the accounting record when sending it further towards > > the end system. > > The network's accounting end system can be understood and > > implemented as > > a central logical entity (no matter if it would physically > > consist of several > > servers). It could then be left to the end system to compare > > the possible > > still existing D-flag marked records against others in a > > configurable > > backward and forward (e.g. 2* TIME_WAIT) time windows. > > > > Since backward and forward time windows are used to check if > > the D-flag marked > > record is really a duplicate, out of order accounting > > records is not an issue. > > > From owner-aaa-wg@merit.edu Thu Oct 17 09:22: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 JAA09999 for ; Thu, 17 Oct 2002 09:22:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 522A0912AA; Thu, 17 Oct 2002 09:24:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 21B67912AB; Thu, 17 Oct 2002 09:24:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 323CE912AA for ; Thu, 17 Oct 2002 09:24:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 12C015DD9F; Thu, 17 Oct 2002 09:24:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9D8C95DD9D for ; Thu, 17 Oct 2002 09:24:43 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9HCMjX10722; Thu, 17 Oct 2002 05:22:45 -0700 Date: Thu, 17 Oct 2002 05:22:45 -0700 (PDT) From: Bernard Aboba To: marco.stura@nokia.com Cc: john.loughney@nokia.com, , Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text In-Reply-To: <142DC466081D9B409AAD1DDCA4B21E1DA3ED4D@esebe016.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > I attach the mail here for your convenience. > > Do you agree with the approach? > > Best Regards > Marco I've updated the text of Issue 372 on the archive to reflect the proposed changes. From owner-aaa-wg@merit.edu Thu Oct 17 09:54: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 JAA11310 for ; Thu, 17 Oct 2002 09:54:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93A53912B0; Thu, 17 Oct 2002 09:56:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F1AF912B1; Thu, 17 Oct 2002 09:56:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D26A912B0 for ; Thu, 17 Oct 2002 09:56:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 363A75DDA2; Thu, 17 Oct 2002 09:56:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 4AC185DDA0 for ; Thu, 17 Oct 2002 09:56:32 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9HDuXH13250 for ; Thu, 17 Oct 2002 16:56:33 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 17 Oct 2002 16:56:30 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 17 Oct 2002 16:56:28 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text Date: Thu, 17 Oct 2002 16:56:27 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E439B@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Resolution of issue 372 - proposed text Thread-Index: AcJ14I3Jh0swm8FqTO6fTo0Sjf+XdQAA2Nhw From: To: Cc: , , X-OriginalArrivalTime: 17 Oct 2002 13:56:28.0280 (UTC) FILETIME=[FD520780:01C275E4] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA11310 Hi Bernard, for the accounting state machine in the proposed resolution (http://www.drizzle.com/~aboba/AAA/issues.html#Issue%20372) you wrote. [BA - does this make sense? I think not, because "storage" here may not mean non-volatile storage, just placement in the buffer. This would result in many, many more records marked with the T flag than is really necessary.] I agree, changing the state machine here would really mean sending many, many more T=1 records than is really necessary. This change shouldn't be required. Br Marco > -----Original Message----- > From: ext Bernard Aboba [mailto:aboba@internaut.com] > Sent: 17. October 2002 15:23 > To: Stura Marco (NET/Helsinki) > Cc: Loughney John (NRC/Helsinki); jari.arkko@kolumbus.fi; > aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text > > > > I attach the mail here for your convenience. > > > > Do you agree with the approach? > > > > Best Regards > > Marco > > I've updated the text of Issue 372 on the archive to reflect > the proposed > changes. > > From owner-aaa-wg@merit.edu Thu Oct 17 12:04: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 MAA15765 for ; Thu, 17 Oct 2002 12:04:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16A18912C1; Thu, 17 Oct 2002 12:06:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFF2B912C2; Thu, 17 Oct 2002 12:06:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B815D912C1 for ; Thu, 17 Oct 2002 12:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9ADA55DDFD; Thu, 17 Oct 2002 12:06:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 1457F5DDA6 for ; Thu, 17 Oct 2002 12:06:45 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HG6b217891; Thu, 17 Oct 2002 09:06:37 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g9HG6mM27589; Thu, 17 Oct 2002 11:06:49 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 17 Oct 2002 11:06:36 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D24067554FE@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: john.loughney@nokia.com, randy@psg.com Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Thu, 17 Oct 2002 11:06:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C275F7.295BD010" 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_01C275F7.295BD010 Content-Type: text/plain john.loughney@nokia.com wrote: > > The proposal is to use the d-bit with real-time accounting to > assign a priority to all accounting requests where the D-bit > = 0, as we can safely assume this message is not a duplicate > request. With out it, we can never assume that an accounting request > is not a duplicate. > Respectfully disagree. Without the T/D-bit it is possible to detect re-transmissions as I said before. Use a sequenceID in the accounting messages. The billing systems are smart enough to detect duplications based on the last successfully processed message sequenceID. > For an accounting request where the d-bit = 1, then the > proposal is not to process the message in real-time, but to > have an optimized duplicate detection algorithm and/or > configurable based on service provider's needs. Here you are saying that D/T=1 messages wouldn't be processed in real-time. What happens if the D/T=0 was never received at the server. The user will get service only when the server responds back for the D/T=1 message which was delayed (non real-time) by several seconds e.g. 30 -120 secs at least. The user has to wait upto 2 mins to get service. Won't that piss off the user? > With any > luck, messages with the d-bit = 1 should an extremely small > number. This type of mechanism is already in use in some > GPRS networks and shown that the mechanism is effective. > We may be talking about some specific implementation here. > Of course, one could suggest having a hashed-based look-up to > perform the duplicate check, but that may increase the delay > to the user; as well as cause additionally hardware needs > (memory & processor) to the service provider to ensure that > they are able to perform the duplicate check in real-time. > > I understand that this type of functionality may not be > needed in traditional IP-style accounting practices; but for > cellular packet services, where heavy use of pre-paid > services is common, this is needed. > Not really. pre-paid services can be deployed and used w/o this retransmission bit in the base protocol header. ------_=_NextPart_001_01C275F7.295BD010 Content-Type: text/html RE: [AAA-WG]: Use of the D-Bit clarification

john.loughney@nokia.com wrote:

>
> The proposal is to use the d-bit with real-time accounting to
> assign a priority to all accounting requests where the D-bit
> = 0, as we can safely assume this message is not a duplicate
> request. With out it, we can never assume that an accounting request
> is not a duplicate.
>

Respectfully disagree. Without the T/D-bit it is possible to detect
re-transmissions as I said before. Use a sequenceID in the
accounting messages. The billing systems are smart enough to detect
duplications based on the last successfully processed message sequenceID.

> For an accounting request where the d-bit = 1, then the
> proposal is not to process the message in real-time, but to
> have an optimized duplicate detection algorithm and/or
> configurable based on service provider's needs. 

Here you are saying that D/T=1 messages wouldn't be processed in
real-time. What happens if the D/T=0 was never received at the server.
The user will get service only when the server responds back for the
D/T=1 message which was delayed (non real-time) by several seconds e.g.
30 -120 secs at least. The user has to wait upto 2 mins to get service.
Won't that piss off the user?

> With any
> luck, messages with the d-bit = 1 should an extremely small
> number.  This type of mechanism is already in use in some
> GPRS networks and shown that the mechanism is effective.
>

We may be talking about some specific implementation here.

> Of course, one could suggest having a hashed-based look-up to
> perform the duplicate check, but that may increase the delay
> to the user; as well as cause additionally hardware needs
> (memory & processor) to the service provider to ensure that
> they are able to perform the duplicate check in real-time.
>
> I understand that this type of functionality may not be
> needed in traditional IP-style accounting practices; but for
> cellular packet services, where heavy use of pre-paid
> services is common, this is needed.
>

Not really. pre-paid services can be deployed and used w/o this
retransmission bit in the base protocol header.

------_=_NextPart_001_01C275F7.295BD010-- From owner-aaa-wg@merit.edu Thu Oct 17 14:05: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 OAA20189 for ; Thu, 17 Oct 2002 14:05:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 48105912CE; Thu, 17 Oct 2002 14:07:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 155BB912CF; Thu, 17 Oct 2002 14:07:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1DFDA912CE for ; Thu, 17 Oct 2002 14:07:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08F9C5DDB4; Thu, 17 Oct 2002 14:07:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by segue.merit.edu (Postfix) with ESMTP id BDEDF5DD8C for ; Thu, 17 Oct 2002 14:07:38 -0400 (EDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id F24B86A911; Thu, 17 Oct 2002 21:07:32 +0300 (EEST) Message-ID: <3DAEF45C.4080806@kolumbus.fi> Date: Thu, 17 Oct 2002 20:33:16 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kuntal Chowdhury Cc: john.loughney@nokia.com, randy@psg.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Use of the D-Bit clarification References: <23BDB0046F3ED51185CD0002A5608D24067554FE@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kuntal Chowdhury wrote: > > For an accounting request where the d-bit = 1, then the > > proposal is not to process the message in real-time, but to > > have an optimized duplicate detection algorithm and/or > > configurable based on service provider's needs. > > Here you are saying that D/T=1 messages wouldn't be processed in > real-time. What happens if the D/T=0 was never received at the server. > The user will get service only when the server responds back for the > D/T=1 message which was delayed (non real-time) by several seconds e.g. > 30 -120 secs at least. The user has to wait upto 2 mins to get service. > Won't that piss off the user? I agree. The T bit is *only* for retransmission detection, not for priority. (In fact, I have previously proposed a new AVP for specifically representing priority, so that proxies can schedule outgoing records in priority order. This is a much more general and useful mechanism, and can hopefully be done as a separate RFC at some point in time.) > > Of course, one could suggest having a hashed-based look-up to > > perform the duplicate check, but that may increase the delay > > to the user; as well as cause additionally hardware needs > > (memory & processor) to the service provider to ensure that > > they are able to perform the duplicate check in real-time. > > > > I understand that this type of functionality may not be > > needed in traditional IP-style accounting practices; but for > > cellular packet services, where heavy use of pre-paid > > services is common, this is needed. > > > > Not really. pre-paid services can be deployed and used w/o this > retransmission bit in the base protocol header. Yes. People have pointed out that duplicate detection can be performed without protocol extensions as well. The Nokia folks have stated that they believe they can do this detection faster or with less memory if the T bit is introduced to the protocol. *I* would choose other implementation tactics myself, but the matter is quite important for very large deployments and I'd hate to get into trouble later with this. Without specific measurements to prove the case one way or the other, I'm willing to accept an informational T bit in the header, as long as we don't mandate any specific duplicate detection algorithm on the server side. And I don't want any priority meanings for this bit either, for the reasons that you Kuntal brought up well in the above. If it turns out that most implementations don't use the T bit, at least we can get some useful information about the Diameter transport behaviour by observing the number of T=1 requests. Jari From owner-aaa-wg@merit.edu Fri Oct 18 01:46: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 BAA07276 for ; Fri, 18 Oct 2002 01:46:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 064AB912E2; Fri, 18 Oct 2002 01:48:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9D1E912E3; Fri, 18 Oct 2002 01:48:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2D16A912E2 for ; Fri, 18 Oct 2002 01:47:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0FD445DDCA; Fri, 18 Oct 2002 01:47:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 22E085DDC9 for ; Fri, 18 Oct 2002 01:47:48 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9I5lnH17787 for ; Fri, 18 Oct 2002 08:47:49 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 18 Oct 2002 08:47:46 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 08:47:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Use of the D-Bit clarification Date: Fri, 18 Oct 2002 08:47:46 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E439D@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ2CCwEx0wAKkBIS4izjVFvRT/Z8QAX4ePg From: To: , Cc: , , X-OriginalArrivalTime: 18 Oct 2002 05:47:46.0570 (UTC) FILETIME=[E2A1E6A0:01C27669] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA07276 Hi, > Kuntal Chowdhury wrote: > > > > For an accounting request where the d-bit = 1, then the > > > proposal is not to process the message in real-time, but to > > > have an optimized duplicate detection algorithm and/or > > > configurable based on service provider's needs. > > > > Here you are saying that D/T=1 messages wouldn't be processed in > > real-time. What happens if the D/T=0 was never received at > the server. > > The user will get service only when the server responds back for the > > D/T=1 message which was delayed (non real-time) by several > seconds e.g. > > 30 -120 secs at least. The user has to wait upto 2 mins to > get service. > > Won't that piss off the user? Please refer to my explanation of the use of the T-flag (at that time still D) Mail subject "[AAA-WG]: Use of the D-Bit clarification" why the user wouldn't be piss off and what usually are the application mechanisms defined for real-time accounting (i.e. prepaid). Jari Arkko wrote: > I agree. The T bit is *only* for retransmission detection, not > for priority. Agreed, absolutely no priority meaning. > (In fact, I have previously proposed a new AVP for specifically > representing priority, so that proxies can schedule outgoing > records in priority order. This is a much more general and useful > mechanism, and can hopefully be done as a separate RFC at some > point in time.) Very interesting indeed. > Yes. People have pointed out that duplicate detection can be > performed without protocol extensions as well. The Nokia folks > have stated that they believe they can do this detection faster > or with less memory if the T bit is introduced to the protocol. > *I* would choose other implementation tactics myself, but the > matter is quite important for very large deployments and I'd > hate to get into trouble later with this. Without specific > measurements to prove the case one way or the other, I'm > willing to accept an informational T bit in the header, as > long as we don't mandate any specific duplicate detection > algorithm on the server side. And I don't want any priority > meanings for this bit either, for the reasons that you Kuntal > brought up well in the above. If it turns out that most > implementations don't use the T bit, at least we can get > some useful information about the Diameter transport behaviour > by observing the number of T=1 requests. Right Jari! Nokia folks proposal was based on implementation experience with existing charging protocols e.g. used in 3G/2G GPRS networks. And since the matter is very important for very large deployments, you exactly made the point. Thanks Jari Marco From owner-aaa-wg@merit.edu Fri Oct 18 06:51: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 GAA20756 for ; Fri, 18 Oct 2002 06:51:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67199912EA; Fri, 18 Oct 2002 06:53:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 387CA912EB; Fri, 18 Oct 2002 06:53:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFBBA912EA for ; Fri, 18 Oct 2002 06:53:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B32D65DE31; Fri, 18 Oct 2002 06:53:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 084825DDEC for ; Fri, 18 Oct 2002 06:53:44 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9IArjH12773 for ; Fri, 18 Oct 2002 13:53:45 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 18 Oct 2002 13:53:42 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 18 Oct 2002 13:53:42 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [AAA-WG]: Resolution of Issue 372 - done! X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Fri, 18 Oct 2002 13:53:41 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58AF@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Use of the D-Bit clarification Thread-Index: AcJ2EQPJkPv/APKGQlKeggMe8WDhbwAg1LYA From: To: X-OriginalArrivalTime: 18 Oct 2002 10:53:42.0574 (UTC) FILETIME=[9FA9D4E0:01C27694] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA20756 Hi all, It seems that we have come to consensus on issue 372. We want to get the Diameter Base spec to IETF last call as soon as possible, so I will add the text that is on the website (http://www.drizzle.com/~aboba/AAA/issues.html) except for section 8.2, which is incorrect (as stated by Bernard) - meaning I will not touch 8.2. Thanks! John From owner-aaa-wg@merit.edu Fri Oct 18 11:52: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 LAA01537 for ; Fri, 18 Oct 2002 11:52:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A78691300; Fri, 18 Oct 2002 11:54:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B9D291302; Fri, 18 Oct 2002 11:54:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1173991300 for ; Fri, 18 Oct 2002 11:54:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EDA205DE57; Fri, 18 Oct 2002 11:54:49 -0400 (EDT) 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 69A675DE54 for ; Fri, 18 Oct 2002 11:54:49 -0400 (EDT) Received: from gwzw2k (rtp-vpn1-393.cisco.com [10.82.225.137]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA21179; Fri, 18 Oct 2002 08:54:39 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , Cc: , "Glen Zorn" Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text Date: Fri, 18 Oct 2002 08:54:35 -0700 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: <0C1353ABB1DEB74DB067ADFF749C4EEFD38FA0@esebe004.ntc.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John Loughney [mailto:john.loughney@nokia.com] writes: > Hi all, > > So, it seems that we are moving to consensus on this issue. > I propose the following text for section 3, based on Jari's mail. > Please comment. > > John > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E T r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > ... some text .... > > T, potentially retransmitted message Why "potentially retransmitted"? I would think that this must be deterministic... > > This flag is used as an indication of an application layer > retransmission event, e.g. due to failover to an alternate > server, or due to resending accounting records from non-volatile > memory after a reboot of the client. > > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request for the first time, > it MAY reset this flag. In order to assure that only retransmissions have the flag set, I would change this MAY to MUST. > > If request is either known to be a retransmission or the Diameter > client or agent is unable to assure that it is the first such request, > it MUST set this flag. Does this mean that a stateless agent would always set the flag before forwarding? > > Diameter agents that receive a request with the T flag set, MUST > keep the T flag set in the forwarded request. > > Diameter servers MAY use the T flag as an aid when processing requests > and detecting duplicate messages. However, servers that do this MUST > ensure that duplicates are found even when the the first transmitted > request arrives at the server after the retransmitted request. > > This flag MUST NOT be set if an error answer message > (about e.g. a protocol error) has been received for an > previous message. Change "an" to "the", I think; otherwise, this could be interpreted as "if a protocol error ever happens, never set the 'T' bit again" > It can be used only in cases where no > answer has been received from the Server for a message > and the message is sent again (e.g. due to a failover to an > alternate agent, due to a recovered primary peer > node or due to a client re-sendind a stored record). > This flag MUST NOT be set in answer messages. > > > Appendix C. > > The following is an example of how the T-flag may be used by the > server to > detect duplicate records. Implementers are advised, however, > that configuration > errors in the network or software errors cannot be detected > solely by using > the T-flag. > > Diameter server may check the T-flag of the received message to determine > if the record is a possible duplicate. With the T-flag usage, > the checking > is based on tracking Session-ID and possibly > Accounting-Record-Number AVPs. > That tracking may be done for a configurable time window to > future and to > past for the corresponding AVP pairs, per a certain accounting > record arriving > to a recipient Diameter node. Only when a T-flag marked (i.e. > T-flag set) > accounting record is countered, its Session-ID and possibly > Accounting-Record-Number AVP pair is buffered for a possible > future check, > but no check is needed immediately. The checking is done, Session-Id and > possibly Accounting-Record-Number AVPs of the D-flag marked > record against > the other Session-ID and possibly Accounting-Record-Number AVP pairs > of the time windows. If the duplicate record is not found in the > backward and > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag mark > is not removed > from the accounting record when sending it further towards the > end system. > The network's accounting end system can be understood and implemented as > a central logical entity (no matter if it would physically > consist of several > servers). It could then be left to the end system to compare the possible > still existing D-flag marked records against others in a configurable > backward and forward (e.g. 2* TIME_WAIT) time windows. > > Since backward and forward time windows are used to check if the > D-flag marked > record is really a duplicate, out of order accounting records is > not an issue. > > From owner-aaa-wg@merit.edu Fri Oct 18 11:57: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 LAA01710 for ; Fri, 18 Oct 2002 11:57:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C9A591302; Fri, 18 Oct 2002 11:59:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 31A7291303; Fri, 18 Oct 2002 11:59:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF9AE91302 for ; Fri, 18 Oct 2002 11:59:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8E945DE54; Fri, 18 Oct 2002 11:59:06 -0400 (EDT) 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 5666F5DDB6 for ; Fri, 18 Oct 2002 11:59:06 -0400 (EDT) Received: from gwzw2k (rtp-vpn1-393.cisco.com [10.82.225.137]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA28576; Fri, 18 Oct 2002 08:58:53 -0700 (PDT) Reply-To: From: "Glen Zorn" To: , , Cc: , , Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Date: Fri, 18 Oct 2002 08:58:50 -0700 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: <142DC466081D9B409AAD1DDCA4B21E1D9E4398@esebe016.ntc.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit marco.stura@nokia.com [mailto:marco.stura@nokia.com] writes: ... > and ADD This example sems to be specific to the application in question, and not particularly applicable in the general case; I would leave it out of the document. > > The following is an indicative example of how the "T" flag may > be used by > the server to detect duplicate requests. > > A Diameter server may check the "T" flag of the received > message to determine > if the request is a possible duplicate. If the "T" flag is set > in the request > message, the server searches for a duplicate within a > (configurable) duplication > time window backward and forward. This limits database > searching to those > records where the "T" flag is set. In a well run network, > network partitions > and device faults will presumably be rare events, so this > approach represents > a substantial optimization of the duplicate detection process. > During failover, it is possible for the original record to be > received after > the "T" flag marked record, due to differences in network > delays experienced > along the path by the original and duplicate transmission. The > likelihood of > this occurring increases as the failover interval is decreased. > In order to detect with relative assurance the possibly out of > order duplicate > record, the Diameter server should use backward and forward time windows > when performing duplicate checking for the "T" flag marked request. > The forward time window should be at least a time period of > approximately > TIME_WAIT. > > > -----Original Message----- > > From: ext [mailto:john.loughney@nokia.com] > > Sent: 17. October 2002 11:24 > > To: jari.arkko@kolumbus.fi > > Cc: aaa-wg@merit.edu > > Subject: [AAA-WG]: Resolution of issue 372 - proposed text > > > > > > Hi all, > > > > So, it seems that we are moving to consensus on this issue. > > I propose the following text for section 3, based on Jari's mail. > > Please comment. > > > > John > > > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Ver | Message Length | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |R P E T r r r r| Command-Code | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Application-ID | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Hop-by-Hop Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | End-to-End Identifier | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | AVPs ... > > +-+-+-+-+-+-+-+-+-+-+-+-+- > > > > ... some text .... > > > > T, potentially retransmitted message > > > > This flag is used as an indication of an application layer > > retransmission event, e.g. due to failover to an alternate > > server, or due to resending accounting records from non-volatile > > memory after a reboot of the client. > > > > If a Diameter client or agent knows that it is sending this > > request or accounting record contained in the request > > for the first time, > > it MAY reset this flag. > > > > If request is either known to be a retransmission or > > the Diameter > > client or agent is unable to assure that it is the > > first such request, > > it MUST set this flag. > > > > Diameter agents that receive a request with the T flag set, MUST > > keep the T flag set in the forwarded request. > > > > Diameter servers MAY use the T flag as an aid when > > processing requests > > and detecting duplicate messages. However, servers that > > do this MUST > > ensure that duplicates are found even when the the > > first transmitted > > request arrives at the server after the retransmitted request. > > > > This flag MUST NOT be set if an error answer message > > (about e.g. a protocol error) has been received for an > > previous message. It can be used only in cases where no > > answer has been received from the Server for a message > > and the message is sent again (e.g. due to a failover to an > > alternate agent, due to a recovered primary peer > > node or due to a client re-sendind a stored record). > > This flag MUST NOT be set in answer messages. > > > > > > Appendix C. > > > > The following is an example of how the T-flag may be used by > > the server to > > detect duplicate records. Implementers are advised, however, > > that configuration > > errors in the network or software errors cannot be detected > > solely by using > > the T-flag. > > > > Diameter server may check the T-flag of the received message > > to determine > > if the record is a possible duplicate. With the T-flag > > usage, the checking > > is based on tracking Session-ID and possibly > > Accounting-Record-Number AVPs. > > That tracking may be done for a configurable time window to > > future and to > > past for the corresponding AVP pairs, per a certain > > accounting record arriving > > to a recipient Diameter node. Only when a T-flag marked > > (i.e. T-flag set) > > accounting record is countered, its Session-ID and possibly > > Accounting-Record-Number AVP pair is buffered for a possible > > future check, > > but no check is needed immediately. The checking is done, > > Session-Id and > > possibly Accounting-Record-Number AVPs of the D-flag marked > > record against > > the other Session-ID and possibly Accounting-Record-Number AVP pairs > > of the time windows. If the duplicate record is not found in > > the backward and > > forward (e.g. 2 * TIME_WAIT) time windows, then the T-flag > > mark is not removed > > from the accounting record when sending it further towards > > the end system. > > The network's accounting end system can be understood and > > implemented as > > a central logical entity (no matter if it would physically > > consist of several > > servers). It could then be left to the end system to compare > > the possible > > still existing D-flag marked records against others in a > > configurable > > backward and forward (e.g. 2* TIME_WAIT) time windows. > > > > Since backward and forward time windows are used to check if > > the D-flag marked > > record is really a duplicate, out of order accounting > > records is not an issue. > > > > From owner-aaa-wg@merit.edu Fri Oct 18 12:04: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 MAA01887 for ; Fri, 18 Oct 2002 12:04:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 02CCB91303; Fri, 18 Oct 2002 12:06:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BDF8391304; Fri, 18 Oct 2002 12:06:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 83C9D91303 for ; Fri, 18 Oct 2002 12:06:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 677845DE5A; Fri, 18 Oct 2002 12:06:01 -0400 (EDT) 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 D68195DE54 for ; Fri, 18 Oct 2002 12:06:00 -0400 (EDT) Received: from gwzw2k (rtp-vpn1-393.cisco.com [10.82.225.137]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA08953; Fri, 18 Oct 2002 09:05:12 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Yoshihiro Ohba" , Cc: , , , Subject: RE: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Date: Fri, 18 Oct 2002 09:05:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" 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: <20021017130432.GA1083@catfish> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] writes: ... > > > However, servers > > that do this MUST ensure that duplicates > are found even when > > the first transmitted request arrives at > the server after the > > retransmitted request. > > I think the above sentense can be moved to the Appendix. Or left out altogether...in the provision of the bit, we have enabled it's usage in any fashion desired. I would prefer that the details of this usage be specified in documents describing protocols that use it; the base Diameter protocol doesn't. From owner-aaa-wg@merit.edu Mon Oct 21 03:19: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 DAA20391 for ; Mon, 21 Oct 2002 03:19:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 833A191213; Mon, 21 Oct 2002 03:21:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 40C2B9121A; Mon, 21 Oct 2002 03:21:06 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 245A691213 for ; Mon, 21 Oct 2002 03:21:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3DC05DF85; Mon, 21 Oct 2002 03:21:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 449DF5DEEF for ; Mon, 21 Oct 2002 03:21:04 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9L7L9H19018 for ; Mon, 21 Oct 2002 10:21:09 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 21 Oct 2002 10:21:02 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 10:21:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: [AAA-WG]: Issue 372, where we stand Date: Mon, 21 Oct 2002 10:21:02 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58E4@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Thread-Index: AcJ2zROZJ/9gxWbPS9Gp7PKRZIF4mwCBNwKg From: To: X-OriginalArrivalTime: 21 Oct 2002 07:21:02.0879 (UTC) FILETIME=[698822F0:01C278D2] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, After some mail exchanges, I've adjusted the text to state the following. Please let me know if this is OK, as I would like to get the draft submitted. thanks, John Change chapter 3 as follow 3 Diameter Header A summary of the Diameter header format is shown below. The fields are transmitted in network byte order. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R P E T r r r r| Command-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Application-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hop-by-Hop Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | End-to-End Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVPs ... +-+-+-+-+-+-+-+-+-+-+-+-+- Version This Version field MUST be set to 1 to indicate Diameter Version 1. Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields. Command Flags The Command Flags field is eight bits. The following bits are assigned: R(equest) - If set, the message is a request. If cleared, the message is an answer. P(roxiable) - If set, the message MAY be proxied, relayed or redirected. If cleared, the message MUST be locally processed. 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 are commonly referred to as error messages. This bit MUST NOT be set in request messages. See section 7.2. T(Potentialy re-transmitted message) This flag is defined only for request messages sent by Diameter clients or agents. This flag is used as an indication of an application layer retransmission event, e.g. due to failover to an alternate server. If a Diameter client or agent knows that it is sending this request or accounting record contained in the request for the first time, it MUST reset this flag. Diameter agents only need to be concerned about the number of requests they send based on a single received request; retransmissions by other entities need not be tracked. However, Diameter agents that receive a request with the T flag set, MUST keep the T flag set in the forwarded request. If request is either known to be a retransmission or the Diameter client or agent is unable to assure that it is the first such request, it MUST set this flag. For instance, after a reboot, a client may not know whether it has already tried to send the accounting records in its non-volatile memory before the reboot occurred. Diameter servers MAY use the T flag as an aid when processing requests and detecting duplicate messages. However, servers that do this MUST ensure that duplicates are found even when the first transmitted request arrives at the server after the retransmitted request. This flag MUST NOT be set if an error answer message (e.g. a protocol error) has been received for an earlier message. It can be used only in cases where no answer has been received from the Server for a request and the request is sent again, (e.g. due to a failover to an alternate peer, due to a recovered primary peer or due to a client re-sending a stored record from non-volatile memory such as after reboot of a client or agent).This flag MUST NOT be set in answer messages. 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. 5.5.4 Failover and Failback Procedures Change the paragraph When a transport failure is detected, all messages in the queue are sent to an alternate agent, if possible. .....etc.. to When a transport failure is detected, if possible all messages in the queue are sent to an alternate agent with the T flag set. On booting a Diameter client or agent, the T flag is also set on any records still remaining to be transmitted in non-volatile storage. Change appendix C as follows: Appendix C. Duplicate Detection As described in section 9.4, accounting record duplicate detection is based on session identifiers. Duplicates can appear for various reasons: - Failover to an alternate server. Where close to real-time performance is required, failover thresholds need to be kept low and this may lead to an increased likelihood of duplicates. Failover can occur at the client or within Diameter agents. - Failure of a client or agent after sending of a record from non-volatile memory, but prior to receipt of an application layer ACK and deletion of the record to be sent. This will result in retransmission of the record soon after the client or agent has rebooted. - Duplicates received from RADIUS gateways. Since the retransmission behavior of RADIUS is not defined within [RFC2865], the likelihood of duplication will vary according to the implementation. - 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 included User-Name and duplicate elimination is easy in this case. In other situations it may be necessary to perform real-time duplicate detection, such as when credit limits are imposed or real-time fraud detection is desired. In general, only generation of duplicates due to failover or re-sending of records in non-volatile storage can be reliably detected by Diameter clients or agents. In such cases the Diameter client or agents can mark the message as possible duplicate by setting the T flag. Since the Diameter server is responsible for duplicate detection, it can choose to make use of the T flag or not, in order to optimize duplicate detection. Since the T flag does not affect interoperability, and may not be needed by some servers, generation of the T flag is REQUIRED for Diameter clients and agents, but MAY be implemented by Diameter servers. As an example, it can be usually be assumed that duplicates appear within a time window of longest recorded network partition or device fault, perhaps a day. So only records within this time window need to be looked at in the backward direction. Secondly, hashing techniques or other schemes, such as the use of the T flag in the received messages, may be used to eliminate the need to do a full search even in this set except for rare cases. The following is an example of how the T flag may be used by the server to detect duplicate requests. A Diameter server MAY check the T flag of the received message to determine if the record is a possible duplicate. If the T flag is set in the request message, the server searches for a duplicate within a configurable duplication time window backward and forward. This limits database searching to those records where the T flag is set. In a well-run network, network partitions and device faults will presumably be rare events, so this approach represents a substantial optimization of the duplicate detection process. During failover, it is possible for the original record to be received after the T flag marked record, due to differences in network delays experienced along the path by the original and duplicate transmissions. The likelihood of this occurring increase as the failover interval is decreased. In order to be able to detect out of order duplicates, the Diameter server should use backward and forward time windows when performing duplicate checking for the T flag marke! d request. For example, in order to allow time for the original record to exit the network and be recorded by the accounting server, the Diameter server can delay processing records with the T flag set until a time period TIME_WAIT + RECORD_PROCESSING_TIME has elapsed after the closing of the original transport connection. After this time period has expired, then it may check the T flag marked records against the database with relative assurance that the original records, if sent, have been received and recorded. From owner-aaa-wg@merit.edu Mon Oct 21 03:34: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 DAA20655 for ; Mon, 21 Oct 2002 03:34:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2674A9121E; Mon, 21 Oct 2002 03:36:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F08D49121F; Mon, 21 Oct 2002 03:36:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D00679121E for ; Mon, 21 Oct 2002 03:36:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA4455DF6C; Mon, 21 Oct 2002 03:36:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from shardagate.mahindrabt.com (shardagate.mahindrabt.com [203.124.158.2]) by segue.merit.edu (Postfix) with ESMTP id A334C5DEEF for ; Mon, 21 Oct 2002 03:36:07 -0400 (EDT) Received: from thisdomain (mailscan.sharda.mahindrabt.com [10.5.0.97]) by shardagate.mahindrabt.com (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA04800 for ; Mon, 21 Oct 2002 13:06:01 +0530 Received: from intranet.sharda.mahindrabt.com by mahindrabt.com ; Mon, 21 Oct 2002 12:57:42 +0530 Date: Mon, 21 Oct 2002 12:57:42 +0530 X-Originating-IP: 10.5.0.15 X-Auth-User: ninadj@mahindrabt.com Received: from MahindraBT.com ([10.5.12.200]) by intranet.sharda.mahindrabt.com (8.9.3/8.9.3) with ESMTP id NAA08225 for ; Mon, 21 Oct 2002 13:05:54 +0530 Message-ID: <3DB3AEA9.A2805BAD@MahindraBT.com> Date: Mon, 21 Oct 2002 13:07:13 +0530 From: Ninad Jadhav X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Roles of a Diameter Node Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a very basic question. As I understand, a Diameter Node can act either as a Client, Agent, Server, or Agent + Server. Is there any other combination of roles, possible? Regards - Ninad Jadhav ********************************************************* Disclaimer This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. ********************************************************* Visit us at http://www.mahindrabt.com From owner-aaa-wg@merit.edu Mon Oct 21 03:56: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 DAA20999 for ; Mon, 21 Oct 2002 03:56:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E5F49121F; Mon, 21 Oct 2002 03:58:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9FB391220; Mon, 21 Oct 2002 03:58:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD0B19121F for ; Mon, 21 Oct 2002 03:58:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 94A935DF2D; Mon, 21 Oct 2002 03:58:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by segue.merit.edu (Postfix) with ESMTP id D7E5A5DF6C for ; Mon, 21 Oct 2002 03:58:11 -0400 (EDT) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9L7vpw01973 for ; Mon, 21 Oct 2002 10:57:51 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 21 Oct 2002 10:58:10 +0300 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 10:58:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Issue 372, where we stand Date: Mon, 21 Oct 2002 10:58:10 +0300 Message-ID: <142DC466081D9B409AAD1DDCA4B21E1D9E43A8@esebe016.ntc.nokia.com> Thread-Topic: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Thread-Index: AcJ2zROZJ/9gxWbPS9Gp7PKRZIF4mwCBNwKgAAD/1WA= From: To: Cc: X-OriginalArrivalTime: 21 Oct 2002 07:58:10.0828 (UTC) FILETIME=[997E2CC0:01C278D7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, sounds OK. However, I think it is still better to change the sentence of T-flag description as suggested by Glen Zorn to avoid wrong interpretation. " This flag MUST NOT be set if the error answer message (e.g. a protocol error) has been received for the earlier message." Glen Zorn wrote: > This flag MUST NOT be set if an error answer message > (about e.g. a protocol error) has been received for an > previous message. >Change "an" to "the", I think; otherwise, this could be interpreted as "if a >protocol error ever happens, never set the 'T' bit again" Br Marco > -----Original Message----- > From: ext [mailto:john.loughney@nokia.com] > Sent: 21. October 2002 10:21 > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Issue 372, where we stand > > > Hi all, > > After some mail exchanges, I've adjusted the text to state > the following. > Please let me know if this is OK, as I would like to get the > draft submitted. > > thanks, > John > > Change chapter 3 as follow > > 3 Diameter Header > > A summary of the Diameter header format is shown below. The > fields are transmitted in network byte order. > > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Ver | Message Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |R P E T r r r r| Command-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Application-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hop-by-Hop Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | End-to-End Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AVPs ... > +-+-+-+-+-+-+-+-+-+-+-+-+- > > Version > This Version field MUST be set to 1 to indicate Diameter Version 1. > > Message Length > The Message Length field is three octets and indicates the > length of the Diameter message including the header fields. > > Command Flags > The Command Flags field is eight bits. The following bits are > assigned: > > > R(equest) - If set, the message is a request. If cleared, the > message is an answer. > > P(roxiable) - If set, the message MAY be proxied, relayed or > redirected. If cleared, the message MUST be locally processed. > > 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 are commonly referred > to as error messages. This bit MUST NOT be set in request > messages. See section 7.2. > > T(Potentialy re-transmitted message) > This flag is defined only for request messages sent by > Diameter clients or agents. This flag is used as an > indication of an application layer retransmission event, e.g. > due to failover to an alternate server. > > If a Diameter client or agent knows that it is sending this > request or accounting record contained in the request for the > first time, it MUST reset this flag. Diameter agents only > need to be concerned about the number of requests they send > based on a single received request; retransmissions by other > entities need not be tracked. However, Diameter agents that > receive a request with the T flag set, MUST keep the T flag > set in the forwarded request. > > If request is either known to be a retransmission or the > Diameter client or agent is unable to assure that it is the > first such request, it MUST set this flag. For instance, > after a reboot, a client may not know whether it has already > tried to send the accounting records in its non-volatile > memory before the reboot occurred. > > Diameter servers MAY use the T flag as an aid when processing > requests and detecting duplicate messages. However, servers > that do this MUST ensure that duplicates are found even when > the first transmitted request arrives at the server after the > retransmitted request. > > This flag MUST NOT be set if an error answer message (e.g. a > protocol error) has been received for an earlier message. It > can be used only in cases where no answer has been received > from the Server for a request and the request is sent again, > (e.g. due to a failover to an alternate peer, due to a > recovered primary peer or due to a client re-sending a stored > record from non-volatile memory such as after reboot of a > client or agent).This flag MUST NOT be set in answer messages. > > 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. > > 5.5.4 Failover and Failback Procedures > > Change the paragraph > > When a transport failure is detected, all messages in the queue are > sent to an alternate agent, if possible. > .....etc.. > > to > > When a transport failure is detected, if possible all > messages in the queue are sent to an alternate agent with the > T flag set. On booting a Diameter client or agent, the T flag > is also set on any records still remaining to be transmitted > in non-volatile storage. > > > Change appendix C as follows: > > Appendix C. Duplicate Detection > > As described in section 9.4, accounting record duplicate > detection is based on session identifiers. Duplicates can > appear for various reasons: > > - Failover to an alternate server. Where close to real-time > performance is required, failover thresholds need to be kept > low and this may lead to an increased likelihood of > duplicates. Failover can occur at the client or within > Diameter agents. > > - Failure of a client or agent after sending of a record from > non-volatile memory, but prior to receipt of an application > layer ACK and deletion of the record to be sent. This will > result in retransmission of the record soon after the client > or agent has rebooted. > > - Duplicates received from RADIUS gateways. Since the > retransmission behavior of RADIUS is not defined within > [RFC2865], the likelihood of duplication will vary according > to the implementation. > > - 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 included User-Name and > duplicate elimination is easy in this case. > > In other situations it may be necessary to perform real-time > duplicate detection, such as when credit limits are imposed > or real-time fraud detection is desired. > > In general, only generation of duplicates due to failover or > re-sending of records in non-volatile storage can be reliably > detected by Diameter clients or agents. In such cases the > Diameter client or agents can mark the message as possible > duplicate by setting the T flag. Since the Diameter server is > responsible for duplicate detection, it can choose to make > use of the T flag or not, in order to optimize duplicate > detection. Since the T flag does not affect interoperability, > and may not be needed by some servers, generation of the T > flag is REQUIRED for Diameter clients and agents, but MAY be > implemented by Diameter servers. > > As an example, it can be usually be assumed that duplicates > appear within a time window of longest recorded network > partition or device fault, perhaps a day. So only records > within this time window need to be looked at in the backward > direction. Secondly, hashing techniques or other schemes, > such as the use of the T flag in the received messages, may > be used to eliminate the need to do a full search even in > this set except for rare cases. > > The following is an example of how the T flag may be used by > the server to detect duplicate requests. > > A Diameter server MAY check the T flag of the received > message to determine if the record is a possible duplicate. > If the T flag is set in the request message, the server > searches for a duplicate within a configurable duplication > time window backward and forward. This limits database > searching to those records where the T flag is set. In a > well-run network, network partitions and device faults will > presumably be rare events, so this approach represents a > substantial optimization of the duplicate detection process. > During failover, it is possible for the original record to be > received after the T flag marked record, due to differences > in network delays experienced along the path by the original > and duplicate transmissions. The likelihood of this occurring > increase as the failover interval is decreased. In order to > be able to detect out of order duplicates, the Diameter > server should use backward and forward time windows when > performing duplicate checking for the T flag marke! > d request. For example, in order to allow time for the > original record to exit the network and be recorded by the > accounting server, the Diameter server can delay processing > records with the T flag set until a time period TIME_WAIT + > RECORD_PROCESSING_TIME has elapsed after the closing of the > original transport connection. After this time period has > expired, then it may check the T flag marked records against > the database with relative assurance that the original > records, if sent, have been received and recorded. > From owner-aaa-wg@merit.edu Mon Oct 21 03:59: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 DAA21106 for ; Mon, 21 Oct 2002 03:59:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56D8F91220; Mon, 21 Oct 2002 04:01:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1677A91221; Mon, 21 Oct 2002 04:01:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B18AC91220 for ; Mon, 21 Oct 2002 04:01:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7E4785DF2D; Mon, 21 Oct 2002 04:00:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id B464D5DEC7 for ; Mon, 21 Oct 2002 04:00:57 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9L813H00673 for ; Mon, 21 Oct 2002 11:01:03 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 21 Oct 2002 11:00:56 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 11:00:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [AAA-WG]: Issue 372, where we stand Date: Mon, 21 Oct 2002 11:00:56 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58E7@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Resolution of issue 372 - proposed text (full set) Thread-Index: AcJ2zROZJ/9gxWbPS9Gp7PKRZIF4mwCBNwKgAAD/1WAAAICzgA== From: To: Cc: X-OriginalArrivalTime: 21 Oct 2002 08:00:56.0708 (UTC) FILETIME=[FC5D7440:01C278D7] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Marco, Glenn, > Hi, > > sounds OK. > > However, I think it is still better to change the sentence > of T-flag description as suggested by Glen Zorn to avoid > wrong interpretation. > > " This flag MUST NOT be set if the error answer message (e.g. > a protocol error) has been received for the earlier message." > > Glen Zorn wrote: > > > This flag MUST NOT be set if an error answer message > > (about e.g. a protocol error) has been received for an > > previous message. > > >Change "an" to "the", I think; otherwise, this could be > interpreted as "if a > >protocol error ever happens, never set the 'T' bit again" Good catch, I will make the change. John From owner-aaa-wg@merit.edu Mon Oct 21 09:25: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 JAA27644 for ; Mon, 21 Oct 2002 09:25:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6500591224; Mon, 21 Oct 2002 09:27:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2EAE691226; Mon, 21 Oct 2002 09:27:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30C4291224 for ; Mon, 21 Oct 2002 09:27:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1914E5DEF7; Mon, 21 Oct 2002 09:27:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 9CC9E5DFB3 for ; Mon, 21 Oct 2002 09:27:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9LCP5l32691; Mon, 21 Oct 2002 05:25:05 -0700 Date: Mon, 21 Oct 2002 05:25:05 -0700 (PDT) From: Bernard Aboba To: john.loughney@nokia.com Cc: marco.stura@nokia.com, Subject: RE: [AAA-WG]: Issue 372, where we stand In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF015A58E7@esebe004.ntc.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > > > This flag MUST NOT be set if an error answer message > > > (about e.g. a protocol error) has been received for an > > > previous message. > > > > >Change "an" to "the", I think; otherwise, this could be > > interpreted as "if a > > >protocol error ever happens, never set the 'T' bit again" > > Good catch, I will make the change. Actually, what I think was intended was: This flag MUST NOT be set if an error answer message (e.g. a protocol error) has been received for the earlier message. From owner-aaa-wg@merit.edu Mon Oct 21 10:09: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 KAA29331 for ; Mon, 21 Oct 2002 10:09:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28FE091226; Mon, 21 Oct 2002 10:11:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EF06E91229; Mon, 21 Oct 2002 10:11:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCB8091226 for ; Mon, 21 Oct 2002 10:11:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB6BE5DFB7; Mon, 21 Oct 2002 10:11:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by segue.merit.edu (Postfix) with ESMTP id 1DF0F5DFA4 for ; Mon, 21 Oct 2002 10:11:18 -0400 (EDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g9LEBNH00512 for ; Mon, 21 Oct 2002 17:11:23 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 21 Oct 2002 17:11:16 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 21 Oct 2002 17:11:16 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [AAA-WG]: Issue 372, where we stand Date: Mon, 21 Oct 2002 17:11:15 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF015A5902@esebe004.ntc.nokia.com> Thread-Topic: [AAA-WG]: Issue 372, where we stand Thread-Index: AcJ5BdDk5oef9hCYRDqKSSzJAZfCJwABeBDg From: To: Cc: , X-OriginalArrivalTime: 21 Oct 2002 14:11:16.0595 (UTC) FILETIME=[B8732430:01C2790B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA29331 > Actually, what I think was intended was: > > This flag MUST NOT be set if an error answer message > (e.g. a protocol error) has been received for the earlier > message. Got it. John From owner-aaa-wg@merit.edu Mon Oct 21 17:41: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 RAA16399 for ; Mon, 21 Oct 2002 17:41:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C3B191241; Mon, 21 Oct 2002 17:43:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3BF1691242; Mon, 21 Oct 2002 17:43:21 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4635C91241 for ; Mon, 21 Oct 2002 17:43:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2FA975DFBD; Mon, 21 Oct 2002 17:43:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 95E8A5DF67 for ; Mon, 21 Oct 2002 17:43:19 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9LKfF704669 for ; Mon, 21 Oct 2002 13:41:15 -0700 Date: Mon, 21 Oct 2002 13:41:15 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 375: Command code allocations for 3GPP Release 5 and 6 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 375: Command code allocations for 3GPP Release 5 and 6 Submitter name: Thomas Narten Submitter email address: narten@us.ibm.com Date first submitted: October 21, 2002 Reference: Document: Base Comment type: T Priority: S Section: 11.2.1 Rationale/Explanation of issue Section 11 of the Diameter Base document uses the term "experimental" in a confusing way, since "experimental codes" have a different meaning per draft-narten-iana-experimental. For example, experimental codes are not for permanent use, and revoking the allocation after a year is not likely to satisfy 3GPP/3GPP2. Resolution (discussed by IESG, AAA editors, 3GPP): Allocate permanent command codes to 3GPP Release 5 via a separate document: http://www-nrc.nokia.com/sua/draft-loughney-aaa-cc-3gpp-00.txt Command codes for 3GPP Release 6 to be allocated from the standard command space, with IETF documentation. The current intent as agreed with 3GPP is to develop a standards track application addressing the needs of AAA for SIP/SDP and encompassing the requirements of the cellular community. Change Section 11.2.1 as described in http://www-nrc.nokia.com/sua/draft-ietf-aaa-diameter-15.txt : (changes highlighted) 11.2.1 Command Codes The Command Code namespace is used to identify Diameter commands. The values 0-255 are reserved for RADIUS backward compatibility, and are defined as "RADIUS Packet Type Codes" in [RADTYPE]. Values 256-16,777,213 are for permanent, standard commands, allocated by IETF Consensus [IANA]. This document defines the Command Codes 257, 258, 271, 274-275, 280 and 282. See section 3.1 for the assignment of the namespace in this specification. ---> 2 experimental command codes. The values 16,777,214 and 16,777,215 (hexidecimal values FFFFFE - FFFFFF) are reserved for experimental commands. As these codes are only for experimental and testing purposes, no guarantee is made for interoperability between Diameter peers using experimental commands, as outlined in [IANA-EXP]. From owner-aaa-wg@merit.edu Mon Oct 21 19:44: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 TAA19405 for ; Mon, 21 Oct 2002 19:44:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A24891237; Mon, 21 Oct 2002 19:46:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3FE2B9124B; Mon, 21 Oct 2002 19:46:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 446EE91237 for ; Mon, 21 Oct 2002 19:46:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18DD75DF53; Mon, 21 Oct 2002 19:46:30 -0400 (EDT) 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 B6D7A5DE30 for ; Mon, 21 Oct 2002 19:46:29 -0400 (EDT) Received: from gwzw2k (rtp-vpn2-991.cisco.com [10.82.243.223]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA16514; Mon, 21 Oct 2002 16:46:19 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , Cc: , Subject: RE: [AAA-WG]: Issue 372, where we stand Date: Mon, 21 Oct 2002 16:46:18 -0700 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.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > This flag MUST NOT be set if an error answer message > > > > (about e.g. a protocol error) has been received for an > > > > previous message. > > > > > > >Change "an" to "the", I think; otherwise, this could be > > > interpreted as "if a > > > >protocol error ever happens, never set the 'T' bit again" > > > > Good catch, I will make the change. > > Actually, what I think was intended was: > > This flag MUST NOT be set if an error answer message > (e.g. a protocol error) has been received for the earlier > message. Yup. From owner-aaa-wg@merit.edu Tue Oct 22 11: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 LAA21491 for ; Tue, 22 Oct 2002 11:18:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16CEF9122E; Tue, 22 Oct 2002 11:20:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAE7391230; Tue, 22 Oct 2002 11:20:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 071A89122E for ; Tue, 22 Oct 2002 11:20:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7A715DDF0; Tue, 22 Oct 2002 11:20:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 5F6275DDD0 for ; Tue, 22 Oct 2002 11:20:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9MEI8k14810 for ; Tue, 22 Oct 2002 07:18:08 -0700 Date: Tue, 22 Oct 2002 07:18:08 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Strawman agenda for IETF 55 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Here is a strawman agenda for the AAA WG meeting at IETF 55. Additions/deletions/comments welcome. Authentication, Authorization and Accounting WG (AAA) IETF 55, Atlanta, GA Wednesday, November 20 1300 - 1500 CHAIRS: Bernard Aboba David Mitton AGENDA Preliminaries (5 minutes) Bluesheets and Minutes Document Status Interoperability/bakeoff report IETF last call Diameter Base, John Loughney (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-14.txt Diameter transport, Bernard Aboba (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-08.txt Diameter MIP, Tony Johansson (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-13.txt AAA WG last call Diameter NASREQ, David Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-09.txt Work in progress Diameter CMS Security, Stephen Farrell (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-04.txt Diameter EAP, Tom Hiller & Glen Zorn (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-eap-00.txt AAA key distribution, Jesse Walker (10 minutes) http://www.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00.txt Predictive authentication support in AAA, S. Pac, Y. Choi (15 minutes) http://mmlab.snu.ac.kr/research/publication/docs/pwc2002_shpack.pdf http://mmlab.snu.ac.kr/research/publication/docs/Networks2002_shpack.pdf Individual submissions Diameter API, J. Kempf (5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-api-02.txt Diameter C++ API, Y. Ohba (5 minutes) http://www.ietf.org/internet-drafts/draft-ohba-aaa-diameter-cxxapi-00.txt Diameter Credit Control Application, Harri Hakala (5 minutes) http://www.ietf.org/internet-drafts/draft-hakala-diameter-credit-control-04.txt Diameter Mobile IPv6 Application, Franck Le (5 minutes) http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-02.txt Localized Key Management for AAA in MIPv6, M. Kim (5 minutes) http://www.ietf.org/internet-drafts/draft-mun-aaa-localkm-mobileipv6-00.txt From owner-aaa-wg@merit.edu Tue Oct 22 13:37: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 NAA27617 for ; Tue, 22 Oct 2002 13:37:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC34991232; Tue, 22 Oct 2002 13:39:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8231291239; Tue, 22 Oct 2002 13:39:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A299991232 for ; Tue, 22 Oct 2002 13:39:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 823675DDAB; Tue, 22 Oct 2002 13:39:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 10ADC5DDA7 for ; Tue, 22 Oct 2002 13:39:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9MGbCt16006; Tue, 22 Oct 2002 09:37:12 -0700 Date: Tue, 22 Oct 2002 09:37:12 -0700 (PDT) From: Bernard Aboba To: iesg@ietf.org Cc: aaa-wg@merit.edu, Subject: [AAA-WG]: Request for IETF Last call on draft-ietf-aaa-diameter-15.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The AAA WG has now completed working group last call on the Diameter Base Protocol with 18 comments: Issues 352, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 369, 370, 371, 372, 373, 375 Comments received during this and previous AAA WG last calls are available for inspection at: http://www.drizzle.com/~aboba/AAA/issues.html The latest version of the document submitted to the IETF archive is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt As a result, the AAA WG recommends that the IESG begin IETF last call on this document, in order to consider it for adoption as an IETF Proposed Standard. From owner-aaa-wg@merit.edu Wed Oct 23 11:52: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 LAA20686 for ; Wed, 23 Oct 2002 11:52:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4A2019127F; Wed, 23 Oct 2002 11:54:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BED491280; Wed, 23 Oct 2002 11:54:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 241B59127F for ; Wed, 23 Oct 2002 11:54:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E1985DE20; Wed, 23 Oct 2002 11:54:29 -0400 (EDT) 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 730905DE12 for ; Wed, 23 Oct 2002 11:54:28 -0400 (EDT) Received: from gwzw2k (rtp-vpn2-355.cisco.com [10.82.241.99]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA23580; Wed, 23 Oct 2002 08:54:21 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" Cc: Subject: RE: [AAA-WG]: [issue 353] Issues with EAP-00 draft Date: Wed, 23 Oct 2002 08:54:19 -0700 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.4910.0300 Importance: Normal Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > > Not sure I follow your reasoning. Are you saying that > typical behavior is > > also optimal? This assertion seems a bit absurd :-)... > > I'm just wondering which behavior the draft is advocating, and why. I believe from the text that it is advocating the "preferred" approach. > > > Indeed! In fact, it looks to me like the "typical" > approach, far from being > > either optimal or even "preferred" is actually pretty > useless: it seems to > > waste bandwidth to no good purpose, since the empty request > cannot be routed > > to the home realm... > > However, if there is no proxy, then it could conceivably be > useful. For > example, the RADIUS server could decide to dispense with an > EAP Identity > exchange altogether and go immediately to an identity-hiding > method (EAP > TTLS or PEAP). > > > I would prefer :-) to delete or deprecate the first approach. > > Perhaps the right thing to do is to indicate that the second > approach is > preferred, except in special cases where the first approach > MAY be used. > > > > You might give an example of a situation where this would occur. > > > > Can you think of one? > > The case that comes to mind is use of Session-Timeout to indicate > the desired timeout period for the NAS, before resending the > EAP Request. > > > > > Since > > > there is controversy about this AVP, including it in NASREQ > > > would prevent > > > that document from advancing. > > > > The major controversy I recall was from Paul Funk, who > hasn't followed up > > AFAIK, even as far as answering my question as to why the > current AVPs do > > not suffice to do exactly what he wants. Are there other > complaints? > > Yes, see Issue #294. I view Issue #294 as essentially baseless. > > > > From owner-aaa-wg@merit.edu Wed Oct 23 14: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 OAA29796 for ; Wed, 23 Oct 2002 14:55:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E9069128B; Wed, 23 Oct 2002 14:56:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25AF291294; Wed, 23 Oct 2002 14:56:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0F8049128B for ; Wed, 23 Oct 2002 14:56:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEA7A5DE2F; Wed, 23 Oct 2002 14:56:38 -0400 (EDT) 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 8D79D5DE12 for ; Wed, 23 Oct 2002 14:56:38 -0400 (EDT) Received: from gwzw2k (sjc-vpn1-375.cisco.com [10.21.97.119]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA20598; Wed, 23 Oct 2002 11:56:22 -0700 (PDT) Reply-To: From: "Glen Zorn" To: "Bernard" Cc: "AAA WG" Subject: [AAA-WG]: Issue 353 Date: Wed, 23 Oct 2002 11:56:21 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 2 of draft-ietf-aaa-eap-00.txt says: 2. Extensible Authentication Protocol Support in Diameter The Extensible Authentication Protocol (EAP) [RFC2284] provides a standard mechanism for support of various authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart and token cards, Kerberos [RFC1510], public-key, one-time passwords [RFC1938], and others. This document describes the Command-Code values and AVPs that are required for an EAP packet to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility for fraudulent authentication, such as replay and man-in-the-middle attacks. End-to-end authentication also provides for mutual (bi-directional) authentication, which is not possible with PAP and CHAP in a roaming PPP environment. Issue 353 says (in part): Page 2, section 2, last sentence: Change "with PAP and CHAP in a roaming PPP environment." to "with PAP, CHAP or EAP-MD5." The problem is that mutual authentication _is_ possible in a roaming PPP environment using PAP, CHAP or EAP-MD5, under certain constraint which may be inconvenient, but it is possible. To avoid endless discussions of PPP minutiae, I suggest the following text: 2. Extensible Authentication Protocol Support in Diameter The Extensible Authentication Protocol (EAP) [RFC2284] provides a standard mechanism for support of various authentication methods. Through the use of EAP, support for a number of authentication schemes may be added, including smart and token cards, Kerberos [RFC1510], public-key, one-time passwords [RFC1938], and others. This document describes the Command-Code values and AVPs that are required for an EAP packet to be encapsulated within the Diameter protocol. Since authentication occurs between the EAP client and its home Diameter server, end-to-end authentication is achieved, reducing the possibility of replay and man-in-the-middle attacks and simplifying the satisfaction of requirements for mutual authentication in roaming environments. From owner-aaa-wg@merit.edu Sat Oct 26 00:53: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 AAA21713 for ; Sat, 26 Oct 2002 00:53:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17AE491211; Sat, 26 Oct 2002 00:55:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFB669131D; Sat, 26 Oct 2002 00:55:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F03F891211 for ; Sat, 26 Oct 2002 00:55:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEDA25DF2D; Sat, 26 Oct 2002 00:55:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 554E25DECB for ; Sat, 26 Oct 2002 00:55:23 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g9Q3qub28162 for ; Fri, 25 Oct 2002 20:52:56 -0700 Date: Fri, 25 Oct 2002 20:52:56 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 376: Base-15 Nits Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Issue 376: Base-15 Nits Submitter name: David Mitton Submitter email address: david@mitton.com Date first submitted: October 23, 2002 Reference: Document: Base-15 Comment type: E Priority: 1 Section: Several Rationale/Explanation of issue: - "Acct-Interim-Interval" has lower case "interim" in two places - "Accounting-RADIUS-Session-Id" (44) is a really silly name change. I have a line in NASREQ now that says basically insert the value of attribute 44, into AVP 44 with a different name. Eg, no value change. The RADIUS attribute 44 as defined in RFC 2866 is "Acct-Session-Id" and we have not changed the semantics (just added behaviors to some other AVPs elsewhere) Can we just revert to the old name? it does not conflict. In general, I would think that all RFC 2866 accounting attributes keep their Acct-* names, and any new Diameter Accounting AVPs are named Accounting-* This has been true except for this case and Acct-Application-Id (259) {I guess because it pairs well with Auth-Application-Id (258)} which really doesn't offer a dictionary conflict. Dave. From owner-aaa-wg@merit.edu Tue Oct 29 02:12: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 CAA22913 for ; Tue, 29 Oct 2002 02:12:25 -0500 (EST) Received: by trapdoor.merit.edu (Postfix) id 8A6179124A; Tue, 29 Oct 2002 02:14:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A0179124C; Tue, 29 Oct 2002 02:14: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 501219124A for ; Tue, 29 Oct 2002 02:14:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 32C4F5DE3A; Tue, 29 Oct 2002 02:14:32 -0500 (EST) Delivered-To: aaa-wg@merit.edu Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by segue.merit.edu (Postfix) with ESMTP id BD4465DDF8 for ; Tue, 29 Oct 2002 02:14:31 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g9T7EUKV007937 for ; Tue, 29 Oct 2002 08:14:30 +0100 (MET) Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 29 Oct 2002 08:14:30 +0100 Message-ID: <9505F6390AA7D311A2D500508B951BEF0C1306CD@esealnt427> From: "Mikael Jakobsson (EAB)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Some editorial nits in base-15 Date: Tue, 29 Oct 2002 08:14:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, found some editorial nits while reading through draft 15 of diameter base. 2.8.3 Redirect Agents First paragraph states "Since Redirect agents do not perform any application level processing, the provide services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier." which is the same as last paragraph (except for spelling error in the first one) "Since Redirect agents do not perform any application level processing, they provide relaying services for all Diameter applications, and therefore MUST advertise the Relay Application Identifier." Suggestion is to remove the first one. 8.6 Inferring Session Termination from Origin-State-Id Correct CER/CAA to CER/CEA in the following paragraph (the second one). "By including Origin-State-Id in CER/CAA messages, an access device allows a next-hop server to determine immediately upon connection whether the device has lost its sessions since the last connection." 11.3 Application Identifiers Second paragraph states 0xff00000000 - 0xfffffffe for vendor specific applications. There are too many zeros in 0xff00000000 so correct to 0xff000000 - 0xff000000. "IANA [IANA] will assign the range 0x00000001 to 0x00ffffff for standards-track applications; and 0xff00000000 - 0xfffffffe for vendor specific applications, on a first-come, first-served basis. Assignment of standards-track application IDs are by Designated Expert with Specification Required [IANA]." 11.4.1 Result-Code AVP Values Correct value ranges for result codes from "As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4002 and 5001-5017." to "As defined in Section 7.1, the Result-Code AVP (AVP Code 268) defines the values 1001, 2001-2002, 3001-3010, 4001-4003 and 5001-5016." Best Regards Mikael Jakobsson ----------------------------------------- Mikael Jakobsson Ericsson AB Core Unit Service Network & Applications Tel: +46 455 39 52 81 Fax: +46 455 815 10 Mobile: +46 703 10 52 81 mailto:Mikael.Jakobsson@epk.ericsson.se http://www.ericsson.com