From owner-aaa-bof@merit.edu Thu Mar 1 00:42:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12205 for ; Thu, 1 Mar 2001 00:42:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 538005DD8D; Thu, 1 Mar 2001 00:42:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 356675DD94; Thu, 1 Mar 2001 00:42:36 -0500 (EST) Received: from fep08.tmt.tele.fi (hank-fep8-0.inet.fi [194.251.242.203]) by segue.merit.edu (Postfix) with ESMTP id ABFA75DD8D for ; Thu, 1 Mar 2001 00:42:34 -0500 (EST) Received: from kolumbus.fi ([195.156.180.181]) by fep08.tmt.tele.fi (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20010301054231.LCMR502.fep08.tmt.tele.fi@kolumbus.fi>; Thu, 1 Mar 2001 07:42:31 +0200 Message-ID: <3A9DE1C8.2070705@kolumbus.fi> Date: Thu, 01 Mar 2001 07:44:40 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" Subject: Re: [AAA-WG]: Back to extensions... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > End-to-end security is mandatory to implement, it is not > mandatory to use. So if it is not needed, you don't have > to turn it on. > > Yes, but the mandatory-to-implement part *is* what I am worrying about! Along the same lines, I would also like to suggest that we can advance the base Diameter specs to an RFC status before the e2e parts. It is my understanding that the base protocol parts must be published _soon_ in order for them to be useful for various third generation mobile network standardization uses, and it would be unfortunate if the e2e work delayed this, given that at least in the beginning we may not need e2e there. [I believe e2e is very useful but not always, and it is my gut feeling that it will take some time to nail down the details of e2e, not to mention the picking of the solution among the competing ones.] Jari From owner-aaa-bof@merit.edu Thu Mar 1 00:49:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA12274 for ; Thu, 1 Mar 2001 00:49:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CEB45DDBC; Thu, 1 Mar 2001 00:45:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E26BD5DD94; Thu, 1 Mar 2001 00:45:09 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 619185DDBC for ; Thu, 1 Mar 2001 00:45:05 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f215bmC27114 for ; Wed, 28 Feb 2001 21:37:48 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Draft Agenda for IETF 50 Date: Wed, 28 Feb 2001 21:45:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is another shot at the agenda for IETF 50. If you have any items you'd like to get on the agenda, please send them to me or Dave. Authentication, Authorization and Accounting WG (AAA) ====================================================== CHAIRS: Bernard Aboba Dave Mitton AGENDA: Monday, March 19, 2001, 1930-2200 Minute Takers & Bluesheets Agenda Bashing Review of WG milestones (5 minutes) Review of Document Progress (5 minutes) Discussion of Interim Meeting decisions, Dave Mitton (5 minutes) DATA MODELLING SMIng and DIAMETER J. Schoenwaelder (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-sming-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-modules-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-inet-modules-00. http://www.ietf.org/internet-drafts/draft-schoenw-sming-diameter-00.txt AAA Data Modelling David Spence (30 minutes) http://www.ietf.org/internet-drafts/draft-spence-aaa-nas-data-model-00.txt http://www.ietf.org/internet-drafts/draft-spence-aaaarch-objmsg-00.txt DIAMETER Data Modelling proposal Erik Guttman (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-solutions-01.txt Data Modelling Discussion and wrapup (10 minutes) Friday, March 23, 2001, 9000 - 1130 TRANSPORT AAA transport profile Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-01.txt SECURITY AAA Security Overview Bernard Aboba (10 minutes) Kerberos for DIAMETER End-to-end security Kaushik Narayan (30 minutes) http://www.ietf.org/internet-drafts/draft-kaushik-radius-sec-ext-05.txt CMS for DIAMETER End-to-End security Stephen Farrell (30 minutes) http://www.ietf.org/internet-drafts/draft-calhoun-diameter-strong-crypto-06. txt PROXIES Proxies Dave Mitton (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-proxies-01.txt EXTENSION HANDLING Accounting integration Glen Zorn (10 minutes) Where do we go from here? (Chairs & ADs) RESEARCH UPDATE (5 minutes) John Vollbrecht From owner-aaa-bof@merit.edu Thu Mar 1 06:50:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29731 for ; Thu, 1 Mar 2001 06:50:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id D5FBF5DE56; Thu, 1 Mar 2001 06:48:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C0DD45DE9C; Thu, 1 Mar 2001 06:48:02 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 3E28D5DE56 for ; Thu, 1 Mar 2001 06:48:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11581; Thu, 1 Mar 2001 03:47:52 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18813; Thu, 1 Mar 2001 03:47:52 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id DAA18577; Thu, 1 Mar 2001 03:47:48 -0800 (PST) Date: Thu, 1 Mar 2001 03:43:26 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Back to extensions... To: Jari Arkko Cc: Bernard Aboba , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" <3A9DE1C8.2070705@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Yes, but the mandatory-to-implement part *is* what I am > worrying about! > > Along the same lines, I would also like to suggest that we can advance > the base Diameter specs to an RFC status before the e2e parts. It is > my understanding that the base protocol parts must be published _soon_ > in order for them to be useful for various third generation mobile > network standardization uses, and it would be unfortunate if the e2e > work delayed this, given that at least in the beginning we may not > need e2e there. > > [I believe e2e is very useful but not always, and it is > my gut feeling that it will take some time to nail down the details > of e2e, not to mention the picking of the solution among the competing > ones.] 3GPP2 has exactly the same concerns. They have expressed a desire for the e2e to NOT slow down progress of the base and other extensions down. PatC From owner-aaa-bof@merit.edu Thu Mar 1 09:35:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05223 for ; Thu, 1 Mar 2001 09:35:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id CC0785DE8D; Thu, 1 Mar 2001 09:32:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BAB7D5DE77; Thu, 1 Mar 2001 09:32:04 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id EBA6D5DE8B for ; Thu, 1 Mar 2001 09:32:02 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f21EObC23834; Thu, 1 Mar 2001 06:24:37 -0800 From: "Bernard Aboba" To: "Pat Calhoun" , "Jari Arkko" Cc: "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Back to extensions... Date: Thu, 1 Mar 2001 06:32:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > given that at least in the beginning we may not need e2e there. Can you describe why e2e may not be needed in the initial implementations of 3G? Looking at RFC 2989, it seems that the e2e requirements came out of the need to use AAA to distribute keys, tunnel passwords, and user passwords. RFC 2607 describes the security problems that result from using RADIUS to carry out these and other functions. Are you saying that the initial implementations of 3G will not use AAA for key distribution, tunnel passwords or PAP? If this were the case, and in addition, "routing brokers" were used (e.g. proxies don't modify attributes), then I'd agree that e2e security might not be required in such a situation. >3GPP2 has exactly the same concerns. They have expressed a desire for the e2e >to NOT slow down progress of the base and other extensions down. If the question is whether the base spec can proceed as long as it has the required functionality to support e2e, whether the e2e spec is completely done, I think the answer to that is "yes". From owner-aaa-bof@merit.edu Fri Mar 2 04:21:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24237 for ; Fri, 2 Mar 2001 04:21:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E53D5DE65; Fri, 2 Mar 2001 04:17:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F1A55DD92; Fri, 2 Mar 2001 04:17:59 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 9240B5DDBA for ; Fri, 2 Mar 2001 04:17:52 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f229Hmd28292 for ; Fri, 2 Mar 2001 10:17:48 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 02 10:17:35 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 2 Mar 2001 10:17:34 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEDF@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: TLS or SSL? Date: Fri, 2 Mar 2001 10:17:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Is it decided which one between SSL3.0 and TLS1.0 will be required by the Base document? Regards, Martin From owner-aaa-bof@merit.edu Fri Mar 2 10:40:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03616 for ; Fri, 2 Mar 2001 10:40:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 94CC05DEDD; Fri, 2 Mar 2001 10:36:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 837FC5DED3; Fri, 2 Mar 2001 10:36:48 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 258005DEC4 for ; Fri, 2 Mar 2001 10:36:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26830 for ; Fri, 2 Mar 2001 07:36:46 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20154; Fri, 2 Mar 2001 07:36:45 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA07621; Fri, 2 Mar 2001 07:36:43 -0800 (PST) Date: Fri, 2 Mar 2001 07:32:20 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: New Diameter I-Ds are now available To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The latest version of the Diameter Internet-Drafts are now available. I believe that I have caught all of the comments that have been posted to the list. The following WG I-Ds have been released, and are available for preview on www.diameter.org: draft-ietf-aaa-framework-01.txt: includes a couple of minor editorial changes. draft-ietf-aaa-diameter-01.txt: This is the I-D that changed the most. In addition to including all of the changes that resulted from the Interim meeting, and the various comments on the list, the document went through a complete re-org. The old version's section 2 was really overloaded, and it contained LOTS of protocol-ish stuff that really didn't belong in an protocol overview section. I hope that you like the new format, as I find it MUCH simpler to find information. Please note that I have left the ICV and encrypted-payload for the time being, as it MAY be necessary for e2e (but this will be known when we select an e2e approach). After we the IETF we can discuss whether it stays, or goes. draft-ietf-aaa-mobileip-01.txt: This document has included lots of changes as well, mostly from comments on the list, but also from renaming of a few AVPs in the base protocol. The Feature-Vector AVP has much better language, but does rely on a few Mobile IP Key Request extensions that are not yet defined. A new Mobile IP AAA Keys, and Mobile IP Generalized Key Extensions I-Ds are on their way. draft-ietf-aaa-nasreq-01.txt: This document has mostly fixes to naming changes of AVPs in the base I-D, and a few additional minor editorial changes. draft-ietf-aaa-accounting-01.txt: This document includes changes that resulted from comments on the list, as well as from naming changes of AVPs in the base protocol, as well as some minor editorial changes. The following IDs are NOT WG documents, but have also been updated (and available on the web site): draft-calhoun-diameter-sun-ping-01.txt: Fixes due to changes in AVP naming in base protocol. As I may have mentioned previously, this is a VERY simple extension, and is a VERY useful tool. I hope that others have had the time to implement this extension at next week's bakeoff :) draft-calhoun-diameter-res-mgmt-08.txt: Fixes due to changes in AVP naming in base protocol. draft-kempf-diameter-api-04.txt: Quite a few changes are included in the API document. The most important being how Grouped AVPs are formed. A diff will show the changes. An interesting note to the WG is that I have been receiving LOTS of comments on this document as private mail. There appears to be quite a bit of interest in a common API across platforms. Please let me know if you have any questions, or comments. Thanks, PatC From owner-aaa-bof@merit.edu Fri Mar 2 11:25:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05223 for ; Fri, 2 Mar 2001 11:25:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0C365DDEB; Fri, 2 Mar 2001 11:24:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BFEB95DDD2; Fri, 2 Mar 2001 11:24:30 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 27E815DD91 for ; Fri, 2 Mar 2001 11:24:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08542; Fri, 2 Mar 2001 08:24:22 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29020; Fri, 2 Mar 2001 08:24:21 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA08235; Fri, 2 Mar 2001 08:24:20 -0800 (PST) Date: Fri, 2 Mar 2001 08:19:58 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: TLS or SSL? To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEDF@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Is it decided which one between SSL3.0 and TLS1.0 will be required by the > Base document? Currently the spec calls for SSL 3.0, but we haven't really discussed this point. PatC From owner-aaa-bof@merit.edu Fri Mar 2 14:18:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13787 for ; Fri, 2 Mar 2001 14:18:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1522B5DED3; Fri, 2 Mar 2001 14:12:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ED1165DEC1; Fri, 2 Mar 2001 14:12:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 5DB985DE1F for ; Fri, 2 Mar 2001 14:12:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05045 for ; Fri, 2 Mar 2001 11:12:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11234 for ; Fri, 2 Mar 2001 11:12:42 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA11648 for ; Fri, 2 Mar 2001 11:12:40 -0800 (PST) Date: Fri, 2 Mar 2001 11:08:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Strong Security I-D available To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, A new version of the strong security I-D has been sent to the Internet-Drafts editor and is now available for preview at www.diameter.org. PatC From owner-aaa-bof@merit.edu Fri Mar 2 16:23:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19772 for ; Fri, 2 Mar 2001 16:23:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6BF575DEBE; Fri, 2 Mar 2001 16:20:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A7D95DE9D; Fri, 2 Mar 2001 16:20:13 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id AE19B5DEB9 for ; Fri, 2 Mar 2001 16:20:11 -0500 (EST) Received: from gwzpc ([64.104.42.72] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA26689; Fri, 2 Mar 2001 13:20:03 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Martin Julien (ECE)" Cc: Subject: RE: [AAA-WG]: TLS or SSL? Date: Fri, 2 Mar 2001 13:19:49 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@eng.sun.com] writes: > > Is it decided which one between SSL3.0 and TLS1.0 will be > required by the > > Base document? > > Currently the spec calls for SSL 3.0, but we haven't really discussed this > point. I would think that given a choice between a roughly equivalentprotocols we would choose the IETF standard (i.e., TLS). > > PatC > > > From owner-aaa-bof@merit.edu Fri Mar 2 16:26:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19889 for ; Fri, 2 Mar 2001 16:26:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 759A15DEEE; Fri, 2 Mar 2001 16:23:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 649255DEC5; Fri, 2 Mar 2001 16:23:51 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5CEAE5DDAE for ; Fri, 2 Mar 2001 16:23:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26389; Fri, 2 Mar 2001 13:23:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19275; Fri, 2 Mar 2001 13:23:04 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA14808; Fri, 2 Mar 2001 13:23:02 -0800 (PST) Date: Fri, 2 Mar 2001 13:18:39 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: TLS or SSL? To: gwz@cisco.com Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I would think that given a choice between a roughly equivalentprotocols we > would choose the IETF standard (i.e., TLS). Your response is most timely, I've already sent in the latest I-Ds :( I will fix this in the next revision or the base protocol. PatC From owner-aaa-bof@merit.edu Sat Mar 3 09:43:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19797 for ; Sat, 3 Mar 2001 09:43:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EB165DDA3; Sat, 3 Mar 2001 09:43:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EA49D5DDA8; Sat, 3 Mar 2001 09:43:08 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 0E0825DDA3 for ; Sat, 3 Mar 2001 09:43:07 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f23EZYC20223; Sat, 3 Mar 2001 06:35:34 -0800 From: "Bernard Aboba" To: , Subject: RE: [AAA-WG]: Extension requirements? Date: Sat, 3 Mar 2001 06:43:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >given the liklihood of vendor-specific (and even implementation-specific) >extensions I understand the need for vendor-specific *attributes*, but vendor-specific extensions? One of the fundamental architectural principles of AAA is that new attributes should not require any new code on the AAA server, only a new dictionary entry. This is fundamental to the AAA architecture, because it provides the flexibility necessary to add new attributes to the protocol without having to upgrade servers. This works because typically only the NAS needs to understand the semantics of a given attribute. The major exception to this model are the authentication attributes (User-Password, CHAP-Password, EAP-Message, etc.) which require code to exist on the AAA server in order to verify them. >But many RADIUS servers are home-grown, part of closed systems. If history >is a guide, many Diameter servers will be, too. So why would the developers >thereof care about the market? Why should they be required to implement >something they will never use, just to be conformant? If we are adhering to the fundamental principles of AAA architecture, the answer to that question would be "because supporting additional attributes doesn't impose any additional work, other than new dictionary entries". The major exception to this would be attributes relating to authentication, which do require new code. If the work involved in implementing new attributes is significantly greater than this, then this results in a significant loss in flexibility. This would be the equivalent of treating SNMP MIBs as "extensions" and assuming that it would be impossible to suport them on an SNMP manager without code changes to the manager. From owner-aaa-bof@merit.edu Tue Mar 6 22:57:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10378 for ; Tue, 6 Mar 2001 22:57:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 441E25E0CD; Tue, 6 Mar 2001 22:09:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 76E705E8B4; Tue, 6 Mar 2001 21:23:06 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id E4C085E567 for ; Tue, 6 Mar 2001 20:42:44 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkfgg15557 for ; Wed, 7 Mar 2001 01:42:44 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkfgg16117 for ; Tue, 6 Mar 2001 20:42:10 -0500 (EST) Date: Tue, 6 Mar 2001 20:42:10 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION:draft-ietf-aaa-diameter-accounting-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 06 Mar 2001 06:39:55 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: aaa-wg@merit.edu Subject: I-D ACTION:draft-ietf-aaa-diameter-accounting-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Diameter Accounting Extensions Author(s) : J. Arkko, P. Calhoun, G. Zorn Filename : draft-ietf-aaa-diameter-accounting-01.txt Pages : 18 Date : 05-Mar-01 The Diameter protocol provides Authentication, Authorization and Accounting for network access technologies, such as NASREQ, ROAMOPS and Mobile IP. This extension describes how accounting records can be securely transmitted over the Diameter protocol. When combined with the Strong Security extension, accounting records MAY traverse intermediate proxies in a secure fashion and is compatible with the referral broker model. This extension allows real-time accounting transfers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-accounting-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-diameter-accounting-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-diameter-accounting-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-aaa-diameter-accounting-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Mar 6 22:58:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10404 for ; Tue, 6 Mar 2001 22:58:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D90E5DFC7; Tue, 6 Mar 2001 22:13:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 263585E10D; Tue, 6 Mar 2001 21:24:38 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by segue.merit.edu (Postfix) with ESMTP id A76295E27A for ; Tue, 6 Mar 2001 20:44:45 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkfgg19265 for ; Wed, 7 Mar 2001 01:44:45 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkfgg16148 for ; Tue, 6 Mar 2001 20:44:11 -0500 (EST) Date: Tue, 6 Mar 2001 20:44:11 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION:draft-ietf-aaa-diameter-framework-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 06 Mar 2001 06:40:04 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: aaa-wg@merit.edu Subject: I-D ACTION:draft-ietf-aaa-diameter-framework-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Diameter Framework Document Author(s) : P. Calhoun et al. Filename : draft-ietf-aaa-diameter-framework-01.txt Pages : 32 Date : 05-Mar-01 Current Internet Service Providers (ISPs) scale their networks by using the RADIUS protocol, which provides user Authentication, Authorization and Accounting (AAA) of Dial-up PPP clients. The recent work done in the Roaming Operations (ROAMOPS) Working Group was to investigate whether RADIUS could be used in a roaming network, and concluded that RADIUS was ill-suited for inter-domain purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-framework-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-diameter-framework-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-diameter-framework-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-aaa-diameter-framework-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Mar 6 22:59:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10425 for ; Tue, 6 Mar 2001 22:59:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5D01C5DEC3; Tue, 6 Mar 2001 22:14:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 202545E113; Tue, 6 Mar 2001 21:24:50 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id DC3335E30A for ; Tue, 6 Mar 2001 20:45:09 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkfgh18478 for ; Wed, 7 Mar 2001 01:45:09 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkfgg16158 for ; Tue, 6 Mar 2001 20:44:35 -0500 (EST) Date: Tue, 6 Mar 2001 20:44:35 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION:draft-ietf-aaa-diameter-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 06 Mar 2001 06:39:59 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: aaa-wg@merit.edu Subject: I-D ACTION:draft-ietf-aaa-diameter-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Diameter Base Protocol Author(s) : P. Calhoun et al. Filename : draft-ietf-aaa-diameter-01.txt Pages : 64 Date : 05-Mar-01 The Diameter base protocol is intended to provide a AAA framework for Mobile-IP, NASREQ and ROAMOPS. This draft specifies the message format, transport, error reporting and security services to be used by all Diameter extensions and MUST be supported by all Diameter implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-diameter-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-diameter-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-aaa-diameter-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Mar 6 22:59:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10441 for ; Tue, 6 Mar 2001 22:59:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DB5B5E102; Tue, 6 Mar 2001 22:14:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EEFDB5E118; Tue, 6 Mar 2001 21:24:58 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by segue.merit.edu (Postfix) with ESMTP id 8501A5E27F for ; Tue, 6 Mar 2001 20:45:43 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkfgh26680 for ; Wed, 7 Mar 2001 01:45:43 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkfgh16174 for ; Tue, 6 Mar 2001 20:45:09 -0500 (EST) Date: Tue, 6 Mar 2001 20:45:08 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION:draft-ietf-aaa-diameter-mobileip-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 06 Mar 2001 06:40:08 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: aaa-wg@merit.edu Subject: I-D ACTION:draft-ietf-aaa-diameter-mobileip-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Diameter Mobile IP Extensions Author(s) : P. Calhoun, C. Perkins Filename : draft-ietf-aaa-diameter-mobileip-01.txt Pages : 34 Date : 05-Mar-01 This document specifies an extension to the Diameter base protocol that allows a Diameter server to authenticate, authorize and collect accounting information for services rendered to a mobile node. Combined with the Inter-Domain capability of the base protocol, this extension allows mobile nodes to receive service from foreign service providers. The Diameter Accounting extension will be used by the Foreign and Home agents to transfer usage information to the Diameter servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-diameter-mobileip-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-diameter-mobileip-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-aaa-diameter-mobileip-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Tue Mar 6 23:00:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10470 for ; Tue, 6 Mar 2001 23:00:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2F7C95DEF9; Tue, 6 Mar 2001 22:14:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3757C5E276; Tue, 6 Mar 2001 21:25:02 -0500 (EST) Received: from cmr2.ash.ops.us.uu.net (cmr2.ash.ops.us.uu.net [198.5.241.40]) by segue.merit.edu (Postfix) with ESMTP id D2B855E361 for ; Tue, 6 Mar 2001 20:46:04 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr2.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkfgh20962 for ; Wed, 7 Mar 2001 01:46:04 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkfgh16182 for ; Tue, 6 Mar 2001 20:45:30 -0500 (EST) Date: Tue, 6 Mar 2001 20:45:30 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: I-D ACTION:draft-ietf-aaa-diameter-nasreq-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: ---------- Forwarded message ---------- Date: Tue, 06 Mar 2001 06:40:13 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Cc: aaa-wg@merit.edu Subject: I-D ACTION:draft-ietf-aaa-diameter-nasreq-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication, Authorization and Accounting Working Group of the IETF. Title : Diameter NASREQ Extensions Author(s) : P. Calhoun et al. Filename : draft-ietf-aaa-diameter-nasreq-01.txt Pages : 53 Date : 05-Mar-01 This document describes the Diameter extension that is used for AAA in a PPP/SLIP Dial-Up and Terminal Server Access environment. This extension, combined with the base protocol, satisfies the requirements defined in the NASREQ AAA criteria specification and the ROAMOPS AAA Criteria specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-aaa-diameter-nasreq-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-aaa-diameter-nasreq-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-ietf-aaa-diameter-nasreq-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Thu Mar 8 11:14:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01697 for ; Thu, 8 Mar 2001 11:14:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 757815DE85; Thu, 8 Mar 2001 11:13:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5CC8F5DE89; Thu, 8 Mar 2001 11:13:54 -0500 (EST) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by segue.merit.edu (Postfix) with SMTP id EE3445DE85 for ; Thu, 8 Mar 2001 11:13:52 -0500 (EST) Received: from grubby.research.bell-labs.com ([135.104.2.9]) by crufty; Thu Mar 8 11:11:41 EST 2001 Received: from king.research.bell-labs.com ([135.1.152.1]) by grubby; Thu Mar 8 11:13:31 EST 2001 Received: from notmafia.research.bell-labs.com.research.bell-labs.com (notmafia [135.1.152.230]) by king.research.bell-labs.com (Postfix) with SMTP id AF5CC5701F; Thu, 8 Mar 2001 10:13:30 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Pete McCann To: "Aaa-Wg@Merit. Edu" Cc: tom.hiller@lucent.com Subject: [AAA-WG]: DIAMETER AKA X-Mailer: VM 6.33 under Emacs 19.34.2 Message-Id: <20010308161330.AF5CC5701F@king.research.bell-labs.com> Date: Thu, 8 Mar 2001 10:13:30 -0600 (CST) Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, We recently submitted a draft on how to carry AKA parameters in DIAMETER messages. See the announcement copied below. We would appreciate discussion and feedback on this draft, especially whether it is completely in tune with the latest DIAMETER specification. Also, note that this version does not cover sequence number re-synchronization, but we plan to address it in a future update. Thanks, -Pete McCann A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DIAMETER Support for Authentication and Key Agreement (AKA) Author(s) : T. Hiller, P. McCann Filename : draft-hiller-aaa-diamaka-00.txt Pages : 13 Date : 27-Feb-01 The Authentication and Key Agreement (AKA) protocol is a widely used mechanism for authenticating mobile nodes in wireless networks. This draft proposes new DIAMETER AVPs to carry AKA parameters, which will enable DIAMETER to serve as an inter-domain transport mechanism for AKA messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hiller-aaa-diamaka-00.txt From owner-aaa-bof@merit.edu Thu Mar 8 14:14:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09083 for ; Thu, 8 Mar 2001 14:14:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 34ED65DDC1; Thu, 8 Mar 2001 14:13:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1CA6D5DDB7; Thu, 8 Mar 2001 14:13:47 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8DEDB5DDAC for ; Thu, 8 Mar 2001 14:13:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26931; Thu, 8 Mar 2001 11:13:44 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19191; Thu, 8 Mar 2001 11:13:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA00203; Thu, 8 Mar 2001 11:13:39 -0800 (PST) From: Patrice Calhoun Message-Id: <200103081913.LAA00203@nasnfs.Eng.Sun.COM> Date: Thu, 8 Mar 2001 11:12:59 -0800 To: , Reply-To: Subject: [AAA-WG]: Mobile IP Extension X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, This is just a heads up on changes that are required in the Mobile IP Extension, as a result of the testing this week in San Jose. The Mobile IP extension currently defines the following signalling FA AAAF AAAH HA -AMR-> -AMR-> -HAR-> <-AMA- <-AMA- <-HAA- However, if the Home Agent is assigned in the visited network, the following signalling is mandated: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -AMA-> -HAR-> <------------AMA---------- <-HAA- <-HAI- We had originally decided to do this to reduce the number of round trips to the AAAH. In the above scenario, the AAAH authenticates the mobile, generates keys, and replies back to the AAAF. The AAAH is not contacted again until the HAI is sent to inform the AAAH of the status of the request. However, this scheme, while reducing round trips, does require that HAR-ish AVPs are present in the AMA. This really makes the protocol quite complicated, and further requires that the HAI include some success result code. This means that in order to save round trips, we end up abusing protocol messages. Therefore, after discussin this over with people that have implemented it, we decided that protocol complexity did not justify this, and we reverted back to what was in the spec some time back, which is: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- This means that the signalling is exactly the same, whether the Home Agent is in the home or visited network. Furthermore, it makes it VERY simple to also handle the case where the Home Agent is in a third network, as below: (3rd domain) FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- Anyone object to the above changes in the -02 of the Mobile IP extension? Again, implementors found this to be the simplest. Thanks, PatC From owner-aaa-bof@merit.edu Thu Mar 8 15:20:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11537 for ; Thu, 8 Mar 2001 15:20:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BEB15DF44; Thu, 8 Mar 2001 15:15:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EC1495DEC4; Thu, 8 Mar 2001 15:15:10 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id D99D25DF5F for ; Thu, 8 Mar 2001 15:10:39 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f28KAbd20853 for ; Thu, 8 Mar 2001 21:10:37 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 08 21:10:35 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 8 Mar 2001 21:10:36 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEEE@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt Date: Thu, 8 Mar 2001 21:10:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, I have some comments on this document, and hopefully they might be useful. 1) I think that page 8 should be a new section about a Mobile Node moving to a Foreign Network. 2)Page 8, par.2, the MIP-Previous-FA-NAI must be change for MIP-Previous-FA-FQDN. You should use find and replace for this one, since there are more than one. 3) Page 8, in figure 5, the message between the HA and AAAF must be HAA, instead of HAR. 4) Page 8, par.2, last sentence. I don't really understand what you mean there. I guess you meant that Home Agent and the requesting Foreign Agent are in different domain. The thing is that it is likely that the Home Agent and the MIP-Previous-FA-FQDN were in the same domain at the last registration, right? 5) In section 1.3, the meaning of home address 255.255.255.255 is described, but the meaning of 0.0.0.0 should also be added for clarity. BTW, those conditions are mentioned at several places in the document. I like the concept of the state machine as in the Base spec. 6) Section 1.4, the second paragraph suggests to release the all resources in the Home Diameter server upon the receipt of the STR from the Home Agent. I guess it should be clear that the referred Home Agent is the "active" Home Agent, since there might be 2 Home Agents at the same time while roaming. During handoffs between different FAs in different domains, and let's say that the Home Agent in the old Foreign domain can not be maintained there, then a new Home Agent has to be started in the Home Domain or the new Foreign domain and the AAAH needs to send a STI to the old Home Agent, which replies with a STR. In that case, the Home Diameter should not release resources, right? 7) Many references to MIP-Reg-Req should be changed for MIP-Reg-Request. Find and replace. 8) Many references to MIP-Reg-Rep should be changed for MIP-Reg-Reply. Find and replace. 9) Many references to Peer-SPI should be changed for MIP-Peer-SPI . Find and replace. 10) In section 2.3, a home address of 255.255.255.255 should also request a new address. 11) Section 2.3 par.2, "If a AAAF receives a HAR..." should be "If a AAAF receives a AMA..." Right? 12) Section 3.1, it it Hop-by-Hop Failures?, or Per-Hop Failures? Should all those errors be sent through a DSI? 13) Section 3.1, just wondering, why error numbers are 6xxx series? 14) Section 4.6, A reference to Previous Foreign Agent Notification Extension would be nice. 15) Section 4.7, "If the mobile node sets the home agent field equal to 0.0.0.0 ..." should also include 255.255.255.255, like mentioned in section 1.3 16) Section 4.7, "...Home-Address-Requested flag or the Home-Agent-Request flag..." should rather be "Mobile-Node-Home-Address-Requested flag or the Home-Agent-Requested flag" 17) "If the mobile node requests a home agent in the foreign network by setting the home address field to all ones,..." I guess it should be home agent instead, right? Also, in the document, 255.255.255.255 is used and some other places it is all ones. Can it be one or the other for clarity? 18) Section 5.0 par.2, "Absence or the AVP, or a value of zero indicates infinity (no timeout)." It the message definition, it says that this AVP is mandatory. 19) Section 5.0 par.2, "If no preferred SPI value is indicated the registration keys the foreign agent needs..." I think that the part "the registration keys the foreign agent needs" does not really fit in this sentence. 20) Section 5.1 par.3, "MIP-HA-to-MN-Key AVP in the AMR message..." should be "in the AMA message" (reference to section 1.3 p.7) 21) Section 5.1 par.3, "When the AAAF receives the AMR,..." should also be "the AMA" 22) Section 5.1 par.5, "MIP-MN-to-HA-Key AVP into the AMR message" should be "the AMA" 23) Section 5.1 par.5, "...in the MIP-HA-to-MN-Key AVP from the AVP received from AAAH, AAAF then recodes the registration key into a new MIP-HA-to-MN-Key AVP ". Both MIP-HA-to-MN-Key should be replaced by MIP-MN-to-HA-Key. 24) Section 5.2 par.2, "...MIP-MN-to-FA-Key AVP in the AMR message..." should be the "AMA message" 25) Section 5.2 last par., "...key available to AAAF." should be "available to FA" 26) Section 5.3 par.4, "...MIP-HA-to-FA-Key AVP as part of the AMR..." should be "to the AMA" 27) Section 2.1, why is the Session-ID is required with {}, but not with [], like in other messages? 28) Section 2.1, why the "Authorization-Lifetime" required? 29) I am wondering why the Destination-Realm AVP is required in Answer messages? 30) In section 2.2, the Origin-FQDN AVP and the Origin-Realm AVP must be required. 31) In section 2.5, what is the point of sending a HAI without the MIP-Home-Agent-Address? Should it be required? 32) In the case where a mobile node handoffs to a different FA within the same administrative domain, is it required to reach the Home server with the AMR?, or can it be handled in the AAAF? It might be interesting to show this scenario, right? I think this is it for now. Cheers, Martin From owner-aaa-bof@merit.edu Thu Mar 8 17:54:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16211 for ; Thu, 8 Mar 2001 17:54:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id CE23D5DEEE; Thu, 8 Mar 2001 17:51:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E69E5DEEF; Thu, 8 Mar 2001 17:51:14 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 6CF0F5DEDF for ; Thu, 8 Mar 2001 17:51:10 -0500 (EST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Thu, 8 Mar 2001 16:50:55 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Mar 2001 16:50:54 -0600 Message-ID: From: "Haseeb Akhtar" To: "'pcalhoun'" , aaa-wg , diameter Subject: RE: [AAA-WG]: Mobile IP Extension Date: Thu, 8 Mar 2001 16:50:45 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A822.35DD64B0" Sender: owner-aaa-bof@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_01C0A822.35DD64B0 Content-Type: text/plain; charset="iso-8859-1" Pat, I would like to propose we generalize AMR and AMA so that both of these messages can be used between all four entities involved (FA, AAAF, AAAH and HA) during registration. That way, we can truly ignore the geographical proximity between them and focus on their functional behavior. So, this is what the flow would look like. FA AAAF AAAH HA@visited_network -AMR-> -AMR-> <-AMA- --------AMR--------> <--------AMA-------- <-AMA- Granted, there are differences between the functions that needs to be performed after receiving AMR vs. HAR, however, the Session ID can keep the servers stateful. Also, you are having to open up the AAAF for both AMR/AMA and HAR/HAA interfaces in the option cited below. Combining them into one interface will, in my opinion, make a better protocol. Regards, Haseeb -----Original Message----- From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] Sent: Thursday, March 08, 2001 1:13 PM To: aaa-wg; diameter Subject: [AAA-WG]: Mobile IP Extension All, This is just a heads up on changes that are required in the Mobile IP Extension, as a result of the testing this week in San Jose. The Mobile IP extension currently defines the following signalling FA AAAF AAAH HA -AMR-> -AMR-> -HAR-> <-AMA- <-AMA- <-HAA- However, if the Home Agent is assigned in the visited network, the following signalling is mandated: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -AMA-> -HAR-> <------------AMA---------- <-HAA- <-HAI- We had originally decided to do this to reduce the number of round trips to the AAAH. In the above scenario, the AAAH authenticates the mobile, generates keys, and replies back to the AAAF. The AAAH is not contacted again until the HAI is sent to inform the AAAH of the status of the request. However, this scheme, while reducing round trips, does require that HAR-ish AVPs are present in the AMA. This really makes the protocol quite complicated, and further requires that the HAI include some success result code. This means that in order to save round trips, we end up abusing protocol messages. Therefore, after discussin this over with people that have implemented it, we decided that protocol complexity did not justify this, and we reverted back to what was in the spec some time back, which is: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- This means that the signalling is exactly the same, whether the Home Agent is in the home or visited network. Furthermore, it makes it VERY simple to also handle the case where the Home Agent is in a third network, as below: (3rd domain) FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- Anyone object to the above changes in the -02 of the Mobile IP extension? Again, implementors found this to be the simplest. Thanks, PatC ------_=_NextPart_001_01C0A822.35DD64B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Mobile IP Extension

Pat,

I would like to propose we generalize AMR and AMA =
so that both of these messages can be used = between
all four entities involved (FA, AAAF, AAAH and HA) = during
registration. That way, we can truly ignore the =
geographical proximity between them and focus on = their
functional behavior.

So, this is what the flow would look like.

FA      =         AAAF    =         AAAH    = HA@visited_network
  -AMR->  =       =         -AMR->
          =       =         <-AMA-
        =         =         --------AMR-------->
        =         =         <--------AMA--------
  <-AMA-  =       =        

Granted, there are differences between the functions = that
needs to be performed after receiving AMR vs. HAR, = however,
the Session ID can keep the servers stateful.

Also, you are having to open up the AAAF for both = AMR/AMA
and HAR/HAA interfaces in the option cited below. = Combining
them into one interface will, in my opinion, make a = better
protocol.

Regards,

Haseeb



-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.S= un.COM]
Sent: Thursday, March 08, 2001 1:13 PM
To: aaa-wg; diameter
Subject: [AAA-WG]: Mobile IP Extension


All,

This is just a heads up on changes that are required = in the Mobile IP Extension,
as a result of the testing this week in San = Jose.

The Mobile IP extension currently defines the = following signalling

FA       = AAAF      AAAH      = HA
   -AMR->    = -AMR->    -HAR->
   <-AMA-    = <-AMA-    <-HAA-

However, if the Home Agent is assigned in the visited = network, the
following signalling is mandated:

FA       = AAAF      AAAH      = AAAF      HA
   -AMR->    = -AMR->    -AMA->    = -HAR->
   = <------------AMA----------    <-HAA-
          &nb= sp;           &nb= sp; <-HAI-

We had originally decided to do this to reduce the = number of round trips to
the AAAH. In the above scenario, the AAAH = authenticates the mobile, generates
keys, and replies back to the AAAF. The AAAH is not = contacted again until the
HAI is sent to inform the AAAH of the status of the = request.

However, this scheme, while reducing round trips, = does require that HAR-ish
AVPs are present in the AMA. This really makes the = protocol quite complicated,
and further requires that the HAI include some = success result code. This
means that in order to save round trips, we end up = abusing protocol messages.

Therefore, after discussin this over with people that = have implemented it, we
decided that protocol complexity did not justify = this, and we reverted back
to what was in the spec some time back, which = is:
FA       = AAAF      AAAH      = AAAF      HA
   -AMR->    = -AMR->    -HAR->    = -HAR->
   <-AMA-    = <-AMA-    <-HAA-    = <-HAA-

This means that the signalling is exactly the same, = whether the Home Agent is
in the home or visited network. Furthermore, it = makes it VERY simple to also
handle the case where the Home Agent is in a third = network, as below:

          &nb= sp;           &nb= sp;       (3rd domain)
FA       = AAAF      AAAH      = AAAF      HA
   -AMR->    = -AMR->    -HAR->    = -HAR->
   <-AMA-    = <-AMA-    <-HAA-    = <-HAA-

Anyone object to the above changes in the -02 of the = Mobile IP extension? Again,
implementors found this to be the simplest.

Thanks,

PatC


------_=_NextPart_001_01C0A822.35DD64B0-- From owner-aaa-bof@merit.edu Thu Mar 8 18:04:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16413 for ; Thu, 8 Mar 2001 18:04:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 83ADA5DE87; Thu, 8 Mar 2001 17:59:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 335ED5DFA1; Thu, 8 Mar 2001 17:58:59 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AB0765DFA1 for ; Thu, 8 Mar 2001 17:57:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16807; Thu, 8 Mar 2001 14:56:29 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17663; Thu, 8 Mar 2001 14:56:28 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id OAA04761; Thu, 8 Mar 2001 14:56:20 -0800 (PST) From: Patrice Calhoun Message-Id: <200103082256.OAA04761@nasnfs.Eng.Sun.COM> Date: Thu, 8 Mar 2001 14:55:43 -0800 To: "Haseeb Akhtar" , "diameter" , "aaa-wg" Reply-To: Subject: RE: [AAA-WG]: Mobile IP Extension X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit hmmmm.... I recall having this discussion, and I am quite sure that my response will be the same. I really do not care much for messages that have to be treated completely differently, based on whether the receiver is a home server or a home agent. Your proposal makes it REALLY hard to have a single code base, that supports both client and server side (NAS/FA and AAAH). Anyone else? PatC >Pat, > >I would like to propose we generalize AMR and AMA >so that both of these messages can be used between >all four entities involved (FA, AAAF, AAAH and HA) during >registration. That way, we can truly ignore the >geographical proximity between them and focus on their >functional behavior. > >So, this is what the flow would look like. > >FA AAAF AAAH HA@visited_network > -AMR-> -AMR-> > <-AMA- > --------AMR--------> > <--------AMA-------- > <-AMA- > >Granted, there are differences between the functions that >needs to be performed after receiving AMR vs. HAR, however, >the Session ID can keep the servers stateful. > >Also, you are having to open up the AAAF for both AMR/AMA >and HAR/HAA interfaces in the option cited below. Combining >them into one interface will, in my opinion, make a better >protocol. > >Regards, > >Haseeb > > > >-----Original Message----- >From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] >Sent: Thursday, March 08, 2001 1:13 PM >To: aaa-wg; diameter >Subject: [AAA-WG]: Mobile IP Extension > > >All, > >This is just a heads up on changes that are required in the Mobile IP >Extension, >as a result of the testing this week in San Jose. > >The Mobile IP extension currently defines the following signalling > >FA AAAF AAAH HA > -AMR-> -AMR-> -HAR-> > <-AMA- <-AMA- <-HAA- > >However, if the Home Agent is assigned in the visited network, the >following signalling is mandated: > >FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -AMA-> -HAR-> > <------------AMA---------- <-HAA- > <-HAI- > >We had originally decided to do this to reduce the number of round trips to >the AAAH. In the above scenario, the AAAH authenticates the mobile, >generates >keys, and replies back to the AAAF. The AAAH is not contacted again until >the >HAI is sent to inform the AAAH of the status of the request. > >However, this scheme, while reducing round trips, does require that HAR-ish >AVPs are present in the AMA. This really makes the protocol quite >complicated, >and further requires that the HAI include some success result code. This >means that in order to save round trips, we end up abusing protocol >messages. > >Therefore, after discussin this over with people that have implemented it, >we >decided that protocol complexity did not justify this, and we reverted back >to what was in the spec some time back, which is: >FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -HAR-> -HAR-> > <-AMA- <-AMA- <-HAA- <-HAA- > >This means that the signalling is exactly the same, whether the Home Agent >is >in the home or visited network. Furthermore, it makes it VERY simple to also >handle the case where the Home Agent is in a third network, as below: > > (3rd domain) >FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -HAR-> -HAR-> > <-AMA- <-AMA- <-HAA- <-HAA- > >Anyone object to the above changes in the -02 of the Mobile IP extension? >Again, >implementors found this to be the simplest. > >Thanks, > >PatC > > From owner-aaa-bof@merit.edu Thu Mar 8 18:36:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17365 for ; Thu, 8 Mar 2001 18:36:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 97BED5DE39; Thu, 8 Mar 2001 18:23:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 560AC5DF2A; Thu, 8 Mar 2001 18:22:13 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id F28545DF20 for ; Thu, 8 Mar 2001 18:21:19 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f28NLHi05911; Thu, 8 Mar 2001 17:21:17 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id f28NLDE05957; Thu, 8 Mar 2001 17:21:13 -0600 (CST) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id RAA08516; Thu, 8 Mar 2001 17:21:16 -0600 (CST) Received: from ericsson.com (rc130106.exu.ericsson.se [138.85.130.106]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA23024; Thu, 8 Mar 2001 17:21:11 -0600 (CST) Message-ID: <3AA81421.6CAB3207@ericsson.com> Date: Thu, 08 Mar 2001 15:22:10 -0800 From: Tony Johansson Organization: Ericsson Inc X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Haseeb Akhtar Cc: "'pcalhoun'" , aaa-wg , diameter Subject: Re: [AAA-WG]: Mobile IP Extension References: Content-Type: multipart/alternative; boundary="------------08441F2BA1EA66C8F3B46724" Sender: owner-aaa-bof@merit.edu Precedence: bulk --------------08441F2BA1EA66C8F3B46724 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Haseeb, I disagree with you. An AMR and an HAR are two different things. The AMR deals with user authentication and the HAR deals with HA assignment. We have been discussing this during the interop test even in San Jose and I strongly believe that the most logic way of doing this is as Pat describes it below. BR, /Tony Haseeb Akhtar wrote: > > > Pat, > > I would like to propose we generalize AMR and AMA > so that both of these messages can be used between > all four entities involved (FA, AAAF, AAAH and HA) during > registration. That way, we can truly ignore the > geographical proximity between them and focus on their > functional behavior. > > So, this is what the flow would look like. > > FA AAAF AAAH HA@visited_network > -AMR-> -AMR-> > <-AMA- > --------AMR--------> > <--------AMA-------- > <-AMA- > > Granted, there are differences between the functions that > needs to be performed after receiving AMR vs. HAR, however, > the Session ID can keep the servers stateful. > > Also, you are having to open up the AAAF for both AMR/AMA > and HAR/HAA interfaces in the option cited below. Combining > them into one interface will, in my opinion, make a better > protocol. > > Regards, > > Haseeb > > > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] > Sent: Thursday, March 08, 2001 1:13 PM > To: aaa-wg; diameter > Subject: [AAA-WG]: Mobile IP Extension > > All, > > This is just a heads up on changes that are required in the Mobile IP > Extension, > as a result of the testing this week in San Jose. > > The Mobile IP extension currently defines the following signalling > > FA AAAF AAAH HA > -AMR-> -AMR-> -HAR-> > <-AMA- <-AMA- <-HAA- > > However, if the Home Agent is assigned in the visited network, the > following signalling is mandated: > > FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -AMA-> -HAR-> > <------------AMA---------- <-HAA- > <-HAI- > > We had originally decided to do this to reduce the number of round > trips to > the AAAH. In the above scenario, the AAAH authenticates the mobile, > generates > keys, and replies back to the AAAF. The AAAH is not contacted again > until the > HAI is sent to inform the AAAH of the status of the request. > > However, this scheme, while reducing round trips, does require that > HAR-ish > AVPs are present in the AMA. This really makes the protocol quite > complicated, > and further requires that the HAI include some success result code. > This > means that in order to save round trips, we end up abusing protocol > messages. > > Therefore, after discussin this over with people that have implemented > it, we > decided that protocol complexity did not justify this, and we reverted > back > to what was in the spec some time back, which is: > FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -HAR-> -HAR-> > <-AMA- <-AMA- <-HAA- <-HAA- > > This means that the signalling is exactly the same, whether the Home > Agent is > in the home or visited network. Furthermore, it makes it VERY simple > to also > handle the case where the Home Agent is in a third network, as below: > > (3rd domain) > FA AAAF AAAH AAAF HA > -AMR-> -AMR-> -HAR-> -HAR-> > <-AMA- <-AMA- <-HAA- <-HAA- > > Anyone object to the above changes in the -02 of the Mobile IP > extension? Again, > implementors found this to be the simplest. > > Thanks, > > PatC > --------------08441F2BA1EA66C8F3B46724 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Haseeb,

I disagree with you. An AMR and an HAR are two different things. The AMR deals with user authentication and the HAR deals with HA assignment. We have been discussing this during the interop test even in San Jose and I strongly believe that the most logic way of doing this is as Pat describes it below.

BR,

/Tony

Haseeb Akhtar wrote:

 

Pat,

I would like to propose we generalize AMR and AMA
so that both of these messages can be used between
all four entities involved (FA, AAAF, AAAH and HA) during
registration. That way, we can truly ignore the
geographical proximity between them and focus on their
functional behavior.

So, this is what the flow would look like.

FA              AAAF            AAAH    HA@visited_network
  -AMR->                -AMR->
                        <-AMA-
                        --------AMR-------->
                        <--------AMA--------
  <-AMA-

Granted, there are differences between the functions that
needs to be performed after receiving AMR vs. HAR, however,
the Session ID can keep the servers stateful.

Also, you are having to open up the AAAF for both AMR/AMA
and HAR/HAA interfaces in the option cited below. Combining
them into one interface will, in my opinion, make a better
protocol.

Regards,

Haseeb
 

-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM]
Sent: Thursday, March 08, 2001 1:13 PM
To: aaa-wg; diameter
Subject: [AAA-WG]: Mobile IP Extension

All,

This is just a heads up on changes that are required in the Mobile IP Extension,
as a result of the testing this week in San Jose.

The Mobile IP extension currently defines the following signalling

FA       AAAF      AAAH      HA
   -AMR->    -AMR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-

However, if the Home Agent is assigned in the visited network, the
following signalling is mandated:

FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -AMA->    -HAR->
   <------------AMA----------    <-HAA-
                        <-HAI-

We had originally decided to do this to reduce the number of round trips to
the AAAH. In the above scenario, the AAAH authenticates the mobile, generates
keys, and replies back to the AAAF. The AAAH is not contacted again until the
HAI is sent to inform the AAAH of the status of the request.

However, this scheme, while reducing round trips, does require that HAR-ish
AVPs are present in the AMA. This really makes the protocol quite complicated,
and further requires that the HAI include some success result code. This
means that in order to save round trips, we end up abusing protocol messages.

Therefore, after discussin this over with people that have implemented it, we
decided that protocol complexity did not justify this, and we reverted back
to what was in the spec some time back, which is:
FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -HAR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-    <-HAA-

This means that the signalling is exactly the same, whether the Home Agent is
in the home or visited network. Furthermore, it makes it VERY simple to also
handle the case where the Home Agent is in a third network, as below:

                              (3rd domain)
FA       AAAF      AAAH      AAAF      HA
   -AMR->    -AMR->    -HAR->    -HAR->
   <-AMA-    <-AMA-    <-HAA-    <-HAA-

Anyone object to the above changes in the -02 of the Mobile IP extension? Again,
implementors found this to be the simplest.

Thanks,

PatC
 

--------------08441F2BA1EA66C8F3B46724-- From owner-aaa-bof@merit.edu Fri Mar 9 03:14:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09891 for ; Fri, 9 Mar 2001 03:14:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id E82175DD8C; Fri, 9 Mar 2001 03:13:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 955445DDA6; Fri, 9 Mar 2001 03:13:34 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 3C5985DD8C for ; Fri, 9 Mar 2001 03:13:25 -0500 (EST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f298DNC24054 for ; Fri, 9 Mar 2001 09:13:24 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Fri Mar 09 09:13:21 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 09:15:51 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEEF@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'pcalhoun@nasnfs.Eng.Sun.COM'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt Date: Fri, 9 Mar 2001 09:11:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi Pat, I sent it to the list yesterday, but for some reasons, it never made it apparently??? Let's try again! Martin > -----Original Message----- > From: Martin Julien (ECE) > Sent: Thursday, March 08, 2001 9:11 PM > To: 'aaa-wg@merit.edu' > Subject: Comments on draft-ietf-aaa-diameter-mobileip-01.txt > > Hi Pat, > > I have some comments on this document, and hopefully they > might be useful. > > > 1) I think that page 8 should be a new section about a Mobile > Node moving to a Foreign Network. > > 2)Page 8, par.2, the MIP-Previous-FA-NAI must be change for > MIP-Previous-FA-FQDN. You should use find and replace for > this one, since there are more than one. > > 3) Page 8, in figure 5, the message between the HA and AAAF > must be HAA, instead of HAR. > > 4) Page 8, par.2, last sentence. I don't really understand > what you mean there. I guess you meant that Home Agent and > the requesting Foreign Agent are in different domain. The > thing is that it is likely that the Home Agent and the > MIP-Previous-FA-FQDN were in the same domain at the last > registration, right? > > 5) In section 1.3, the meaning of home address > 255.255.255.255 is described, but the meaning of 0.0.0.0 > should also be added for clarity. BTW, those conditions are > mentioned at several places in the document. I like the > concept of the state machine as in the Base spec. > > 6) Section 1.4, the second paragraph suggests to release the > all resources in the Home Diameter server upon the receipt of > the STR from the Home Agent. I guess it should be clear that > the referred Home Agent is the "active" Home Agent, since > there might be 2 Home Agents at the same time while roaming. > During handoffs between different FAs in different domains, > and let's say that the Home Agent in the old Foreign domain > can not be maintained there, then a new Home Agent has to be > started in the Home Domain or the new Foreign domain and the > AAAH needs to send a STI to the old Home Agent, which replies > with a STR. In that case, the Home Diameter should not > release resources, right? > > 7) Many references to MIP-Reg-Req should be changed for > MIP-Reg-Request. Find and replace. > > 8) Many references to MIP-Reg-Rep should be changed for > MIP-Reg-Reply. Find and replace. > > 9) Many references to Peer-SPI should be changed for > MIP-Peer-SPI . Find and replace. > > 10) In section 2.3, a home address of 255.255.255.255 should > also request a new address. > > 11) Section 2.3 par.2, "If a AAAF receives a HAR..." should > be "If a AAAF receives a AMA..." Right? > > 12) Section 3.1, it it Hop-by-Hop Failures?, or Per-Hop > Failures? Should all those errors be sent through a DSI? > > 13) Section 3.1, just wondering, why error numbers are 6xxx series? > > 14) Section 4.6, A reference to Previous Foreign Agent > Notification Extension would be nice. > > 15) Section 4.7, "If the mobile node sets the home agent > field equal to 0.0.0.0 ..." should also include > 255.255.255.255, like mentioned in section 1.3 > > 16) Section 4.7, "...Home-Address-Requested flag or the > Home-Agent-Request flag..." should rather be > "Mobile-Node-Home-Address-Requested flag or the > Home-Agent-Requested flag" > > 17) "If the mobile node requests a home agent in the foreign > network by > setting the home address field to all ones,..." I guess it > should be home agent instead, right? Also, in the document, > 255.255.255.255 is used and some other places it is all ones. > Can it be one or the other for clarity? > > 18) Section 5.0 par.2, "Absence or the AVP, or a value of > zero indicates infinity > (no timeout)." It the message definition, it says that > this AVP is mandatory. > > 19) Section 5.0 par.2, "If no preferred SPI value is > indicated the registration keys the foreign agent needs..." I > think that the part "the registration keys the foreign agent > needs" does not really fit in this sentence. > > 20) Section 5.1 par.3, "MIP-HA-to-MN-Key AVP in the AMR > message..." should be "in the AMA message" (reference to > section 1.3 p.7) > > 21) Section 5.1 par.3, "When the AAAF receives the AMR,..." > should also be "the AMA" > > 22) Section 5.1 par.5, "MIP-MN-to-HA-Key AVP into the AMR > message" should be "the AMA" > > 23) Section 5.1 par.5, "...in the MIP-HA-to-MN-Key AVP from > the AVP received from AAAH, AAAF then recodes the > registration key into a new MIP-HA-to-MN-Key AVP ". Both > MIP-HA-to-MN-Key should be replaced by MIP-MN-to-HA-Key. > > 24) Section 5.2 par.2, "...MIP-MN-to-FA-Key AVP in the AMR > message..." should be the "AMA message" > > 25) Section 5.2 last par., "...key available to AAAF." should > be "available to FA" > > > 26) Section 5.3 par.4, "...MIP-HA-to-FA-Key AVP as part of > the AMR..." should be "to the AMA" > > 27) Section 2.1, why is the Session-ID is required with {}, > but not with [], like in other messages? > > 28) Section 2.1, why the "Authorization-Lifetime" required? > > 29) I am wondering why the Destination-Realm AVP is required > in Answer messages? > > 30) In section 2.2, the Origin-FQDN AVP and the Origin-Realm > AVP must be required. > > 31) In section 2.5, what is the point of sending a HAI > without the MIP-Home-Agent-Address? Should it be required? > > 32) In the case where a mobile node handoffs to a different > FA within the same administrative domain, is it required to > reach the Home server with the AMR?, or can it be handled in > the AAAF? It might be interesting to show this scenario, right? > > > I think this is it for now. > Cheers, > Martin From owner-aaa-bof@merit.edu Fri Mar 9 09:42:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15203 for ; Fri, 9 Mar 2001 09:42:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1AD995DDD1; Fri, 9 Mar 2001 09:41:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 009665DDD2; Fri, 9 Mar 2001 09:41:54 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E4C815DDD1 for ; Fri, 9 Mar 2001 09:41:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29102; Fri, 9 Mar 2001 06:41:48 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14458; Fri, 9 Mar 2001 06:41:47 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA26455; Fri, 9 Mar 2001 06:41:44 -0800 (PST) Date: Fri, 9 Mar 2001 06:37:15 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: Comments on draft-ietf-aaa-diameter-mobileip-01.txt To: "Martin Julien (ECE)" Cc: "'pcalhoun@nasnfs.Eng.Sun.COM'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEEF@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Martin, Got them yesterday. I will go through them on Monday as I start getting -02 ready. Thanks for the great comments, PatC From owner-aaa-bof@merit.edu Fri Mar 9 10:21:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17013 for ; Fri, 9 Mar 2001 10:21:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6F2AB5DE17; Fri, 9 Mar 2001 10:19:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57E0E5DE16; Fri, 9 Mar 2001 10:19:35 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5F59A5DE14 for ; Fri, 9 Mar 2001 10:19:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25495; Fri, 9 Mar 2001 07:19:32 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19527; Fri, 9 Mar 2001 07:19:31 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA26770; Fri, 9 Mar 2001 07:19:28 -0800 (PST) Date: Fri, 9 Mar 2001 07:15:00 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Diameter Issues found @ Connectathon To: aaa-wg@merit.edu, diameter@diameter.org Cc: pcalhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Here are some issues that were found in the protocol during the interoperability testing that occurred this week. I would suggest that we fix the protocol but would be interested in hearing any comments. 1) Vendor-Id AVP (Base Protocol) Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This now requires in order to implement Diameter, an enterprise number must be received from IANA. This really doesn't make a whole lot of sense, and the group felt that moving back to Vendor-Name was the correct approach. Further, the Vendor-Name could also include some "product" information for those vendors that have many client and server products (e.g. say abc has FAs and NASes, as well as a server). 2) Result-Code in MRI (Base Protocol) The Base Protocol defines the Message-Reject-Ind command to include the Result-Code AVP. This really does violate the protocol, since if the Result-Code is to be present in the MRI, it should also be present in the DRI (and all -Ind messages). Therefore, the group agreed that the Result-Code must not be present in the MRI, and instead be replaced with some other AVP, such as the Message-Reject-Code AVP (new). 3) DIAMETER_STILL_WORKING (Base Protocol) The base protocol is not clear about this one, but receiving the above error does imply that another message will eventually be received with the same Identifier in the header. This needs to be clarified, since many vendors use the identifier to match request/responses, and don't expect more than one message with the same id. 4) Peer State Machine (Base Protocol) The state machine is still not clear on how to deal with race conditions, and testing showed that further clarifications are required when a TCP or SCTP connection is established. My recommendation is that the initiator of the connection (the one that calls connect()) should be the one that sends the first DRI. Upon receiving the DRI, the receiver (one that calls listen()) checks whether another connection is in the process of being established, and if so, it will do an election process. If the identifier in the received Diameter header is equal or greater than the one it had sent, it will tear down the other connection. Otherwise, the incoming connection is shutdown. So the receiver is always the one that does the election check, and the fact that the DRIs aren't sent simultaneously on the same connection makes it easier to make such a check. 5) Unknown Vendor-Specific Commands The MRI is used to inform a peer that an unknown command code has been received. However, if the command code is vendor specific, there is no way to state this. Therefore, a new AVP, called the Unknown-Vendor-Id needs to be created to inform a peer of the possible vendor-id/command code combination. Of course, this AVP only needs to be present if it was a vendor-specific command code. 6) Treatment of Route-Record (Base Protocol) An issue arose where a host sent me a packet with the route-record different from the fqdn that gets resolved via DNS. So when the corresponding response was received, I would throw the packet away when I determined that I didn't know how to get to the host in the route-record. This led to a discussion which resulted in an agreement that the Origin-FQDN in the DRI SHOULD be saved by Diameter implementations, since this MUST be the same name as the one that would be present in the Route-Record. Of course, if the Origin-FQDN presented is the same as the one that is resolved by DNS, this is not an issue, but the above clarification can really reduce potential problems in the field (hey, it took me 45 minutes to figure out what was going on, and I have source code). So I propose a clarification in the Route-Record AVP that states that the name in the AVP is the same as the one that was in the Origin-FQDN in the DRI. 7) HAR (MIP) An issue arose and it was agreed that the Home-Agent AVP MUST be present in the HAR. The HAR is the message that is sent towards the Home Agent. 8) RADIUS-style MIP Challenge/Response (MIP) The Mobile IP Challenge/Response I-D supports a RADIUS compatibility mode. In this mode, the response in constructed in a way that is compatible with existing RADIUS servers. The problem is that the challenge advertised to the mobile needs to be known by the AAAH in order to compute the response, and the challenge is never sent in a Diameter message. So a new Diameter AVP needs to be created that would encapsulate the Challenge. This would ONLY need to be done if the MN-AAA authentication extension was created using the RADIUS mode, and this is known by the FA via the SPI. 9) Authorization-Lifetime in AMR (MIP) The MIP extension currently requires that the Authorization-Lifetime AVP be present in the AMR (from the foreign agent). I have no idea why it was done this way, but I know that many Foreign Agents will be perfectly happy to receive whatever value they get from the AAAH, so it doesn't make sense for this AVP to always be present in the message. I would like to recommend that this AVP become optional in the AMR. 10) Authorization-Lifetime and KEYs (MIP) Although it really isn't clearly stated, the Authorization-Lifetime and the session key lifetimes MUST be the same. This clarification is required in the document. 11) Flags in Diameter header (Base Protocol) The current (01) I-D states: "A Diameter node MUST NOT set these flags in any other combination. A Diameter node receiving a message in which these flags are not set appropriately SHOULD NOT reject the message for this reason, but MAY log the event for diagnosis." This sort-of implies that it isn't mandatory to set the bits. Some additional language needs to be added to make it clear that setting these bits is a MUST. 12) HA in visited network (see e-mail I sent yesterday) Although NASREQ was tested (well, not the tunneling AVPs), and as well as the Accounting extension, no issues were found in any of those I-Ds. Comments appreciated, PatC From owner-aaa-bof@merit.edu Fri Mar 9 10:31:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17451 for ; Fri, 9 Mar 2001 10:31:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C4275DFD6; Fri, 9 Mar 2001 10:27:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E1F815DFEE; Fri, 9 Mar 2001 10:27:49 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id CA8965DFD6 for ; Fri, 9 Mar 2001 10:27:46 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f29FRjd25362 for ; Fri, 9 Mar 2001 16:27:45 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Mar 09 16:29:22 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 9 Mar 2001 16:27:44 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEF2@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Key generation for MobileIP? Date: Fri, 9 Mar 2001 16:27:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, In section 5.3 from "draft-ietf-aaa-diameter-mobileip-01.txt", it says that: "If the home agent is in the home domain, then AAAH has to generate the Foreign-Home registration key. Otherwise, it is generated by AAAF." However, the rest of the section seems to suggest that the key generation should be performed in the AAAH. Can it be made clearer in the draft? I am confused about what should be done exactly, since my understanding was that keys should always be generated in the AAAH. Does the AAAH need to keep track of the registration keys for each session? Who should enforce the Authorization-Lifetime between the AAAH and the AAAF? Regards, Martin From owner-aaa-bof@merit.edu Fri Mar 9 11:00:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19091 for ; Fri, 9 Mar 2001 11:00:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 603675E181; Fri, 9 Mar 2001 10:52:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B48D95DE26; Fri, 9 Mar 2001 10:50:55 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AB9C05DE22 for ; Fri, 9 Mar 2001 10:41:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12360; Fri, 9 Mar 2001 07:41:18 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00637; Fri, 9 Mar 2001 07:41:17 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA26967; Fri, 9 Mar 2001 07:41:16 -0800 (PST) Date: Fri, 9 Mar 2001 07:36:47 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Key generation for MobileIP? To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEF2@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Hi, > > In section 5.3 from "draft-ietf-aaa-diameter-mobileip-01.txt", it says that: > > "If the home agent is in the home domain, then AAAH has to generate > the Foreign-Home registration key. Otherwise, it is generated by > AAAF." > > However, the rest of the section seems to suggest that the key generation > should be performed in the AAAH. Can it be made clearer in the draft? Interestingly enough, we did have a discussion about this, and I somehow forgot to include it in my report earlier today. It became clear at the meeting that the text discussing who generates the FA-HA keys is confusing when the HA is in the visited network, and does in fact need to be clarified. > I > am confused about what should be done exactly, since my understanding was > that keys should always be generated in the AAAH. Does the AAAH need to > keep track of the registration keys for each session? What do you mean by keep track? In any case, the AAAF generates the FA-HA keys when the HA is in the visited domain. However, if the HA is in a third domain (which occurs when the HA is allocated in a visited domain, and the user roams to another domain), the AAAH needs to allocate the keys. An alternative is to have the AAAH always allocate the keys, but when the HA is in the visited domain, the AAAF can overwrite those keys with its own set. > Who should enforce > the Authorization-Lifetime between the AAAH and the AAAF? Not sure I understand the question. The AAAH has the final say on the Authorization-Lifetime, however what I noticed at the bakeoff was that if such an AVP was present in the AMR from the FA or AAAF, the AAAH would only override this value if it's Authorization-Lifetime was smaller than the value received. It would never set the Authorization-Lifetime to a value greater than what was received. PatC From owner-aaa-bof@merit.edu Fri Mar 9 12:57:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26416 for ; Fri, 9 Mar 2001 12:57:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id 43AC05DE92; Fri, 9 Mar 2001 12:50:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9D5685DF30; Fri, 9 Mar 2001 12:50:28 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id 7D1DB5DE65 for ; Fri, 9 Mar 2001 12:48:10 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Fri, 9 Mar 2001 12:38:54 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GTRJ2H19; Fri, 9 Mar 2001 12:38:54 -0500 Received: from mitton.nortelnetworks.com (mitton.us.nortel.com [47.16.86.121]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id DWYWRNV8; Fri, 9 Mar 2001 12:38:53 -0500 Message-Id: <4.3.2.7.2.20010309123336.00c73200@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Mar 2001 12:40:40 -0500 To: aaa-wg@merit.edu, diameter@diameter.org From: "David Mitton" Subject: Re: [AAA-WG]: Diameter Issues wrt Vendor-Name Cc: pcalhoun@eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk At 3/9/01 10:15 AM -0500, Pat Calhoun wrote: >All, > >Here are some issues that were found in the protocol during the >interoperability testing that occurred this week. I would suggest that we fix >the protocol but would be interested in hearing any comments. > >1) Vendor-Id AVP (Base Protocol) > >Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. >This >now requires in order to implement Diameter, an enterprise number must be >received from IANA. This really doesn't make a whole lot of sense, and the >group felt that moving back to Vendor-Name was the correct approach. Further, >the Vendor-Name could also include some "product" information for those >vendors >that have many client and server products (e.g. say abc has FAs and NASes, as >well as a server). ... Two issues: 1) They will need an SMI code if they wish to implement any VSAs anyways. This has not been a problem for RADIUS manufacturers. More importantly they will need an SMI if they are doing any MIBs! Unfortunately, it seems that AAA programmers' don't usually know what the SNMP engineers are up to. 2) I would suggest that perhaps the better name for this AVP would be Product-ID, and that would remove some of the confusion with the AVP Vendor-ID header field. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Fri Mar 9 12:59:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26607 for ; Fri, 9 Mar 2001 12:59:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 568CC5DF1A; Fri, 9 Mar 2001 12:52:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 353365E00F; Fri, 9 Mar 2001 12:52:49 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by segue.merit.edu (Postfix) with ESMTP id 71F035DF1A for ; Fri, 9 Mar 2001 12:52:43 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA18040; Fri, 9 Mar 2001 09:52:40 -0800 (PST) Received: from johnalw2k (sj-dial-4-83.cisco.com [171.68.181.212]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ACU09692; Fri, 9 Mar 2001 09:52:30 -0800 (PST) From: "John Alayari" To: "Tony Johansson" , "Haseeb Akhtar" Cc: "'pcalhoun'" , "aaa-wg" , "diameter" Subject: RE: [AAA-WG]: Mobile IP Extension Date: Fri, 9 Mar 2001 09:51:43 -0800 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01C0A87E.8C01D590" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AA81421.6CAB3207@ericsson.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000E_01C0A87E.8C01D590 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hassib, How are you doing? Having AMR and AMR do different functions based on the session state is unusual. The implementation and maintenance of this in the server will not be easy. Also, this mandates servers to be stateful. I agree with Pat's solution so far. John Alayari. -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tony Johansson Sent: Thursday, March 08, 2001 3:22 PM To: Haseeb Akhtar Cc: 'pcalhoun'; aaa-wg; diameter Subject: Re: [AAA-WG]: Mobile IP Extension Hi Haseeb, I disagree with you. An AMR and an HAR are two different things. The AMR deals with user authentication and the HAR deals with HA assignment. We have been discussing this during the interop test even in San Jose and I strongly believe that the most logic way of doing this is as Pat describes it below. BR, /Tony Haseeb Akhtar wrote: Pat, I would like to propose we generalize AMR and AMA so that both of these messages can be used between all four entities involved (FA, AAAF, AAAH and HA) during registration. That way, we can truly ignore the geographical proximity between them and focus on their functional behavior. So, this is what the flow would look like. FA AAAF AAAH HA@visited_network -AMR-> -AMR-> <-AMA- --------AMR--------> <--------AMA-------- <-AMA- Granted, there are differences between the functions that needs to be performed after receiving AMR vs. HAR, however, the Session ID can keep the servers stateful. Also, you are having to open up the AAAF for both AMR/AMA and HAR/HAA interfaces in the option cited below. Combining them into one interface will, in my opinion, make a better protocol. Regards, Haseeb -----Original Message----- From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] Sent: Thursday, March 08, 2001 1:13 PM To: aaa-wg; diameter Subject: [AAA-WG]: Mobile IP Extension All, This is just a heads up on changes that are required in the Mobile IP Extension, as a result of the testing this week in San Jose. The Mobile IP extension currently defines the following signalling FA AAAF AAAH HA -AMR-> -AMR-> -HAR-> <-AMA- <-AMA- <-HAA- However, if the Home Agent is assigned in the visited network, the following signalling is mandated: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -AMA-> -HAR-> <------------AMA---------- <-HAA- <-HAI- We had originally decided to do this to reduce the number of round trips to the AAAH. In the above scenario, the AAAH authenticates the mobile, generates keys, and replies back to the AAAF. The AAAH is not contacted again until the HAI is sent to inform the AAAH of the status of the request. However, this scheme, while reducing round trips, does require that HAR-ish AVPs are present in the AMA. This really makes the protocol quite complicated, and further requires that the HAI include some success result code. This means that in order to save round trips, we end up abusing protocol messages. Therefore, after discussin this over with people that have implemented it, we decided that protocol complexity did not justify this, and we reverted back to what was in the spec some time back, which is: FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- This means that the signalling is exactly the same, whether the Home Agent is in the home or visited network. Furthermore, it makes it VERY simple to also handle the case where the Home Agent is in a third network, as below: (3rd domain) FA AAAF AAAH AAAF HA -AMR-> -AMR-> -HAR-> -HAR-> <-AMA- <-AMA- <-HAA- <-HAA- Anyone object to the above changes in the -02 of the Mobile IP extension? Again, implementors found this to be the simplest. Thanks, PatC ------=_NextPart_000_000E_01C0A87E.8C01D590 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hassib,
 
How=20 are you doing? Having AMR and AMR do different functions based on=20 the session state is unusual. The implementation and = maintenance=20 of this in the server will not be easy. Also, this mandates servers = to be=20 stateful. I agree with Pat's solution so far. 
 
John=20 Alayari. 
-----Original Message-----
From: = owner-aaa-bof@merit.edu=20 [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tony=20 Johansson
Sent: Thursday, March 08, 2001 3:22 = PM
To:=20 Haseeb Akhtar
Cc: 'pcalhoun'; aaa-wg; = diameter
Subject:=20 Re: [AAA-WG]: Mobile IP Extension

Hi Haseeb,=20

I disagree with you. An AMR and an HAR are two different things. = The AMR=20 deals with user authentication and the HAR deals with HA assignment. = We have=20 been discussing this during the interop test even in San Jose and I = strongly=20 believe that the most logic way of doing this is as Pat describes it = below.=20

BR,=20

/Tony=20

Haseeb Akhtar wrote:=20

 =20

Pat,=20

I would like to propose we generalize AMR and = AMA=20
so that both of these messages can be used = between=20
all four entities involved (FA, AAAF, AAAH and = HA)=20 during
registration. That way, we can = truly ignore=20 the
geographical proximity between them = and focus=20 on their
functional behavior.=20

So, this is what the flow would look like. =

FA          &= nbsp;  =20 = AAAF           =20 AAAH    HA@visited_network
 =20 = -AMR->          &nbs= p;    =20 -AMR->
          &nb= sp;           &nbs= p;=20 <-AMA-=20 =
           &nb= sp;           =20 --------AMR-------->=20 =
           &nb= sp;           =20 <--------AMA--------
 =20 <-AMA-=20

Granted, there are differences between the = functions=20 that
needs to be performed after = receiving AMR vs.=20 HAR, however,
the Session ID can keep the = servers=20 stateful.=20

Also, you are having to open up the AAAF for both = AMR/AMA
and HAR/HAA interfaces in the = option cited=20 below. Combining
them into one interface = will, in=20 my opinion, make a better
protocol.=20

Regards,=20

Haseeb
 =20

-----Original Message-----
From:=20 Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Su= n.COM]=20
Sent: Thursday, March 08, 2001 1:13 PM =
To: aaa-wg; diameter
Subject: = [AAA-WG]:=20 Mobile IP Extension=20

All,=20

This is just a heads up on changes that are = required in the=20 Mobile IP Extension,
as a result of the = testing=20 this week in San Jose.=20

The Mobile IP extension currently defines the = following=20 signalling=20

FA      =20 AAAF      = AAAH     =20 HA
   = -AMR->   =20 -AMR->    -HAR->
  =20 <-AMA-    <-AMA-    = <-HAA-=20

However, if the Home Agent is assigned in the = visited=20 network, the
following signalling is=20 mandated:=20

FA      =20 AAAF      = AAAH     =20 AAAF      HA
  =20 -AMR->    -AMR->   =20 -AMA->    -HAR->
  =20 <------------AMA----------    <-HAA- =
          &nb= sp;           &nbs= p;=20 <-HAI-=20

We had originally decided to do this to reduce = the number=20 of round trips to
the AAAH. In the above = scenario,=20 the AAAH authenticates the mobile, generates
keys,=20 and replies back to the AAAF. The AAAH is not contacted again until=20 the
HAI is sent to inform the AAAH of the = status of=20 the request.=20

However, this scheme, while reducing round trips, = does=20 require that HAR-ish
AVPs are present in = the AMA.=20 This really makes the protocol quite complicated,
and further requires that the HAI include some success = result code.=20 This
means that in order to save round = trips, we=20 end up abusing protocol messages.=20

Therefore, after discussin this over with people = that have=20 implemented it, we
decided that protocol = complexity=20 did not justify this, and we reverted back
to what=20 was in the spec some time back, which is:
FA      =20 AAAF      = AAAH     =20 AAAF      HA
  =20 -AMR->    -AMR->   =20 -HAR->    -HAR->
  =20 <-AMA-    <-AMA-   =20 <-HAA-    <-HAA-=20

This means that the signalling is exactly the = same, whether=20 the Home Agent is
in the home or visited = network.=20 Furthermore, it makes it VERY simple to also
handle=20 the case where the Home Agent is in a third network, as = below:=20

          &nb= sp;           &nbs= p;      =20 (3rd domain)
FA      =20 AAAF      = AAAH     =20 AAAF      HA
  =20 -AMR->    -AMR->   =20 -HAR->    -HAR->
  =20 <-AMA-    <-AMA-   =20 <-HAA-    <-HAA-=20

Anyone object to the above changes in the -02 of = the Mobile=20 IP extension? Again,
implementors found = this to be=20 the simplest.=20

Thanks,=20

PatC=20
 

------=_NextPart_000_000E_01C0A87E.8C01D590-- From owner-aaa-bof@merit.edu Fri Mar 9 13:47:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29217 for ; Fri, 9 Mar 2001 13:47:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23F225DF50; Fri, 9 Mar 2001 13:46:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 68FF05DFF6; Fri, 9 Mar 2001 13:44:55 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 2872B5E332 for ; Fri, 9 Mar 2001 13:33:53 -0500 (EST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 9 Mar 2001 12:33:13 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Mar 2001 12:33:12 -0600 Message-ID: From: "Haseeb Akhtar" To: "'John Alayari'" , Tony Johansson Cc: "'pcalhoun'" , aaa-wg , diameter Subject: RE: [AAA-WG]: Mobile IP Extension Date: Fri, 9 Mar 2001 12:33:07 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A8C7.627D48F0" Sender: owner-aaa-bof@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_01C0A8C7.627D48F0 Content-Type: text/plain; charset="iso-8859-1" All, Yes, I do realize that implementing multiple functions in one message may increase complexity. However, what we gain is the reduction in round trip delay - specially for the case when the HA has to be allocated in the visited network. As far as the servers being stateful, well, they already are. That's why Diameter has the concept of Session Termination (section 11.7 of the Base). Although AMR deals with user authentication (MN-AAA), the HAR too carries Mobile IP user authentication information (MN-HA, FA-HA, MN-HA etc.). That is, HAR does not ONLY deal with HA assignment. I did not quite understand Pat's comment as to why this approach with make it difficult to have single code base that supports both client and server side. Regards, Haseeb Hassib, How are you doing? Having AMR and AMR do different functions based on the session state is unusual. The implementation and maintenance of this in the server will not be easy. Also, this mandates servers to be stateful. I agree with Pat's solution so far. John Alayari. -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tony Johansson Sent: Thursday, March 08, 2001 3:22 PM To: Haseeb Akhtar Cc: 'pcalhoun'; aaa-wg; diameter Subject: Re: [AAA-WG]: Mobile IP Extension Hi Haseeb, I disagree with you. An AMR and an HAR are two different things. The AMR deals with user authentication and the HAR deals with HA assignment. We have been discussing this during the interop test even in San Jose and I strongly believe that the most logic way of doing this is as Pat describes it below. BR, /Tony hmmmm.... I recall having this discussion, and I am quite sure that my response will be the same. I really do not care much for messages that have to be treated completely differently, based on whether the receiver is a home server or a home agent. Your proposal makes it REALLY hard to have a single code base, that supports both client and server side (NAS/FA and AAAH). Anyone else? PatC ------_=_NextPart_001_01C0A8C7.627D48F0 Content-Type: text/html; charset="iso-8859-1"
All,
 
Yes, I do realize that implementing multiple functions in one message
may increase complexity. However, what we gain is the reduction in
round trip delay - specially for the case when the HA has to be allocated
in the visited network.
 
As far as the servers being stateful, well, they already are. That's why Diameter
has the concept of Session Termination (section 11.7 of the Base).
 
Although AMR deals with user authentication (MN-AAA), the HAR too carries
Mobile IP user authentication information (MN-HA, FA-HA, MN-HA etc.).  That
is, HAR does not ONLY deal with HA assignment.
 
I did not quite understand Pat's comment as to why this approach with make it
difficult to have single code base that supports both client and server side.
 
Regards,
 
Haseeb
 
 
Hassib,
 
How are you doing? Having AMR and AMR do different functions based on the session state is unusual. The implementation and maintenance of this in the server will not be easy. Also, this mandates servers to be stateful. I agree with Pat's solution so far. 
 
John Alayari. 
-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tony Johansson
Sent: Thursday, March 08, 2001 3:22 PM
To: Haseeb Akhtar
Cc: 'pcalhoun'; aaa-wg; diameter
Subject: Re: [AAA-WG]: Mobile IP Extension

Hi Haseeb,

I disagree with you. An AMR and an HAR are two different things. The AMR deals with user authentication and the HAR deals with HA assignment. We have been discussing this during the interop test even in San Jose and I strongly believe that the most logic way of doing this is as Pat describes it below.

BR,

/Tony

 

hmmmm.... I recall having this discussion, and I am quite sure that my response

will be the same.

I really do not care much for messages that have to be treated completely

differently, based on whether the receiver is a home server or a home agent.

Your proposal makes it REALLY hard to have a single code base, that supports

both client and server side (NAS/FA and AAAH).

Anyone else?

PatC

------_=_NextPart_001_01C0A8C7.627D48F0-- From owner-aaa-bof@merit.edu Fri Mar 9 13:48:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29254 for ; Fri, 9 Mar 2001 13:48:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD17D5DE76; Fri, 9 Mar 2001 13:46:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B8FD95DF20; Fri, 9 Mar 2001 13:46:13 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 7A14B5DF09 for ; Fri, 9 Mar 2001 13:40:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06412; Fri, 9 Mar 2001 10:38:31 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06757; Fri, 9 Mar 2001 10:38:27 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA09962; Fri, 9 Mar 2001 10:38:26 -0800 (PST) Date: Fri, 9 Mar 2001 10:38:26 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Diameter Issues wrt Vendor-Name To: David Mitton Cc: aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" <4.3.2.7.2.20010309123336.00c73200@ZBL6C008.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > At 3/9/01 10:15 AM -0500, Pat Calhoun wrote: > > >All, > > > >Here are some issues that were found in the protocol during the > >interoperability testing that occurred this week. I would suggest that we > fix >the protocol but would be interested in hearing any comments. > > > >1) Vendor-Id AVP (Base Protocol) > > > >Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. > >This > >now requires in order to implement Diameter, an enterprise number must be > >received from IANA. This really doesn't make a whole lot of sense, and the > >group felt that moving back to Vendor-Name was the correct approach. > Further, >the Vendor-Name could also include some "product" information for > those >vendors > >that have many client and server products (e.g. say abc has FAs and NASes, > as >well as a server). > ... > > Two issues: > > 1) They will need an SMI code if they wish to implement any VSAs > anyways. This has not been a problem for RADIUS manufacturers. More > importantly they will need an SMI if they are doing any > MIBs! Unfortunately, it seems that AAA programmers' don't usually know > what the SNMP engineers are up to. Right, but a manufacturer that wants to only sell servers, or perhaps doesn't want VSAs, shouldn't need an SMI code simply to implement the protocol, right? > 2) I would suggest that perhaps the better name for this AVP would be > Product-ID, and that would remove some of the confusion with the AVP > Vendor-ID header field. ok. PatC From owner-aaa-bof@merit.edu Fri Mar 9 20:40:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA13223 for ; Fri, 9 Mar 2001 20:40:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 20E425DE44; Fri, 9 Mar 2001 20:37:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F12695DE9A; Fri, 9 Mar 2001 20:37:47 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id BBE4F5DE44 for ; Fri, 9 Mar 2001 20:37:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20182; Fri, 9 Mar 2001 17:36:19 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05819; Fri, 9 Mar 2001 17:36:18 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA16140; Fri, 9 Mar 2001 17:36:15 -0800 (PST) Date: Fri, 9 Mar 2001 17:31:45 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Mobile IP Extension To: Haseeb Akhtar Cc: "'John Alayari'" , Tony Johansson , "'pcalhoun'" , aaa-wg , diameter In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Yes, I do realize that implementing multiple functions in one message > may increase complexity. However, what we gain is the reduction in > round trip delay - specially for the case when the HA has to be allocated > in the visited network. well, the draft, as it stands already has this, but at the expense of message abuse (meaning the intent of a message is not clear by its command code, guessing is involved) and complexity. > > As far as the servers being stateful, well, they already are. That's why > Diameter > has the concept of Session Termination (section 11.7 of the Base). not necessarily. The protocol allows for servers to be stateful, but my server is in fact quite stateless. People at connectathon were in fact surprised at how little state my server has. This, btw, was intentional in order to validate whether such an implementation is at all possible. I would hate to disallow such implementations... > Although AMR deals with user authentication (MN-AAA), the HAR too carries > Mobile IP user authentication information (MN-HA, FA-HA, MN-HA etc.). That > is, HAR does not ONLY deal with HA assignment. It is used to hand a Registration request to the HA. That's what the HAR is all about. There is no authentication/authorization of the user, since this is done in the AAAH (as a result of the reception of the AMR). > I did not quite understand Pat's comment as to why this approach with make > it > difficult to have single code base that supports both client and server > side. > Sorry, I was a little vague here. My point was close to Tony's. I know that when my Diameter code receives an AMR, and the Destination-Realm is set to my own realm, I can handle that message, authenticate/authorize the user, generate keys if necessary, and then hunt for a home agent. My code also knows that when an HAR is received, and the Destination-FQDN is set to the local hostname, it is to be handed off to the Mobile Agent process. If both messages were AMRs, I am not sure how I would *know* whether to authenticate the user, or hand the RegReq to the mobility agent. Hope that makes more sense, PatC From owner-aaa-bof@merit.edu Mon Mar 12 10:47:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12404 for ; Mon, 12 Mar 2001 10:47:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 58B015DE65; Mon, 12 Mar 2001 10:44:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 38D2C5DED7; Mon, 12 Mar 2001 10:44:25 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EC2605DE65 for ; Mon, 12 Mar 2001 10:44:23 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17124; Mon, 12 Mar 2001 07:44:23 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21815; Mon, 12 Mar 2001 07:44:22 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA04869; Mon, 12 Mar 2001 07:44:21 -0800 (PST) Date: Mon, 12 Mar 2001 07:39:49 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Comments on draft-kaushik-diameter-strong-sec-01.txt To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com, kaushik@cisco.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I have some comments, questions and nits on the above I-D. 1. Some time back on the list, we agreed that Diameter was not all uppercase, since it wasn't an acronym (although many suggestions were proposed). You will want to fix your I-D to use "Diameter" instead of "DIAMETER". 2. "The ROAMOPS Working Group has defined a requirement that allows for the DIAMETER servers..." doesn't quite sound right. A requirement doesn't "allow" for something, but requires a feature. 3. "This specification introduces the 'P' bit in the AVP Header, which is defined in [1]." This is a contradictory sentence. First you state it is introduced here, and defined in the base. You may want to clean up this sentence. Perhaps "This specification makes use of the 'P' bit in the AVP Header, which is defined in [1]." 4. Not being a Kerberos expert, I find that the text in section 3.0 is very confusing. You have the sentence "The KRB-PRIV message carries the Diameter AVPs encrypted in the Session Key." What does this mean? Why are AVPs encryped in a session key? (I assume this is a typo). So if I can assume what you meant here, the AVPs are encrypted inside the KRB-PRIV, using a session key. Further, the KRB-PRIV has a reference to EncryptedData, but the paragraph following that states that this field really contains the EncKrbPrivPart. So which one is it? I would think it is EncryptedData, since it is the only one that has a reference to the CipherText. The sentence "The enc-part holds an encoding of the EncKrbPrivPart sequence encrypted under the session key" needs to be clarified. When you state something is encrypted under a session key, do you really mean it is encrypted using a session key, or is this some kind of binding that I am unaware of? 5. Section 4.0 is much simpler to understand, but I don't see anywhere where a reference to a key is made. Is there an assumption that only one key is pending at any given time, or is one of the those fields a key identifier? 6. I have questions in regards to the following paragraph, which shows up in section 5.0: " The DIAMTER client uses the kerberos service principal for service discovery i.e. to discover the capability of a DIAMETER server to support Kerberos. Since the kerberos service principal is defined per DIAMETER server or proxy only Kerberized DIAMETER servers or proxies would have the service principals registered with the KDC. The KRB_TGS_REQ would fail trying to obtain a ticket for a non Kerberized DIAMETER server or proxy and the NAS would revert back to using the "normal" DIAMETER operation as defined in RFC 2865." First, it sounds like a NAS would send a Kerberos message to a Diameter server, which would fail if it didn't support Kerberos. What exactly does this mean? A Diameter server only handles Diameter messages. Are you instead stating that a Kerberos message is sent to the Kerberos server on the same physical entity that is running Diameter? If so, you will want to make that clearer, as my read of this sounded like Diameter was also handling Kerb messages. Second, RFC 2865 is an obvious cut and paste error from another I-D :) 7. The following paragraph disturbs me quite a bit: " A valid cross domain Ticket Granting Ticket(TGT) must be cached on the DIAMETER client prior to sending a Kerberized DIAMETER request. Cross domain TGT acquisition is out of the scope of this draft and can happen based on inter domain trust or public key extensions like PKCROSS can be employed to obtain cross realm TGTs. " When you presented your proposal in AAA, and at the Interim meeting, you also sort-of hand-waved on this area. Although I understand why you state it is outside the scope of this specification, the casual Diameter reader could be fooled by not understanding what this means in terms of signaling through the Internet. I think that it would be quite useful to show the basic security relationships that are required between the entities, and how the cross-realm TGTs are established. This is really crucial in the deployment, and shouldn't be brushed off as out of scope. In fact, I would highly recommend that this text even shows up prior to the BNF definitions, and has its own section. Now that I think of it, I don't see why section 3 and 4 aren't pushed towards the end of the document. Reading the BNF structures without understanding what is being done is the wrong approach IMHO. 8. Please fix up the following text in section 5 "... a KRB_TGS_REQ to the Ticket Granting Service (TGS) in order to the service principal ticket for the DIAMETER server." 9. I am quite confused here. Section 5.0 contains: "The Kerberized DIAMETER operation would mostly involve dynamic symmetric key negotiation between DIAMETER peers using the Kerberos Application exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated would then be used to provide integrity protection and privacy protection for the DIAMETER AVPs." So it sounds like symmetric keys are what's being distributed, right? If so, then why the following text in section 2.0: "The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation is a requirement for AAA data, such as accounting records." How can non-repudiation be achieved if both sides have the same key? 10. The following paragraph is plagued with cut and paste error from the RADIUS draft: "In routing the Access-Request to the home DIAMETER server, the NAI is typically used, as described in RFC 2486..." 11. The following text describes how Diameter server discovery can be made. I can understand why this was done in RADIUS, given that it never bothered to specify how servers are discovered. However, the base protocol has a section on server discovery. Could you check whether the text in the base protocol is not sufficient, and whether section 3.4 is still required? "The hostname and port of a DIAMETER homeserver can be determined as described in the section 3.4." 12. Remove "of" in "The NAS will start of by creating a KRB_AP_REQ message..." 13. The text reads "... Kerberos-Endtoend-Auth AVP ..." However, I thought at the meeting you claimed that your proposal make use of the ICV and Encrypted-Payload AVPs. is this the case? If not, I can remove these AVPs from the base protocol. I had left them in the -01 in case your proposal was chosen, and I didn't want to have to rip out text, and put it back in -02. Some guidance would be appreciated. Wait! I read further and now I am confused. Is the following correct? Kerberos-Endtoend-Auth AVP is used to carry Kerberos payload used to establish the session key? If so, is this sent in parallel with any request? This isn't clear to me. If it is not sent in parallel, when is it sent? In which Diameter message? The "if end-to-end security is used, then an..." talks about an Integrity Checksum. Is this something present in the ICV or something else? 14. s/SHOULD not/SHOULD NOT/ 15. The following "DIAMETER proxies SHOULD not modify the Kerberos-Data AVP and the Kerberos-Endtoend-Auth AVP since this AVP is meant for DIAMETER end servers." How does a server know it is an end server, and specifically *the* intended end server? Is there some identity hidden somewhere in an AVP that states that the end destination of the message is in order to proxies to know where to send the message? 16. It is now clear to me that a terminology section would be really useful. Perhaps the most commonly used term in this I-D could be defined at the beginning. You claim that a kerberos session key is the same as the client session key, but I know that some RADIUS and Diameter people will get confused if they've ever used the common RADIUS source base, which includes the clients file, which also contains the secret. I am proposing this to reduce any possible confusion on the part of the reader. 17. "In case of an error in Kerberos authentication, an Access-Reject is sent with a Kerberos-Endtoend-Auth AVP containing the KRB_ERROR message in the Kerberos authentication TLV." Cut and paste error. Again, is this done in parallel with a valid request, or prior to? If prior to, then a new message set should be created. 18. The AVP codes assigned conflict with the Mobile IP extension, and with each other :) 19. Copyright year should be 2001. PatC From owner-aaa-bof@merit.edu Mon Mar 12 11:24:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13201 for ; Mon, 12 Mar 2001 11:24:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1C6255DDA1; Mon, 12 Mar 2001 11:23:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 078605DE67; Mon, 12 Mar 2001 11:23:08 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 57F8F5DDA1 for ; Mon, 12 Mar 2001 11:23:05 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id VAA03285; Mon, 12 Mar 2001 21:51:50 +0530 (IST) From: Kaushik Narayan Message-Id: <200103121621.VAA03285@cisco.com> Subject: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt To: pcalhoun@nasnfs.Eng.Sun.COM Date: Mon, 12 Mar 2001 21:51:50 +0530 (IST) Cc: aaa-wg@merit.edu, kaushik@cisco.com (Kaushik Narayan) In-Reply-To: from "Pat Calhoun" at Mar 12, 2001 07:39:49 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat, hi! Thanks a lot for your comments. I will clean up the draft and respond to your questions. I have been working on changing this draft to use GSSAPI for Diameter security instead of raw kerberos which would be the proposed solution. That's the reason I didnot originally send this draft on the list. kaushik! > Hi, > > I have some comments, questions and nits on the above I-D. > > 1. Some time back on the list, we agreed that Diameter was not all uppercase, > since it wasn't an acronym (although many suggestions were proposed). You will > want to fix your I-D to use "Diameter" instead of "DIAMETER". > > 2. "The ROAMOPS Working Group has defined a requirement that allows for > the DIAMETER servers..." doesn't quite sound right. A requirement doesn't > "allow" for something, but requires a feature. > > 3. "This specification introduces the 'P' bit in the AVP Header, which is > defined in [1]." This is a contradictory sentence. First you state it is > introduced here, and defined in the base. You may want to clean up this > sentence. Perhaps "This specification makes use of the 'P' bit in the AVP > Header, which is defined in [1]." > > 4. Not being a Kerberos expert, I find that the text in section 3.0 is very > confusing. You have the sentence "The KRB-PRIV message carries the Diameter > AVPs encrypted in the Session Key." What does this mean? Why are AVPs encryped > in a session key? (I assume this is a typo). > > So if I can assume what you meant here, the AVPs are encrypted inside the > KRB-PRIV, using a session key. > > Further, the KRB-PRIV has a reference to EncryptedData, but the paragraph > following that states that this field really contains the EncKrbPrivPart. So > which one is it? I would think it is EncryptedData, since it is the only one > that has a reference to the CipherText. > > The sentence "The enc-part holds an encoding of the EncKrbPrivPart sequence > encrypted under the session key" needs to be clarified. When you state > something is encrypted under a session key, do you really mean it is encrypted > using a session key, or is this some kind of binding that I am unaware of? > > 5. Section 4.0 is much simpler to understand, but I don't see anywhere where a > reference to a key is made. Is there an assumption that only one key is > pending at any given time, or is one of the those fields a key identifier? > > 6. I have questions in regards to the following paragraph, which shows up in > section 5.0: > > " The DIAMTER client uses the kerberos service principal for service > discovery i.e. to discover the capability of a DIAMETER server to > support Kerberos. Since the kerberos service principal is defined > per DIAMETER server or proxy only Kerberized DIAMETER servers or > proxies would have the service principals registered with the KDC. > The KRB_TGS_REQ would fail trying to obtain a ticket for a non > Kerberized DIAMETER server or proxy and the NAS would revert back > to using the "normal" DIAMETER operation as defined in RFC 2865." > > First, it sounds like a NAS would send a Kerberos message to a Diameter > server, which would fail if it didn't support Kerberos. What exactly does this > mean? A Diameter server only handles Diameter messages. Are you instead > stating that a Kerberos message is sent to the Kerberos server on the same > physical entity that is running Diameter? If so, you will want to make that > clearer, as my read of this sounded like Diameter was also handling Kerb > messages. > > Second, RFC 2865 is an obvious cut and paste error from another I-D :) > > 7. The following paragraph disturbs me quite a bit: > > " A valid cross domain Ticket Granting Ticket(TGT) must be cached on > the DIAMETER client prior to sending a Kerberized DIAMETER request. > Cross domain TGT acquisition is out of the scope of this draft and > can happen based on inter domain trust or public key extensions > like PKCROSS can be employed to obtain cross realm TGTs. " > > When you presented your proposal in AAA, and at the Interim meeting, you also > sort-of hand-waved on this area. Although I understand why you state it is > outside the scope of this specification, the casual Diameter reader could be > fooled by not understanding what this means in terms of signaling through the > Internet. I think that it would be quite useful to show the basic security > relationships that are required between the entities, and how the cross-realm > TGTs are established. This is really crucial in the deployment, and shouldn't > be brushed off as out of scope. > > In fact, I would highly recommend that this text even shows up prior to the > BNF definitions, and has its own section. Now that I think of it, I don't see > why section 3 and 4 aren't pushed towards the end of the document. Reading the > BNF structures without understanding what is being done is the wrong approach > IMHO. > > 8. Please fix up the following text in section 5 "... a KRB_TGS_REQ to the > Ticket Granting Service (TGS) in order to the service principal ticket for the > DIAMETER server." > > 9. I am quite confused here. Section 5.0 contains: > > "The Kerberized > DIAMETER operation would mostly involve dynamic symmetric key > negotiation between DIAMETER peers using the Kerberos Application > exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated > would then be used to provide integrity protection and privacy > protection for the DIAMETER AVPs." > > So it sounds like symmetric keys are what's being distributed, right? If so, > then why the following text in section 2.0: > > "The Mobile-IP and NASREQ > Working Groups have stated in [6, 7, 8] that non-repudiation is a > requirement for AAA data, such as accounting records." > > How can non-repudiation be achieved if both sides have the same key? > > 10. The following paragraph is plagued with cut and paste error from the > RADIUS draft: "In routing the Access-Request to the home DIAMETER server, the > NAI is typically used, as described in RFC 2486..." > > 11. The following text describes how Diameter server discovery can be made. I > can understand why this was done in RADIUS, given that it never bothered to > specify how servers are discovered. However, the base protocol has a section > on server discovery. Could you check whether the text in the base protocol is > not sufficient, and whether section 3.4 is still required? > > "The hostname and port of a DIAMETER homeserver can be determined as described > in the section 3.4." > > 12. Remove "of" in "The NAS will start of by creating a KRB_AP_REQ message..." > > 13. The text reads "... Kerberos-Endtoend-Auth AVP ..." However, I thought at > the meeting you claimed that your proposal make use of the ICV and > Encrypted-Payload AVPs. is this the case? If not, I can remove these AVPs from > the base protocol. I had left them in the -01 in case your proposal was > chosen, and I didn't want to have to rip out text, and put it back in -02. > Some guidance would be appreciated. > > Wait! I read further and now I am confused. Is the following correct? > > Kerberos-Endtoend-Auth AVP is used to carry Kerberos payload used to establish > the session key? If so, is this sent in parallel with any request? This isn't > clear to me. If it is not sent in parallel, when is it sent? In which Diameter > message? > > The "if end-to-end security is used, then an..." talks about an Integrity > Checksum. Is this something present in the ICV or something else? > > 14. s/SHOULD not/SHOULD NOT/ > > 15. The following "DIAMETER proxies SHOULD not modify the Kerberos-Data AVP > and the Kerberos-Endtoend-Auth AVP since this AVP is meant for DIAMETER end > servers." How does a server know it is an end server, and specifically *the* > intended end server? Is there some identity hidden somewhere in an AVP that > states that the end destination of the message is in order to proxies to know > where to send the message? > > 16. It is now clear to me that a terminology section would be really useful. > Perhaps the most commonly used term in this I-D could be defined at the > beginning. You claim that a kerberos session key is the same as the client > session key, but I know that some RADIUS and Diameter people will get confused > if they've ever used the common RADIUS source base, which includes the clients > file, which also contains the secret. I am proposing this to reduce any > possible confusion on the part of the reader. > > 17. "In case of an error in Kerberos authentication, an Access-Reject is sent > with a Kerberos-Endtoend-Auth AVP containing the KRB_ERROR message in the > Kerberos authentication TLV." Cut and paste error. Again, is this done in > parallel with a valid request, or prior to? If prior to, then a new message > set should be created. > > 18. The AVP codes assigned conflict with the Mobile IP extension, and with > each other :) > > 19. Copyright year should be 2001. > > PatC > > From owner-aaa-bof@merit.edu Mon Mar 12 11:26:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13260 for ; Mon, 12 Mar 2001 11:26:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 44DCB5DF00; Mon, 12 Mar 2001 11:25:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 30AF85DEFC; Mon, 12 Mar 2001 11:25:08 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id E1B315DEFA for ; Mon, 12 Mar 2001 11:25:06 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 3009F74; Mon, 12 Mar 2001 11:25:21 -0500 (EST) Message-ID: <3AACF84B.23D8C8E0@Interlinknetworks.com> Date: Mon, 12 Mar 2001 11:24:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com Subject: Re: [AAA-WG]: Diameter Issues found @ Connectathon References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: >... > 1) Vendor-Id AVP (Base Protocol) > > Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This > now requires in order to implement Diameter, an enterprise number must be > received from IANA. This really doesn't make a whole lot of sense, and the > group felt that moving back to Vendor-Name was the correct approach. Further, > the Vendor-Name could also include some "product" information for those vendors > that have many client and server products (e.g. say abc has FAs and NASes, as > well as a server). >... I like Vendor-ID. It is not hard to apply for one. And you need one anyway to insert in the Vendor-ID field of the AVP header. If you use an unregistered, free-format identifier in a Vendor-Name AVP and a different, registered, fixed-format identifier in the Vendor-ID field of the AVP headers, how am I supposed to match them? Keep it consistent throughout. Use the IANA-registered enterprise numbers. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Mar 12 11:35:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13510 for ; Mon, 12 Mar 2001 11:35:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 898CE5DF40; Mon, 12 Mar 2001 11:33:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 74BD55DF5A; Mon, 12 Mar 2001 11:33:32 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 517BD5DF40 for ; Mon, 12 Mar 2001 11:33:31 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 8E54174; Mon, 12 Mar 2001 11:33:45 -0500 (EST) Message-ID: <3AACFA43.4ECD0FBA@Interlinknetworks.com> Date: Mon, 12 Mar 2001 11:33:07 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: David Mitton , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com Subject: Re: [AAA-WG]: Diameter Issues wrt Vendor-Name References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun replied to David Mitton: >... > > Two issues: > > > > 1) They will need an SMI code if they wish to implement any VSAs > > anyways. This has not been a problem for RADIUS manufacturers. More > > importantly they will need an SMI if they are doing any > > MIBs! Unfortunately, it seems that AAA programmers' don't usually know > > what the SNMP engineers are up to. > > Right, but a manufacturer that wants to only sell servers, or perhaps doesn't > want VSAs, shouldn't need an SMI code simply to implement the protocol, right? >... So make the Vendor-ID AVP optional. Only include it if there are vendor-specific AVPs or command codes that the equipment understands or may send. Otherwise it doesn't matter. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Mar 12 11:43:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13690 for ; Mon, 12 Mar 2001 11:43:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6A6565DE45; Mon, 12 Mar 2001 11:42:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4E7F45DE5A; Mon, 12 Mar 2001 11:42:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 165FF5DE45 for ; Mon, 12 Mar 2001 11:42:57 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01627; Mon, 12 Mar 2001 08:42:54 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25250; Mon, 12 Mar 2001 08:42:53 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA05657; Mon, 12 Mar 2001 08:42:51 -0800 (PST) Date: Mon, 12 Mar 2001 08:38:19 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Diameter Issues found @ Connectathon To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" <3AACF84B.23D8C8E0@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > 1) Vendor-Id AVP (Base Protocol) > > > > Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This > > now requires in order to implement Diameter, an enterprise number must be > > received from IANA. This really doesn't make a whole lot of sense, and the > > group felt that moving back to Vendor-Name was the correct approach. Further, > > the Vendor-Name could also include some "product" information for those vendors > > that have many client and server products (e.g. say abc has FAs and NASes, as > > well as a server). > >... > > I like Vendor-ID. It is not hard to apply for one. And you need one anyway > to insert in the Vendor-ID field of the AVP header. Only if you plan to send vendor-specific AVPs, and I would claim that there are plenty of RADIUS implementations that support RFC-only attributes. So requiring that one gets an SMI seems unnecessary. > If you use an > unregistered, free-format identifier in a Vendor-Name AVP and a different, > registered, fixed-format identifier in the Vendor-ID field of the AVP > headers, how am I supposed to match them? Why would you need to match them? You cannot really use the Vendor-Id in the DRI to know what vendor-specific AVPs are supported, since an implementation may in fact support many vendor-specific AVPs from many different vendors. > Keep it consistent throughout. > Use the IANA-registered enterprise numbers. > Consistency is good, but only if used for the same purpose. The intent of the vendor-id in the DRI is only to know the manufacturer of the implementation or device, nothing else. > So make the Vendor-ID AVP optional. Only include it if there are > vendor-specific AVPs or command codes that the equipment understands or may > send. Otherwise it doesn't matter. ok, so if I understand correctly, in the DRI the Vendor-Name represents the name of the manufacturer, and the vendor-id would state which manufacturer's vendor-specific AVPs are supported. Is this correct? PatC From owner-aaa-bof@merit.edu Mon Mar 12 12:29:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14907 for ; Mon, 12 Mar 2001 12:29:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 538E95DEC1; Mon, 12 Mar 2001 12:24:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 239AC5DEBF; Mon, 12 Mar 2001 12:24:05 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 17E2E5DF13 for ; Mon, 12 Mar 2001 12:20:24 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 4311274; Mon, 12 Mar 2001 12:20:38 -0500 (EST) Message-ID: <3AAD0540.BEEC79DB@Interlinknetworks.com> Date: Mon, 12 Mar 2001 12:20:00 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com Subject: Re: [AAA-WG]: Diameter Issues found @ Connectathon References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I guess I was assuming that the purpose for putting vendor information in the DRI was to allow a Diameter peer to signal which vendor specific AVPs and command codes it understands. Of course I could configure that in my "Clients file", but in that case I could configure the manufacturer's name too. I certainly don't mind a text Vendor-Name AVP that could be used for logging purposes, but I think it might be useful to send zero or more Vendor-Id AVPs to indicate the enterprise numbers of the supported vendor-specific protocol elements as well. Pat Calhoun wrote: > > > > 1) Vendor-Id AVP (Base Protocol) > > > > > > Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This > > > now requires in order to implement Diameter, an enterprise number must be > > > received from IANA. This really doesn't make a whole lot of sense, and the > > > group felt that moving back to Vendor-Name was the correct approach. Further, > > > the Vendor-Name could also include some "product" information for those vendors > > > that have many client and server products (e.g. say abc has FAs and NASes, as > > > well as a server). > > >... > > > > I like Vendor-ID. It is not hard to apply for one. And you need one anyway > > to insert in the Vendor-ID field of the AVP header. > > Only if you plan to send vendor-specific AVPs, and I would claim that there > are plenty of RADIUS implementations that support RFC-only attributes. So > requiring that one gets an SMI seems unnecessary. > > > If you use an > > unregistered, free-format identifier in a Vendor-Name AVP and a different, > > registered, fixed-format identifier in the Vendor-ID field of the AVP > > headers, how am I supposed to match them? > > Why would you need to match them? You cannot really use the Vendor-Id in the > DRI to know what vendor-specific AVPs are supported, since an implementation > may in fact support many vendor-specific AVPs from many different vendors. > > > Keep it consistent throughout. > > Use the IANA-registered enterprise numbers. > > > > Consistency is good, but only if used for the same purpose. The intent of the > vendor-id in the DRI is only to know the manufacturer of the implementation or > device, nothing else. > > > So make the Vendor-ID AVP optional. Only include it if there are > > vendor-specific AVPs or command codes that the equipment understands or may > > send. Otherwise it doesn't matter. > > ok, so if I understand correctly, in the DRI the Vendor-Name represents the > name of the manufacturer, and the vendor-id would state which manufacturer's > vendor-specific AVPs are supported. Is this correct? > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Mar 12 12:30:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14944 for ; Mon, 12 Mar 2001 12:30:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 17F4F5DFBE; Mon, 12 Mar 2001 12:24:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E1CB45DFC5; Mon, 12 Mar 2001 12:24:44 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 26E9C5DFBE for ; Mon, 12 Mar 2001 12:24:42 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27146; Mon, 12 Mar 2001 09:24:39 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26348; Mon, 12 Mar 2001 09:24:36 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA06555; Mon, 12 Mar 2001 09:24:26 -0800 (PST) Date: Mon, 12 Mar 2001 09:19:54 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Diameter Issues found @ Connectathon To: David Spence Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" <3AAD0540.BEEC79DB@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I guess I was assuming that the purpose for putting vendor information in > the DRI was to allow a Diameter peer to signal which vendor specific AVPs > and command codes it understands. I just read section 6.1.1 in the base, and you are correct in your assumption. I somehow missed that one. When I eliminated the Vendor-Name AVP, I guess I thought it would make sense to add vendor-ids in the capabilities negotiation phase of the DRI. Of course, having the vendor-id be used for both capabilities discovery AND to recognize the vendor of the peer doesn't work. > Of course I could configure that in my > "Clients file", but in that case I could configure the manufacturer's name > too. Less configuration == better protocol. > I certainly don't mind a text Vendor-Name AVP that could be used for > logging purposes, but I think it might be useful to send zero or more > Vendor-Id AVPs to indicate the enterprise numbers of the supported > vendor-specific protocol elements as well. OK, so it sounds like both are needed. Any objections? PatC > > Pat Calhoun wrote: > > > > > > 1) Vendor-Id AVP (Base Protocol) > > > > > > > > Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. This > > > > now requires in order to implement Diameter, an enterprise number must be > > > > received from IANA. This really doesn't make a whole lot of sense, and the > > > > group felt that moving back to Vendor-Name was the correct approach. Further, > > > > the Vendor-Name could also include some "product" information for those vendors > > > > that have many client and server products (e.g. say abc has FAs and NASes, as > > > > well as a server). > > > >... > > > > > > I like Vendor-ID. It is not hard to apply for one. And you need one anyway > > > to insert in the Vendor-ID field of the AVP header. > > > > Only if you plan to send vendor-specific AVPs, and I would claim that there > > are plenty of RADIUS implementations that support RFC-only attributes. So > > requiring that one gets an SMI seems unnecessary. > > > > > If you use an > > > unregistered, free-format identifier in a Vendor-Name AVP and a different, > > > registered, fixed-format identifier in the Vendor-ID field of the AVP > > > headers, how am I supposed to match them? > > > > Why would you need to match them? You cannot really use the Vendor-Id in the > > DRI to know what vendor-specific AVPs are supported, since an implementation > > may in fact support many vendor-specific AVPs from many different vendors. > > > > > Keep it consistent throughout. > > > Use the IANA-registered enterprise numbers. > > > > > > > Consistency is good, but only if used for the same purpose. The intent of the > > vendor-id in the DRI is only to know the manufacturer of the implementation or > > device, nothing else. > > > > > So make the Vendor-ID AVP optional. Only include it if there are > > > vendor-specific AVPs or command codes that the equipment understands or may > > > send. Otherwise it doesn't matter. > > > > ok, so if I understand correctly, in the DRI the Vendor-Name represents the > > name of the manufacturer, and the vendor-id would state which manufacturer's > > vendor-specific AVPs are supported. Is this correct? > > > > PatC > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: (734) 821-1203 > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-bof@merit.edu Mon Mar 12 13:24:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16210 for ; Mon, 12 Mar 2001 13:24:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id A3AE85DEF5; Mon, 12 Mar 2001 13:21:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 84A5D5DEF0; Mon, 12 Mar 2001 13:21:36 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id 3D88D5DECB for ; Mon, 12 Mar 2001 13:21:34 -0500 (EST) Received: by balinese.baltimore.ie; id SAA04735; Mon, 12 Mar 2001 18:21:33 GMT Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma004696; Mon, 12 Mar 01 18:21:09 GMT Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 12 Mar 2001 18:20:26 +0000 Received: from baltimore.ie (ip191-24.ie.baltimore.com [10.153.24.191]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA09973; Mon, 12 Mar 2001 18:21:09 GMT Message-ID: <3AAD1393.DFE30FF8@baltimore.ie> Date: Mon, 12 Mar 2001 18:21:07 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaushik Narayan Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu, xme Subject: Re: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt References: <200103121621.VAA03285@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Kaushik, Now I'm confused. At the Interim meeting I thought there was more-or-less concensus that GSS-API only makes things worse here, and that you'd then decided not to include GSS-API in your proposal. Your answer below makes it look like you're putting GSS-API back(?) in, even though your -01 draft was posted a couple of weeks after the interim meeting. So, (if only to take me out of my confused state:-), which are we discussing - kerberos with or without GSS-API wrappers? And which version do you plan to describe at the meeting next week, this one or the one with GSS-API and responses to Pat's other comments? (BTW: Its getting *very* close to the meeting to expect most folks to have read another version, even if sent directly to the list.) I also strongly agree with Pat's comment that omitting the description of how the tickets get to the originating node (inter-realm TGTs and all that) means that a very large chunk of the implementation and deployment/configuration work required to support your proposal is not described. Regards, Stephen. Kaushik Narayan wrote: > > pat, > > hi! Thanks a lot for your comments. I will clean up the draft > and respond to your questions. I have been working on > changing this draft to use GSSAPI for Diameter security > instead of raw kerberos which would be the proposed > solution. That's the reason I didnot originally send this > draft on the list. > -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Mon Mar 12 14:55:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18733 for ; Mon, 12 Mar 2001 14:55:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id C90315DF1F; Mon, 12 Mar 2001 14:53:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B5ABC5DE72; Mon, 12 Mar 2001 14:53:13 -0500 (EST) Received: from mail01.bridgewatersystems.com (unknown [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id D567C5DE4F for ; Mon, 12 Mar 2001 14:53:11 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id PAA25696; Mon, 12 Mar 2001 15:49:15 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id OAA04634; Mon, 12 Mar 2001 14:53:36 -0500 (EST) From: "Mark Jones" To: , Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Mon, 12 Mar 2001 14:54:02 -0500 Message-ID: <001901c0ab2e$2fb46250$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3AACF84B.23D8C8E0@Interlinknetworks.com> X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I would like to see the Vendor-ID stay as a required AVP in the DRI to indicate the vendor of the peer. There have been many times when debugging RADIUS problems that it would have been invaluable to know the identity of the client/server. As David mentioned, it really is no big deal to obtain an enterprise number for this purpose. However even with the Vendor-ID and Firmware-ID AVPs in the DRI, I still feel we're missing a product name AVP to complete the identification. The presence of this AVP would be mandatory if the peer is not fully identified by the Vendor-ID and Firmware-ID. I did not understand from the DRI description in the draft how adding a Vendor-ID AVP to this message indicates the vendor-specific capabilities of the peer. Wouldn't one also need to add a list of supported vendor-specific command and AVP codes? Regards, Mark From owner-aaa-bof@merit.edu Mon Mar 12 15:54:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19905 for ; Mon, 12 Mar 2001 15:54:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id C35E25DE78; Mon, 12 Mar 2001 15:53:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ADC915DE81; Mon, 12 Mar 2001 15:53:04 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D67825DE78 for ; Mon, 12 Mar 2001 15:53:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22669; Mon, 12 Mar 2001 12:52:56 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20125; Mon, 12 Mar 2001 12:52:56 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA10127; Mon, 12 Mar 2001 12:52:52 -0800 (PST) Date: Mon, 12 Mar 2001 12:48:19 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon To: Mark Jones Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <001901c0ab2e$2fb46250$2096a8c0@mjones.bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I would like to see the Vendor-ID stay as a required AVP in the DRI to > indicate the vendor of the peer. There have been many times when debugging > RADIUS problems that it would have been invaluable to know the identity of > the client/server. As David mentioned, it really is no big deal to obtain an > enterprise number for this purpose. > > However even with the Vendor-ID and Firmware-ID AVPs in the DRI, I still > feel we're missing a product name AVP to complete the identification. The > presence of this AVP would be mandatory if the peer is not fully identified > by the Vendor-ID and Firmware-ID. looks like we've come full circle, but I will restate my position just in case you missed it. The Vendor-Name should be put back in the protocol, and it is a string. It contains whatever you want (e.g. "Pat Calhoun's Network Access Server and Fish Fryer, oh and it includes Diameter"), and the Firmware Revision 1.0 (do you really see a need for a second version of such a product :). So what you've asked for is there in my proposal to put Vendor-Name back in (oh, and it reduces the round trip time from implementor to IANA down to zero). > I did not understand from the DRI description in the draft how adding a > Vendor-ID AVP to this message indicates the vendor-specific capabilities of > the peer. Wouldn't one also need to add a list of supported vendor-specific > command and AVP codes? The basic idea was that the Vendor-Id would be used to identify which vendor-specific AVPs could be supported, but you have a point that this may be pointless without knowing in advance *which* AVPs are supported. Therefore, perhaps the Vendor-Id in the DRI doesn't make a whole lot of sense. PatC From owner-aaa-bof@merit.edu Mon Mar 12 18:16:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24190 for ; Mon, 12 Mar 2001 18:16:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 909F85DF53; Mon, 12 Mar 2001 18:13:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C3595DE5E; Mon, 12 Mar 2001 18:13:14 -0500 (EST) Received: from mail01.bridgewatersystems.com (unknown [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 9FBEB5DF53 for ; Mon, 12 Mar 2001 18:13:12 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id TAA27014; Mon, 12 Mar 2001 19:09:22 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id SAA08361; Mon, 12 Mar 2001 18:13:43 -0500 (EST) From: "Mark Jones" To: "Pat Calhoun" Cc: , Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Mon, 12 Mar 2001 18:14:09 -0500 Message-ID: <002001c0ab4a$243d9880$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > The Vendor-Name should be put back in the protocol, and it is a string. It > contains whatever you want (e.g. "Pat Calhoun's Network Access Server and Fish > Fryer, oh and it includes Diameter"), and the Firmware Revision 1.0 (do you > really see a need for a second version of such a product :). > Thanks for the explanation. I had misunderstood your intended use of the Vendor-Name AVP. So the Vendor-Name AVP would be mandatory in the DRI message and should contain the vendor name ("Pat Calhoun") and the vendor's name for the product ("Network Access Server and Fish Fryer"). Is that correct? This would certainly meet my debugging aid requirement but I think changing the AVP name to Vendor-Product-Name would give a strong hint that it is expected to contain more than just the vendor name. > The basic idea was that the Vendor-Id would be used to identify which > vendor-specific AVPs could be supported, but you have a point that this may be > pointless without knowing in advance *which* AVPs are supported. Therefore, > perhaps the Vendor-Id in the DRI doesn't make a whole lot of sense. > Keeping this AVP does allow a Diameter server to check whether it even has a dictionary for that vendor and if not, return a Message-Reject-Ind containing the unsupported Vendor-Id. This also allows for a limited form of capabilities negotiation in that devices could offer the same service with vendor-specific bells and whistles or the vanilla version as documented in the extension RFC depending on what the peer supported. Regards, Mark From owner-aaa-bof@merit.edu Mon Mar 12 19:28:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25723 for ; Mon, 12 Mar 2001 19:28:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3CFEA5DE86; Mon, 12 Mar 2001 19:27:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2AD915DE6F; Mon, 12 Mar 2001 19:27:21 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id A463B5DE0C for ; Mon, 12 Mar 2001 19:27:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09392; Mon, 12 Mar 2001 16:27:17 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07390; Mon, 12 Mar 2001 16:27:17 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA13618; Mon, 12 Mar 2001 16:27:14 -0800 (PST) Date: Mon, 12 Mar 2001 16:22:42 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <002001c0ab4a$243d9880$2096a8c0@mjones.bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Thanks for the explanation. I had misunderstood your intended use of the > Vendor-Name AVP. So the Vendor-Name AVP would be mandatory in the DRI > message and should contain the vendor name ("Pat Calhoun") and the vendor's > name for the product ("Network Access Server and Fish Fryer"). Is that > correct? The vendor name was a string, and could contain whatever the developer wanted. It could be as simple as "Pat Calhoun", and could be as complex as the example I had provided. I would hope that developers that had many products would be smart enough to include qualifying strings... > This would certainly meet my debugging aid requirement but I think > changing the AVP name to Vendor-Product-Name would give a strong hint that > it is expected to contain more than just the vendor name. .... but of course, this would be even better. So the contents wouldn't be any different, but the AVP name makes it sounds like it should contain more. Of course, now I could argue that the AVP name you proposed wouldn't include the vendor's name, but just the product name, and we'd be back to square one. Another method is to add clarifying text to Vendor-Name, to make it clear it could contain whatever they wanted. > Keeping this AVP does allow a Diameter server to check whether it even has a > dictionary for that vendor and if not, return a Message-Reject-Ind > containing the unsupported Vendor-Id. This also allows for a limited form of > capabilities negotiation in that devices could offer the same service with > vendor-specific bells and whistles or the vanilla version as documented in > the extension RFC depending on what the peer supported. ok. PatC From owner-aaa-bof@merit.edu Mon Mar 12 19:36:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25879 for ; Mon, 12 Mar 2001 19:36:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4D7785DE0C; Mon, 12 Mar 2001 19:36:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3A9E75DDE8; Mon, 12 Mar 2001 19:36:07 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 7E77B5DD9D for ; Mon, 12 Mar 2001 19:36:02 -0500 (EST) Received: from fredrikj (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id BAA11434; Tue, 13 Mar 2001 01:35:33 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" , , Cc: Subject: [AAA-WG]: RE: [diameter] Diameter Issues found @ Connectathon Date: Tue, 13 Mar 2001 00:37:29 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I beleive that we agreed on having the Home-Agent AVP mandatory in the AMA not the HAR (hopefully the HA will know its own address), but the diameter client in the FA should not be forced to parse the registration reply but should be able to find the HA address in the AMA. /Fredrik >-----Original Message----- >From: owner-diameter@diameter.org [mailto:owner-diameter@diameter.org]On >Behalf Of Pat Calhoun >Sent: den 9 mars 2001 16:15 >To: aaa-wg@merit.edu; diameter@diameter.org >Cc: pcalhoun@eng.sun.com >Subject: [diameter] Diameter Issues found @ Connectathon > > >All, > >Here are some issues that were found in the protocol during the >interoperability testing that occurred this week. I would suggest >that we fix >the protocol but would be interested in hearing any comments. > > >1) Vendor-Id AVP (Base Protocol) > >Someone brought up the fact that the Vendor-Name was changed to >Vendor-Id. This >now requires in order to implement Diameter, an enterprise number must be >received from IANA. This really doesn't make a whole lot of sense, and the >group felt that moving back to Vendor-Name was the correct >approach. Further, >the Vendor-Name could also include some "product" information for >those vendors >that have many client and server products (e.g. say abc has FAs >and NASes, as >well as a server). > > >2) Result-Code in MRI (Base Protocol) > >The Base Protocol defines the Message-Reject-Ind command to include the >Result-Code AVP. This really does violate the protocol, since if the >Result-Code is to be present in the MRI, it should also be present >in the DRI >(and all -Ind messages). Therefore, the group agreed that the >Result-Code must >not be present in the MRI, and instead be replaced with some other >AVP, such >as the Message-Reject-Code AVP (new). > > >3) DIAMETER_STILL_WORKING (Base Protocol) > >The base protocol is not clear about this one, but receiving the >above error >does imply that another message will eventually be received with the same >Identifier in the header. This needs to be clarified, since many >vendors use >the identifier to match request/responses, and don't expect more than one >message with the same id. > > >4) Peer State Machine (Base Protocol) > >The state machine is still not clear on how to deal with race >conditions, and >testing showed that further clarifications are required when a TCP or SCTP >connection is established. My recommendation is that the initiator of the >connection (the one that calls connect()) should be the one that sends the >first DRI. Upon receiving the DRI, the receiver (one that calls listen()) >checks whether another connection is in the process of being >established, and >if so, it will do an election process. If the identifier in the received >Diameter header is equal or greater than the one it had sent, it will tear >down the other connection. Otherwise, the incoming connection is shutdown. > >So the receiver is always the one that does the election check, >and the fact >that the DRIs aren't sent simultaneously on the same connection >makes it easier >to make such a check. > > >5) Unknown Vendor-Specific Commands > >The MRI is used to inform a peer that an unknown command code has been >received. However, if the command code is vendor specific, there is no way >to state this. Therefore, a new AVP, called the Unknown-Vendor-Id needs to >be created to inform a peer of the possible vendor-id/command code >combination. >Of course, this AVP only needs to be present if it was a vendor-specific >command code. > > >6) Treatment of Route-Record (Base Protocol) > >An issue arose where a host sent me a packet with the route-record >different >from the fqdn that gets resolved via DNS. So when the >corresponding response >was received, I would throw the packet away when I determined that I didn't >know how to get to the host in the route-record. > >This led to a discussion which resulted in an agreement that the >Origin-FQDN >in the DRI SHOULD be saved by Diameter implementations, since this MUST be >the same name as the one that would be present in the Route-Record. > >Of course, if the Origin-FQDN presented is the same as the one that is >resolved by DNS, this is not an issue, but the above >clarification can really >reduce potential problems in the field (hey, it took me 45 minutes >to figure >out what was going on, and I have source code). > >So I propose a clarification in the Route-Record AVP that states >that the name >in the AVP is the same as the one that was in the Origin-FQDN in the DRI. > > >7) HAR (MIP) > >An issue arose and it was agreed that the Home-Agent AVP MUST be present in >the HAR. The HAR is the message that is sent towards the Home Agent. > > >8) RADIUS-style MIP Challenge/Response (MIP) > >The Mobile IP Challenge/Response I-D supports a RADIUS >compatibility mode. In >this mode, the response in constructed in a way that is compatible with >existing RADIUS servers. The problem is that the challenge >advertised to the >mobile needs to be known by the AAAH in order to compute the >response, and the >challenge is never sent in a Diameter message. So a new Diameter >AVP needs to >be created that would encapsulate the Challenge. This would ONLY need to be >done if the MN-AAA authentication extension was created using the >RADIUS mode, >and this is known by the FA via the SPI. > > >9) Authorization-Lifetime in AMR (MIP) > >The MIP extension currently requires that the Authorization-Lifetime AVP be >present in the AMR (from the foreign agent). I have no idea why it was done >this way, but I know that many Foreign Agents will be perfectly happy to >receive whatever value they get from the AAAH, so it doesn't make sense for >this AVP to always be present in the message. I would like to >recommend that >this AVP become optional in the AMR. > > >10) Authorization-Lifetime and KEYs (MIP) > >Although it really isn't clearly stated, the Authorization-Lifetime and the >session key lifetimes MUST be the same. This clarification is >required in the >document. > > >11) Flags in Diameter header (Base Protocol) > >The current (01) I-D states: > > "A Diameter node MUST NOT set these flags in any other combination. > A Diameter node receiving a message in which these flags are not > set appropriately SHOULD NOT reject the message for this reason, > but MAY log the event for diagnosis." > >This sort-of implies that it isn't mandatory to set the bits. Some >additional >language needs to be added to make it clear that setting these >bits is a MUST. > > >12) HA in visited network > >(see e-mail I sent yesterday) > > >Although NASREQ was tested (well, not the tunneling AVPs), and as >well as the >Accounting extension, no issues were found in any of those I-Ds. > >Comments appreciated, > >PatC From owner-aaa-bof@merit.edu Mon Mar 12 20:05:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26600 for ; Mon, 12 Mar 2001 20:05:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5E5475DD9D; Mon, 12 Mar 2001 20:01:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4A8645DDE8; Mon, 12 Mar 2001 20:01:38 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1115C5DD9D for ; Mon, 12 Mar 2001 20:01:37 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00870; Mon, 12 Mar 2001 17:01:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26279; Mon, 12 Mar 2001 17:01:24 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA14098; Mon, 12 Mar 2001 17:01:19 -0800 (PST) Date: Mon, 12 Mar 2001 16:56:47 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: RE: [diameter] Diameter Issues found @ Connectathon To: Fredrik Johansson Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I beleive that we agreed on having the Home-Agent AVP mandatory in the AMA > not the HAR (hopefully the HA will know its own address), but the diameter > client in the FA should not be forced to parse the registration reply but > should be able to find the HA address in the AMA. Agreed about the AMA, but it must also be in the HAR in cases where the HAR is proxied (say in a visited network). PatC > > /Fredrik > > >-----Original Message----- > >From: owner-diameter@diameter.org [mailto:owner-diameter@diameter.org]On > >Behalf Of Pat Calhoun > >Sent: den 9 mars 2001 16:15 > >To: aaa-wg@merit.edu; diameter@diameter.org > >Cc: pcalhoun@eng.sun.com > >Subject: [diameter] Diameter Issues found @ Connectathon > > > > > >All, > > > >Here are some issues that were found in the protocol during the > >interoperability testing that occurred this week. I would suggest > >that we fix > >the protocol but would be interested in hearing any comments. > > > > > >1) Vendor-Id AVP (Base Protocol) > > > >Someone brought up the fact that the Vendor-Name was changed to > >Vendor-Id. This > >now requires in order to implement Diameter, an enterprise number must be > >received from IANA. This really doesn't make a whole lot of sense, and the > >group felt that moving back to Vendor-Name was the correct > >approach. Further, > >the Vendor-Name could also include some "product" information for > >those vendors > >that have many client and server products (e.g. say abc has FAs > >and NASes, as > >well as a server). > > > > > >2) Result-Code in MRI (Base Protocol) > > > >The Base Protocol defines the Message-Reject-Ind command to include the > >Result-Code AVP. This really does violate the protocol, since if the > >Result-Code is to be present in the MRI, it should also be present > >in the DRI > >(and all -Ind messages). Therefore, the group agreed that the > >Result-Code must > >not be present in the MRI, and instead be replaced with some other > >AVP, such > >as the Message-Reject-Code AVP (new). > > > > > >3) DIAMETER_STILL_WORKING (Base Protocol) > > > >The base protocol is not clear about this one, but receiving the > >above error > >does imply that another message will eventually be received with the same > >Identifier in the header. This needs to be clarified, since many > >vendors use > >the identifier to match request/responses, and don't expect more than one > >message with the same id. > > > > > >4) Peer State Machine (Base Protocol) > > > >The state machine is still not clear on how to deal with race > >conditions, and > >testing showed that further clarifications are required when a TCP or SCTP > >connection is established. My recommendation is that the initiator of the > >connection (the one that calls connect()) should be the one that sends the > >first DRI. Upon receiving the DRI, the receiver (one that calls listen()) > >checks whether another connection is in the process of being > >established, and > >if so, it will do an election process. If the identifier in the received > >Diameter header is equal or greater than the one it had sent, it will tear > >down the other connection. Otherwise, the incoming connection is shutdown. > > > >So the receiver is always the one that does the election check, > >and the fact > >that the DRIs aren't sent simultaneously on the same connection > >makes it easier > >to make such a check. > > > > > >5) Unknown Vendor-Specific Commands > > > >The MRI is used to inform a peer that an unknown command code has been > >received. However, if the command code is vendor specific, there is no way > >to state this. Therefore, a new AVP, called the Unknown-Vendor-Id needs to > >be created to inform a peer of the possible vendor-id/command code > >combination. > >Of course, this AVP only needs to be present if it was a vendor-specific > >command code. > > > > > >6) Treatment of Route-Record (Base Protocol) > > > >An issue arose where a host sent me a packet with the route-record > >different > >from the fqdn that gets resolved via DNS. So when the > >corresponding response > >was received, I would throw the packet away when I determined that I didn't > >know how to get to the host in the route-record. > > > >This led to a discussion which resulted in an agreement that the > >Origin-FQDN > >in the DRI SHOULD be saved by Diameter implementations, since this MUST be > >the same name as the one that would be present in the Route-Record. > > > >Of course, if the Origin-FQDN presented is the same as the one that is > >resolved by DNS, this is not an issue, but the above > >clarification can really > >reduce potential problems in the field (hey, it took me 45 minutes > >to figure > >out what was going on, and I have source code). > > > >So I propose a clarification in the Route-Record AVP that states > >that the name > >in the AVP is the same as the one that was in the Origin-FQDN in the DRI. > > > > > >7) HAR (MIP) > > > >An issue arose and it was agreed that the Home-Agent AVP MUST be present in > >the HAR. The HAR is the message that is sent towards the Home Agent. > > > > > >8) RADIUS-style MIP Challenge/Response (MIP) > > > >The Mobile IP Challenge/Response I-D supports a RADIUS > >compatibility mode. In > >this mode, the response in constructed in a way that is compatible with > >existing RADIUS servers. The problem is that the challenge > >advertised to the > >mobile needs to be known by the AAAH in order to compute the > >response, and the > >challenge is never sent in a Diameter message. So a new Diameter > >AVP needs to > >be created that would encapsulate the Challenge. This would ONLY need to be > >done if the MN-AAA authentication extension was created using the > >RADIUS mode, > >and this is known by the FA via the SPI. > > > > > >9) Authorization-Lifetime in AMR (MIP) > > > >The MIP extension currently requires that the Authorization-Lifetime AVP be > >present in the AMR (from the foreign agent). I have no idea why it was done > >this way, but I know that many Foreign Agents will be perfectly happy to > >receive whatever value they get from the AAAH, so it doesn't make sense for > >this AVP to always be present in the message. I would like to > >recommend that > >this AVP become optional in the AMR. > > > > > >10) Authorization-Lifetime and KEYs (MIP) > > > >Although it really isn't clearly stated, the Authorization-Lifetime and the > >session key lifetimes MUST be the same. This clarification is > >required in the > >document. > > > > > >11) Flags in Diameter header (Base Protocol) > > > >The current (01) I-D states: > > > > "A Diameter node MUST NOT set these flags in any other combination. > > A Diameter node receiving a message in which these flags are not > > set appropriately SHOULD NOT reject the message for this reason, > > but MAY log the event for diagnosis." > > > >This sort-of implies that it isn't mandatory to set the bits. Some > >additional > >language needs to be added to make it clear that setting these > >bits is a MUST. > > > > > >12) HA in visited network > > > >(see e-mail I sent yesterday) > > > > > >Although NASREQ was tested (well, not the tunneling AVPs), and as > >well as the > >Accounting extension, no issues were found in any of those I-Ds. > > > >Comments appreciated, > > > >PatC > From owner-aaa-bof@merit.edu Tue Mar 13 02:20:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16743 for ; Tue, 13 Mar 2001 02:20:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 858415DDAE; Tue, 13 Mar 2001 02:16:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6E9E05DE67; Tue, 13 Mar 2001 02:16:43 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 40BF85DDAE for ; Tue, 13 Mar 2001 02:16:40 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA16740; Tue, 13 Mar 2001 12:45:15 +0530 (IST) From: Kaushik Narayan Message-Id: <200103130715.MAA16740@cisco.com> Subject: Re: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt To: stephen.farrell@baltimore.ie Date: Tue, 13 Mar 2001 12:45:15 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu In-Reply-To: <3AAD1393.DFE30FF8@baltimore.ie> from "Stephen Farrell" at Mar 12, 2001 06:21:07 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit stephen, hi! The use of GSSAPI makes sense and apart from the forward extensibility it also provides a framework for management of Security Associations (SA). I will send the draft out on the list in next couple of days, I am exploring different alternatives to align the draft with requirements for e2e security from the interim meeting * NAS need not authenticate to the homeserver, only homeserver needs to authenticate to NAS. * Lightweight NAS. * Minimal administrative overhead on the NAS. I planning address deployement issues as a seperate section in the draft. kaushik! > > > Hi Kaushik, > > Now I'm confused. At the Interim meeting I thought there was > more-or-less concensus that GSS-API only makes things worse > here, and that you'd then decided not to include GSS-API in > your proposal. Your answer below makes it look like you're > putting GSS-API back(?) in, even though your -01 draft was > posted a couple of weeks after the interim meeting. > > So, (if only to take me out of my confused state:-), which > are we discussing - kerberos with or without GSS-API wrappers? > And which version do you plan to describe at the meeting next > week, this one or the one with GSS-API and responses to Pat's > other comments? (BTW: Its getting *very* close to the meeting > to expect most folks to have read another version, even if sent > directly to the list.) > > I also strongly agree with Pat's comment that omitting the > description of how the tickets get to the originating node > (inter-realm TGTs and all that) means that a very large chunk of > the implementation and deployment/configuration work required > to support your proposal is not described. > > Regards, > Stephen. > > Kaushik Narayan wrote: > > > > pat, > > > > hi! Thanks a lot for your comments. I will clean up the draft > > and respond to your questions. I have been working on > > changing this draft to use GSSAPI for Diameter security > > instead of raw kerberos which would be the proposed > > solution. That's the reason I didnot originally send this > > draft on the list. > > > > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > > From owner-aaa-bof@merit.edu Tue Mar 13 07:11:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18598 for ; Tue, 13 Mar 2001 07:11:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CD835DD8E; Tue, 13 Mar 2001 07:11:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 85EBC5DDB2; Tue, 13 Mar 2001 07:11:29 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id BC4705DD8E for ; Tue, 13 Mar 2001 07:11:26 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA22145; Tue, 13 Mar 2001 17:39:49 +0530 (IST) From: Kaushik Narayan Message-Id: <200103131209.RAA22145@cisco.com> Subject: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt To: pcalhoun@nasnfs.Eng.Sun.COM Date: Tue, 13 Mar 2001 17:39:49 +0530 (IST) Cc: aaa-wg@merit.edu, kaushik@cisco.com (Kaushik Narayan) In-Reply-To: from "Pat Calhoun" at Mar 12, 2001 07:39:49 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat, hi! Thanks for the comments. Some of sections in the current draft (raw Kerberos) would be removed in the new draft (GSSAPI). Anyways I have tried to address all your queries. Find my reply inline. > > Hi, > > I have some comments, questions and nits on the above I-D. > > 1. Some time back on the list, we agreed that Diameter was not all uppercase, > since it wasn't an acronym (although many suggestions were proposed). You will > want to fix your I-D to use "Diameter" instead of "DIAMETER". I will fix this. > > 2. "The ROAMOPS Working Group has defined a requirement that allows for > the DIAMETER servers..." doesn't quite sound right. A requirement doesn't > "allow" for something, but requires a feature. I will fix this. This line is present in the CMS strong security draft as well. > > 3. "This specification introduces the 'P' bit in the AVP Header, which is > defined in [1]." This is a contradictory sentence. First you state it is > introduced here, and defined in the base. You may want to clean up this > sentence. Perhaps "This specification makes use of the 'P' bit in the AVP > Header, which is defined in [1]." will do that. > > 4. Not being a Kerberos expert, I find that the text in section 3.0 is very > confusing. You have the sentence "The KRB-PRIV message carries the Diameter > AVPs encrypted in the Session Key." What does this mean? Why are AVPs encryped > in a session key? (I assume this is a typo). > > So if I can assume what you meant here, the AVPs are encrypted inside the > KRB-PRIV, using a session key. > > Further, the KRB-PRIV has a reference to EncryptedData, but the paragraph > following that states that this field really contains the EncKrbPrivPart. So > which one is it? I would think it is EncryptedData, since it is the only one > that has a reference to the CipherText. > > The sentence "The enc-part holds an encoding of the EncKrbPrivPart sequence > encrypted under the session key" needs to be clarified. When you state > something is encrypted under a session key, do you really mean it is encrypted > using a session key, or is this some kind of binding that I am unaware of? All of this should read as "encrypted using the session key". The KRB-PRIV contains EncKrbPrivPart in the enc-part field. The EncryptedData is the ASN.1 definition of all messages encrypted using the Kerberos session key. > > 5. Section 4.0 is much simpler to understand, but I don't see anywhere where a > reference to a key is made. Is there an assumption that only one key is > pending at any given time, or is one of the those fields a key identifier? The Kerberos session key is used to generate the checksum. > > 6. I have questions in regards to the following paragraph, which shows up in > section 5.0: > > " The DIAMTER client uses the kerberos service principal for service > discovery i.e. to discover the capability of a DIAMETER server to > support Kerberos. Since the kerberos service principal is defined > per DIAMETER server or proxy only Kerberized DIAMETER servers or > proxies would have the service principals registered with the KDC. > The KRB_TGS_REQ would fail trying to obtain a ticket for a non > Kerberized DIAMETER server or proxy and the NAS would revert back > to using the "normal" DIAMETER operation as defined in RFC 2865." > > First, it sounds like a NAS would send a Kerberos message to a Diameter > server, which would fail if it didn't support Kerberos. What exactly does this > mean? A Diameter server only handles Diameter messages. Are you instead > stating that a Kerberos message is sent to the Kerberos server on the same > physical entity that is running Diameter? If so, you will want to make that > clearer, as my read of this sounded like Diameter was also handling Kerb > messages. > > Second, RFC 2865 is an obvious cut and paste error from another I-D :) Well the KRB_TGS_REQ is the request for the service principal ticket which is sent by the DIAMETER client to the KDC. If a DIAMETER server doesnot support Kerberos it won't have a service principal registered with the KDC. The KRB_TGS_REQ would fail sent by the DIAMETER client to the KDC would fail. This section is a cut and paste from my Kerberized Radius draft. > > 7. The following paragraph disturbs me quite a bit: > > " A valid cross domain Ticket Granting Ticket(TGT) must be cached on > the DIAMETER client prior to sending a Kerberized DIAMETER request. > Cross domain TGT acquisition is out of the scope of this draft and > can happen based on inter domain trust or public key extensions > like PKCROSS can be employed to obtain cross realm TGTs. " > > When you presented your proposal in AAA, and at the Interim meeting, you also > sort-of hand-waved on this area. Although I understand why you state it is > outside the scope of this specification, the casual Diameter reader could be > fooled by not understanding what this means in terms of signaling through the > Internet. I think that it would be quite useful to show the basic security > relationships that are required between the entities, and how the cross-realm > TGTs are established. This is really crucial in the deployment, and shouldn't > be brushed off as out of scope. > > In fact, I would highly recommend that this text even shows up prior to the > BNF definitions, and has its own section. Now that I think of it, I don't see > why section 3 and 4 aren't pushed towards the end of the document. Reading the > BNF structures without understanding what is being done is the wrong approach > IMHO. The new draft would contain a section on deployment of Kerberos and address cross realm issues as well. > > 8. Please fix up the following text in section 5 "... a KRB_TGS_REQ to the > Ticket Granting Service (TGS) in order to the service principal ticket for the > DIAMETER server." I will fix this. > > 9. I am quite confused here. Section 5.0 contains: > > "The Kerberized > DIAMETER operation would mostly involve dynamic symmetric key > negotiation between DIAMETER peers using the Kerberos Application > exchange (KRB_AP_REQ/KRB_AP_REP). The symmetric keys negotiated > would then be used to provide integrity protection and privacy > protection for the DIAMETER AVPs." > > So it sounds like symmetric keys are what's being distributed, right? If so, > then why the following text in section 2.0: > > "The Mobile-IP and NASREQ > Working Groups have stated in [6, 7, 8] that non-repudiation is a > requirement for AAA data, such as accounting records." > > How can non-repudiation be achieved if both sides have the same key? This line should be deleted, non-repudiation cannot be achieved with symmetric keys. > > 10. The following paragraph is plagued with cut and paste error from the > RADIUS draft: "In routing the Access-Request to the home DIAMETER server, the > NAI is typically used, as described in RFC 2486..." This will be fixed. > > 11. The following text describes how Diameter server discovery can be made. I > can understand why this was done in RADIUS, given that it never bothered to > specify how servers are discovered. However, the base protocol has a section > on server discovery. Could you check whether the text in the base protocol is > not sufficient, and whether section 3.4 is still required? > > "The hostname and port of a DIAMETER homeserver can be determined as described > in the section 3.4." Will do. > > 12. Remove "of" in "The NAS will start of by creating a KRB_AP_REQ message..." > > 13. The text reads "... Kerberos-Endtoend-Auth AVP ..." However, I thought at > the meeting you claimed that your proposal make use of the ICV and > Encrypted-Payload AVPs. is this the case? If not, I can remove these AVPs from > the base protocol. I had left them in the -01 in case your proposal was > chosen, and I didn't want to have to rip out text, and put it back in -02. > Some guidance would be appreciated. > > Wait! I read further and now I am confused. Is the following correct? > > Kerberos-Endtoend-Auth AVP is used to carry Kerberos payload used to establish > the session key? If so, is this sent in parallel with any request? This isn't > clear to me. If it is not sent in parallel, when is it sent? In which Diameter > message? > > The "if end-to-end security is used, then an..." talks about an Integrity > Checksum. Is this something present in the ICV or something else? > The model of key exchange was that every Diameter session would perform a key exchange and the first set of Diameter message of the session (authentication/authorization) would carry the Kerberos key exchange messages in AVPs. The key exchange is done in parallel with the Diameter exchange. The new draft uses the Security Association (SA) model and the E2E-SA-Setup-Request and E2E-SA-Setup-Answer commands would be used for key exchange. I was planning to use Kerberos for both e2e and hop-by-hop as well. I sent out an email asking for feedback on the proposal to use object level security for hop-by-hop but recieved no response. This draft has a mention of Kerberos for hop-by-hop but if there is consensus in the group for use of IPSEC/SSL for hop-by-hop then I will drop the use of Kerberos for hop-by-hop in the latest draft. In case use of Kerberos for hop-by-hop is dropped then you can remove the ICV and Encrypted-Payload AVPs from the base document. > 14. s/SHOULD not/SHOULD NOT/ > > 15. The following "DIAMETER proxies SHOULD not modify the Kerberos-Data AVP > and the Kerberos-Endtoend-Auth AVP since this AVP is meant for DIAMETER end > servers." How does a server know it is an end server, and specifically *the* > intended end server? Is there some identity hidden somewhere in an AVP that > states that the end destination of the message is in order to proxies to know > where to send the message? Kerberos service authentication is done per Diameter server. In case the Diameter homeserver which recieves the request is different from the one in the service principal then the kerberos authentication would fail. This model is based on the assumption that the Diameter homeserver discovered using DNS is the same as the homeserver which recieves the request. There is nothing in the packet to tell a proxy to forward the request to that particular homeserver. Since this might not work out an alternative was to use a service principal per domain like diameter@FOO.ORG instead of diameter/server@FOO.ORG in which case the request could be sent to any diameter server in that domain. In this case all Diameter servers in domain FOO.ORG would be valid Diameter servers. Anyways I am planning to change the model of authentication in the latest draft. > > 16. It is now clear to me that a terminology section would be really useful. > Perhaps the most commonly used term in this I-D could be defined at the > beginning. You claim that a kerberos session key is the same as the client > session key, but I know that some RADIUS and Diameter people will get confused > if they've ever used the common RADIUS source base, which includes the clients > file, which also contains the secret. I am proposing this to reduce any > possible confusion on the part of the reader. I will do that. > > 17. "In case of an error in Kerberos authentication, an Access-Reject is sent > with a Kerberos-Endtoend-Auth AVP containing the KRB_ERROR message in the > Kerberos authentication TLV." Cut and paste error. Again, is this done in > parallel with a valid request, or prior to? If prior to, then a new message > set should be created. > > 18. The AVP codes assigned conflict with the Mobile IP extension, and with > each other :) Will change the AVP codes. > > 19. Copyright year should be 2001. I will fix this. thanks, kaushik! > > PatC > > From owner-aaa-bof@merit.edu Tue Mar 13 07:43:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA18910 for ; Tue, 13 Mar 2001 07:43:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id C1EE75DE48; Tue, 13 Mar 2001 07:43:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEC7A5DE1F; Tue, 13 Mar 2001 07:43:22 -0500 (EST) Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8]) by segue.merit.edu (Postfix) with ESMTP id A293B5DE0E for ; Tue, 13 Mar 2001 07:43:20 -0500 (EST) Received: by balinese.baltimore.ie; id MAA23423; Tue, 13 Mar 2001 12:43:19 GMT Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2) id xma022541; Tue, 13 Mar 01 12:42:24 GMT Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 13 Mar 2001 12:41:41 +0000 Received: from baltimore.ie (ip191-24.ie.baltimore.com [10.153.24.191]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA31880; Tue, 13 Mar 2001 12:42:29 GMT Message-ID: <3AAE15B0.8CE04599@baltimore.ie> Date: Tue, 13 Mar 2001 12:42:24 +0000 From: Stephen Farrell Reply-To: stephen.farrell@baltimore.ie Organization: Baltimore Technologies Ltd. X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Kaushik Narayan Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu, xme Subject: Re: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt References: <200103131209.RAA22145@cisco.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Kaushik, I've another question. Might be that I'm not upto date on Kerberos implementations, but rfc150 says (section 1.2): " + Each host on the network must have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection. The degree of "looseness" can be configured on a per-server basis. If the clocks are synchronized over the network, the clock synchronization protocol must itself be secured from network attackers." Now, I remember this being a PITA when we were trying to deploy SESAME (which had Kerberos as an authentication option, if you don't know what SESAME was...it doesn't matter anymore;-). So, my question is: does you proposal require loosely synchronized clocks across all Diameter nodes that want e2e? If so, is time synch already supplied by other parts of Diameter or is it a new requirement for Diameter nodes? Regards, Stephen. -- ____________________________________________________________ Stephen Farrell Baltimore Technologies, tel: (direct line) +353 1 881 6716 39 Parkgate Street, fax: +353 1 881 7000 Dublin 8. mailto:stephen.farrell@baltimore.ie Ireland http://www.baltimore.com From owner-aaa-bof@merit.edu Tue Mar 13 09:09:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20346 for ; Tue, 13 Mar 2001 09:09:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id B33DE5DD93; Tue, 13 Mar 2001 09:09:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 948F85DDA5; Tue, 13 Mar 2001 09:09:09 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 3A27A5DD93 for ; Tue, 13 Mar 2001 09:09:06 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id TAA04285; Tue, 13 Mar 2001 19:37:45 +0530 (IST) From: Kaushik Narayan Message-Id: <200103131407.TAA04285@cisco.com> Subject: Re: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt To: stephen.farrell@baltimore.ie Date: Tue, 13 Mar 2001 19:37:45 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu In-Reply-To: <3AAE15B0.8CE04599@baltimore.ie> from "Stephen Farrell" at Mar 13, 2001 12:42:24 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit stephen, hi! Kerberos would require loose clock synchronization across Diameter nodes that want e2e. Administratively Diameter nodes can configure the maximum allowed clock skew, the default is five minutes. kaushik! > > Kaushik, > > I've another question. Might be that I'm not upto date on Kerberos > implementations, but rfc150 says (section 1.2): > > " + Each host on the network must have a clock which is "loosely > synchronized" to the time of the other hosts; this > synchronization is used to reduce the bookkeeping needs of > application servers when they do replay detection. The degree > of "looseness" can be configured on a per-server basis. If the > clocks are synchronized over the network, the clock > synchronization protocol must itself be secured from network > attackers." > > Now, I remember this being a PITA when we were trying to deploy SESAME > (which had Kerberos as an authentication option, if you don't know what > SESAME was...it doesn't matter anymore;-). > > So, my question is: does you proposal require loosely synchronized > clocks across all Diameter nodes that want e2e? If so, is time synch > already supplied by other parts of Diameter or is it a new requirement > for Diameter nodes? > > Regards, > Stephen. > > > -- > ____________________________________________________________ > Stephen Farrell > Baltimore Technologies, tel: (direct line) +353 1 881 6716 > 39 Parkgate Street, fax: +353 1 881 7000 > Dublin 8. mailto:stephen.farrell@baltimore.ie > Ireland http://www.baltimore.com > > From owner-aaa-bof@merit.edu Tue Mar 13 11:41:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23196 for ; Tue, 13 Mar 2001 11:41:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3A0B25DDC6; Tue, 13 Mar 2001 11:40:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 279495DDA3; Tue, 13 Mar 2001 11:40:30 -0500 (EST) Received: from funk.funk.com (funk.funk.com [198.186.160.66]) by segue.merit.edu (Postfix) with ESMTP id 10F975DD9C for ; Tue, 13 Mar 2001 11:40:27 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by funk.funk.com (8.11.2/8.11.2) with SMTP id f2DFx1W06144; Tue, 13 Mar 2001 10:59:01 -0500 (EST) Message-Id: <4.1.20010313104927.00b98f00@funk1.funk.com> X-Sender: paul@funk1.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 13 Mar 2001 11:15:42 -0500 To: Patrice Calhoun , David Mitton From: Paul Funk Subject: Re: [AAA-WG]: Diameter Issues wrt Vendor-Name Cc: aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <4.3.2.7.2.20010309123336.00c73200@ZBL6C008.corpeast.baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree that the name of the AVP should be Product-ID (or possibly Product-Name, which is more suggestive of a text value). I'm not sure if the preceding discussion was clear enough as to the content of this AVP. My suggestion is that the content of the AVP be the product name itself, and that it be understood in conjunction with Firmware-Revision; that is, Firmware-Revision is the version number of the product named in Product-ID. The Product-ID could contain the manufacturer's name, not alone but as a brand modifier, e.g., "Toyota Corolla". The combination of Product-ID and Firmware-Revision is a definitive indication of what AVPs a Diameter peer supports. Granted this must be configured in advance. But exchanging Vendor-IDs is not an adequate means of discovering capabilities, since a vendor can define a new AVP without adding ot to all devices it manufactures, nor does equipment in the field magically get upgraded when new AVPs appear. Paul At 10:38 AM 3/9/01 -0800, Patrice Calhoun wrote: >> At 3/9/01 10:15 AM -0500, Pat Calhoun wrote: >> >> >All, >> > >> >Here are some issues that were found in the protocol during the >> >interoperability testing that occurred this week. I would suggest that we >> fix >the protocol but would be interested in hearing any comments. >> > >> >1) Vendor-Id AVP (Base Protocol) >> > >> >Someone brought up the fact that the Vendor-Name was changed to Vendor-Id. >> >This >> >now requires in order to implement Diameter, an enterprise number must be >> >received from IANA. This really doesn't make a whole lot of sense, and the >> >group felt that moving back to Vendor-Name was the correct approach. >> Further, >the Vendor-Name could also include some "product" information for >> those >vendors >> >that have many client and server products (e.g. say abc has FAs and NASes, >> as >well as a server). >> ... >> >> Two issues: >> >> 1) They will need an SMI code if they wish to implement any VSAs >> anyways. This has not been a problem for RADIUS manufacturers. More >> importantly they will need an SMI if they are doing any >> MIBs! Unfortunately, it seems that AAA programmers' don't usually know >> what the SNMP engineers are up to. > >Right, but a manufacturer that wants to only sell servers, or perhaps doesn't >want VSAs, shouldn't need an SMI code simply to implement the protocol, right? > >> 2) I would suggest that perhaps the better name for this AVP would be >> Product-ID, and that would remove some of the confusion with the AVP >> Vendor-ID header field. > >ok. > >PatC > Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Tue Mar 13 15:36:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27883 for ; Tue, 13 Mar 2001 15:36:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id EAF0B5DEA0; Tue, 13 Mar 2001 15:33:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2D5615E10B; Tue, 13 Mar 2001 15:28:49 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7B8C95DFAA for ; Tue, 13 Mar 2001 15:26:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA09223; Tue, 13 Mar 2001 12:26:53 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23840; Tue, 13 Mar 2001 12:26:52 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA00215; Tue, 13 Mar 2001 12:26:50 -0800 (PST) Date: Tue, 13 Mar 2001 12:22:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Mobile IP Extension To: aaa-wg@merit.edu, diameter@diameter.org Cc: pcalhoun@eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, It has come to my attention that the following changes are required in the Mobile IP extension. 1. Support for the Filter-Rule I have been informed that there is demand for downloading Filter Rules, as defined in the NASREQ extension to Foreign Agents, and Home Agents (so in the AMA and HAR, respectively). However, the Filter-Rule AVP is defined in the NASREQ extension. So, we have the following options: a) Move the Filter-Rule AVP to the base protocol b) Redefine another Filter-Ruls AVP in the mobile IP extension c) Simply have the Mobile IP extension refer to the Filter-Rule AVP from the NASREQ extension, or d) Create a new extension that ONLY defines the Filter-Rules, but no command code (so I am not even sure that it would require an Extension-Id). Does anyone have an opinion on the best approach? 2. Support for co-located Mobile Nodes The Mobile IP extension currently requires the Foreign Agent to contact the AAA infrastructure. However, when a mobile node is co-located there is no Foreign Agent, and therefore the Home Agent would be the instigator of the AMR to the AAAH. I propose keeping the AMR/AMA messages for this purpose, but would create a new Feature-Vector value that would indicate this was a co-located mobile node. Any comments? PatC From owner-aaa-bof@merit.edu Tue Mar 13 19:05:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00570 for ; Tue, 13 Mar 2001 19:05:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 58E935E384; Tue, 13 Mar 2001 18:26:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A2CC5E75B; Tue, 13 Mar 2001 17:36:03 -0500 (EST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id C37CE5E44C for ; Tue, 13 Mar 2001 16:59:12 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01126; Tue, 13 Mar 2001 13:57:59 -0800 (PST) Received: from jtrostle-nt2 (dhcp-128-107-141-207.cisco.com [128.107.141.207]) by mira-sjc5-1.cisco.com (Mirapoint) with SMTP id ABW15728; Tue, 13 Mar 2001 13:59:09 -0800 (PST) Message-Id: <4.1.20010313135654.00c4cad0@mira-sjc5-1> X-Sender: jtrostle@mira-sjc5-1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 13 Mar 2001 14:02:40 -0800 To: stephen.farrell@baltimore.ie, Kaushik Narayan From: Jonathan Trostle Subject: Re: [AAA-WG]: Re: Comments on draft-kaushik-diameter-strong-sec-01.txt Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu, xme In-Reply-To: <3AAE15B0.8CE04599@baltimore.ie> References: <200103131209.RAA22145@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk Existing implementations don't require the application client and application server to have synchronized clocks. If the clocks are not synchronized, then an error message is returned to the client which allows the client to make a subsequent AP request with a timestamp that will be acceptable to the server. (But the extra round trip is not necessary when the client and server's clock are within some fixed skew period - typically 5 minutes but the skew period can be longer). Jonathan At 12:42 PM 3/13/01 +0000, Stephen Farrell wrote: > >Kaushik, > >I've another question. Might be that I'm not upto date on Kerberos >implementations, but rfc150 says (section 1.2): > >" + Each host on the network must have a clock which is "loosely > synchronized" to the time of the other hosts; this > synchronization is used to reduce the bookkeeping needs of > application servers when they do replay detection. The degree > of "looseness" can be configured on a per-server basis. If the > clocks are synchronized over the network, the clock > synchronization protocol must itself be secured from network > attackers." > >Now, I remember this being a PITA when we were trying to deploy SESAME >(which had Kerberos as an authentication option, if you don't know what >SESAME was...it doesn't matter anymore;-). > >So, my question is: does you proposal require loosely synchronized >clocks across all Diameter nodes that want e2e? If so, is time synch >already supplied by other parts of Diameter or is it a new requirement >for Diameter nodes? > >Regards, >Stephen. > > >-- >____________________________________________________________ >Stephen Farrell >Baltimore Technologies, tel: (direct line) +353 1 881 6716 >39 Parkgate Street, fax: +353 1 881 7000 >Dublin 8. mailto:stephen.farrell@baltimore.ie >Ireland http://www.baltimore.com > From owner-aaa-bof@merit.edu Tue Mar 13 19:45:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01013 for ; Tue, 13 Mar 2001 19:45:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7494C5DEEB; Tue, 13 Mar 2001 18:47:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9FEF65E20E; Tue, 13 Mar 2001 18:07:38 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 86AEC5DF02 for ; Tue, 13 Mar 2001 17:41:28 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id C5A6775; Tue, 13 Mar 2001 17:41:42 -0500 (EST) Message-ID: <3AAEA200.5DFF02FD@Interlinknetworks.com> Date: Tue, 13 Mar 2001 17:41:04 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Jones Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon References: <002001c0ab4a$243d9880$2096a8c0@mjones.bridgewatersys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I like the Vendor-Product-Name AVP as discussed in this thread. I also urge inclusion of a Vendor-ID AVP that could appear in a DRI message zero or more times to indicate at least partial support for vendor specific AVPs and Command Codes. But I guess we do need to agree on how it would work. My idea would be that it would indicate Vendor-IDs that I support, not Vendor-IDs I expect my peer to support. So there would be no need to respond to a DRI with an MRI whenever I don't support some of your Vendor-IDs. It would merely be a hint at the sender's capabilities. So if I include a Vendor-ID AVP in my DRI for Vendor X, it means that I have included (at least some of) Vendor X's AVPs in my dictionary and may know how to process them. If later you send me a Vendor X Foobar AVP with the M bit set and I don't happen to support the Foobar AVP, then I would have to reject the message. If the M bit is not set and I don't support the Foobar AVP then I may ignore it. But at least it would be worthwhile for you to include Vendor X AVPs in the the messages you send me. If I do not include a Vendor-ID AVP in my DRI that advertises support for Vendor-X, then you have a very high degree of assurance that I will not understand Vendor X AVPs and if you have any degraded way of mapping Vendor X AVPs to standard AVPs you should really do it. In our RADIUS server, we have a vendor ID item in our "RADIUS Clients" configuration file. The server uses it to decide whether to include vendor-specific attributes in messages sent to the client. We don't go so far as to configure lists of supported vendor-specific attributes for each RADIUS client (although you can do that on a server-wide basis), yet the per-client configuration feature we do provide seems to be useful. Including the information in the DRI message would be even better because it makes one less thing for the network administrator to have to configure. One could still include a configuration item to override or augment the DRI information for a particular client. Therefore, my recommendation is to provide a simple capability (Vendor-IDs that I mostly support) in the DRI but not worry about complexities such as: here is a list of all the command codes I support and which AVPs I allow and require for each command code and under what circumstances ad infinitum. In short, I think a simple, numeric Vendor-ID AVP would be useful and further complexities probably unwarranted. Mark Jones wrote: > > Pat, > > > The Vendor-Name should be put back in the protocol, and it is a string. It > > contains whatever you want (e.g. "Pat Calhoun's Network Access Server and > Fish > > Fryer, oh and it includes Diameter"), and the Firmware Revision 1.0 (do > you > > really see a need for a second version of such a product :). > > > > Thanks for the explanation. I had misunderstood your intended use of the > Vendor-Name AVP. So the Vendor-Name AVP would be mandatory in the DRI > message and should contain the vendor name ("Pat Calhoun") and the vendor's > name for the product ("Network Access Server and Fish Fryer"). Is that > correct? This would certainly meet my debugging aid requirement but I think > changing the AVP name to Vendor-Product-Name would give a strong hint that > it is expected to contain more than just the vendor name. > > > The basic idea was that the Vendor-Id would be used to identify which > > vendor-specific AVPs could be supported, but you have a point that this > may be > > pointless without knowing in advance *which* AVPs are supported. > Therefore, > > perhaps the Vendor-Id in the DRI doesn't make a whole lot of sense. > > > > Keeping this AVP does allow a Diameter server to check whether it even has a > dictionary for that vendor and if not, return a Message-Reject-Ind > containing the unsupported Vendor-Id. This also allows for a limited form of > capabilities negotiation in that devices could offer the same service with > vendor-specific bells and whistles or the vanilla version as documented in > the extension RFC depending on what the peer supported. > > Regards, > Mark -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Mar 14 14:01:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01480 for ; Wed, 14 Mar 2001 14:01:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0B085DE03; Wed, 14 Mar 2001 13:38:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D9B35DEC7; Wed, 14 Mar 2001 13:14:49 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id 9A7035E452 for ; Wed, 14 Mar 2001 13:08:32 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA29355; Wed, 14 Mar 2001 23:37:18 +0530 (IST) From: Kaushik Narayan Message-Id: <200103141807.XAA29355@cisco.com> Subject: [AAA-WG]:Diameter Strong Security using GSSAPI v2 To: aaa-wg@merit.edu Date: Wed, 14 Mar 2001 23:37:18 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.11530.984593238--%" Sender: owner-aaa-bof@merit.edu Precedence: bulk --%--multipart-mixed-boundary-1.11530.984593238--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, I am attaching the latest version of the Diameter strong security draft using GSSAPI. This draft uses GSSAPI v2 for Diameter e2e security and tries to address some specific issues 1> NAS need not authenticate to the homeserver, only homeserver needs to authenticate to the NAS. 2> Minimal administration on the NAS. 3> Lightweight NAS implementation. 4> Eliminate need for DNS for discovery of KDC and Diameter homeserver. The draft still needs some editing and a few things needed to be added. kaushik! --%--multipart-mixed-boundary-1.11530.984593238--% Content-Type: text/plain Content-Description: ascii text Content-Disposition: attachment; filename="draft-kaushik-diameter-strong-sec-02.txt" Content-Transfer-Encoding: 7bit Individual Contribution Kaushik Narayan Internet-Draft HCL-Cisco Category :Standards Track March 2001 Diameter Strong Security Extension using GSSAPI v2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires September 2001. Please send comments to the author (kaushik@cisco.com). Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Diameter base protocol defines message integrity and AVP encryption using static symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. Kaushik expires September 2001 [Page 1] Internet-Draft March 2001 The ROAMOPS Working Group has defined a requirement that needs the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify, and/or be able to view sensitive information, within the message. The Mobile-IP and NASREQ Working Groups have stated that strong authentication is a requirement for AAA data, such as accounting records. This Diameter extension specifies how strong AVP authentication, integrity and encryption can be done using by keys negotiated using Kerberos v5. Table of Contents 1.0 Introduction 2.0 GSSAPI Overview 3.0 GSS Algorithm 4.0 Usage Scenario with Kerberos v5 GSSAPI mechanism 5.0 Deployment Issues 6.0 Strong Security AVPs 6.2 GSS-Data AVP 6.3 GSS-Token AVP 6.4 E2ESecureList AVP 7.0 Result Code AVP Values 8.0 IANA Considerations 9.0 Security Considerations 10.0 References 11.0 Authors' Addresses 1.0 Introduction The Diameter base protocol [1] defines message integrity and AVP encryption using symmetric transforms to secure the communication between two Diameter nodes. The base protocol also defines a Diameter proxy server, that forwards requests to other servers when it detects that a given request cannot be satisfied locally. The ROAMOPS Working Group has defined a requirement in [10] that allows for the Diameter servers communicating through the proxy to be able to provide for end-to-end AVP integrity and confidentiality, making it difficult for the proxy to be able to modify and see sensitive information within the message. The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation is a requirement for AAA data, such as accounting records. Kaushik expires September 2001 [Page 2] Internet-Draft March 2001 When a chain of proxies use hop-by-hop security, each node in the proxy chain MUST recompute the Integrity-Value-Check (ICV) [1], making it easy for a malicious proxy to modify information in a Diameter message. It is virtually impossible for the rest of the nodes in the proxy chain to know that the message was modified in mid-stream. Figure 1 shows an example of such a network, where DIA3 modifies the contents of "foo" in both the request and the response. (Request) (Request) (Request) [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] +------+ -----> +------+ -----> +------+ -----> +------+ | | | | | | | | | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | | | | | | | | | +------+ <----- +------+ <----- +------+ <----- +------+ (Answer) (Answer) (Answer) [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] Figure 1: Proxy Chain This document describes how strong authentication and encryption can be provided in the Diameter protocol, by employing security services provided by GSSAPI. GSSAPI would be use for key negotiation between Diameter peers. In the example provided in Figure 1, the originator of the request and response adds a digital signature that covers a set of AVPs within the message. The protected AVPs MUST NOT be changed by an intermediate proxy server (DIA2, DIA3), since the signature validation performed by the end server would fail. The Extension number for this draft is two (2). This value is used in the Extension-Id AVP as defined in [1]. This specification makes use of the 'P' bit in the AVP Header, which is defined in [2]. 2.0 GSSAPI Overview In GSS, client and server interact to create a "security context". Creating a security context involves a negotiation between client and server. Once a context has been established, it has a finite lifetime for which it can be used to secure messages. Client and server MUST be locally authenticated and have acquired default credentials before using this protocol as specified in Section 1.1.1 "Credentials" in RFC 2743 [RFC2743]. Kaushik expires September 2001 [Page 2] Internet-Draft March 2001 In GSS, establishing a security context involves the passing of opaque tokens between the client and the server. The client generates the initial token and sends it to the server. The server processes the token and if necessary, returns a subsequent token to the client. The client processes this token, and so on, until the negotiation is complete. The number of times the client and server exchange tokens depends on the underlying security mechanism A completed negotiation results in a context handle. A unique context is required for each server to which the client sends secure messages. A context is identified by a context handle. A client maintains a mapping of servers to handles, (target_name, key_name, context_handle) The value key_name also identifies a context handle. The context_handle WOULD be used to provide protection for Diameter AVPs. The GSS Security Context is synonomous to the Security Assocation (SA) for the purpose of this discussion. The Diameter E2E-SA-Setup-Request, E2E-SA-Setup-Answer defined in [2] would carry the context establishment tokens. 3.0 GSS Algorithm When a Diameter node is about to send a messsage which MAY use strong security, it must determine whether to use the strong security service or not. The Diameter node WOULD first check whether a context handle has been cached for the given destination realm. The cached context handle would be used for strong security in case it has not expired. In the present discussion we assume that the Diameter node has not cached any information. This draft makes use of the Diameter E2E-SA-Setup-Request (ESSR) and E2E-SA-Setup-Answer (ESSA) messages defined in [2] to establish whether strong security is required and if so, for which AVPs. Step 1: The originating node sends the ESSR message to the destination node (a server in the destination realm). The ESSR message SHOULD contain the name and the realm of the originating node in Origin-FQDN and Origin-Realm AVPs. Kaushik expires September 2001 [Page 3] Internet-Draft March 2001 Step 2: The destination node calls GSS_Init_sec_context, using the most recent reply token received from originating node during this exchange, if any. It MUST set the integ_req_flag to "true" to request that per-message integrity protection be supported for this context. and it MUST pass the TTL for this SA in lifetime_req parameter. The destination node would generate an error in the following cases * If the resulting major_status code is GSS_S_COMPLETE and the integ_avail flag is not true, then per-message integrity protection is not available. * If the call does not produce a GSS token of non-zero length. In case of an error the destination node would send an error message in the ESSA message. The destination node sends the ESSA message with a valid GSS token to the originating node in the following cases * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, The originating node will reply back with a new token to be provided to GSS_Init_sec_context. * If GSS_Init_sec_context returns a GSS_S_COMPLETE. In this case the security context has been succesfully established at the destination node and the processing on the destination node continues with Step 4. This ESSA message WOULD contain - the token returned from the GSS_Init_sec_context call. - List of AVPs to be protected. Step 3: The originating node calls GSS_Accept_sec_context, using the token received in the ESSA message from destination node. The originating node WOULD reply back with an ESSA message containing the GSS token in the following cases * If the resulting major_status code is GSS_S_COMPLETE, the security context has been established succesfully on the originating node and processing continues with Step 4. * If the resulting major_status code is GSS_S_CONTINUE_NEEDED, the processing will continue with Steps 2 and 3 until GSS_S_COMPLETE. Kaushik expires September 2001 [Page 4] Internet-Draft March 2001 The list of AVPsto be protected by this SA is extracted from the E2ESecureList AVP. In case the GSS_Acccept_Sec_Context does not produce a GSS token of non-zero length an error message is generated and auditing is done. The originating node cannot obtain end-to-end strong security. Step 4: The security context has been succesfully established at the Diameter node. The Diameter node can now obtain security services using the context handle, the GSS_Wrap method would be used for confidentiality protection and GSS_GetMIC would be used for integrity protection. The context handle would be valid until TTL set by the destination node expires. Callers would be returned GSS_S_CONTEXT_EXPIRED in case they call GSS_Wrap or GSS_GetMIC after TTL expiration. The list of AVPs to be protected would be carried in the E2ESecureList AVP. The E2ESecureList AVP WOULD be protected using the context handle. 4.0 Usage Scenario with Kerberos v5 GSSAPI mechanism. The Kerberos v5 GSSAPI mechanism would be used in the single-TGT mode wherin Kerberos is used without mutual authentication. The destination Diameter node SHOULD possess a valid cross realm TGT which forms the default credentials. Acquisition of cross realm TGTs and models for cross realm trust are discussed in section 5.0. The Kerberos v5 service principal would be of the form diameter@NAShostname@NASREALM.COM. The destination Diameter node (homeserver) would construct this service principal based on the information passed in the ESSR request from the originating node (NAS). The GSS_Init_Sec_Context would acquire the service principal ticket from the KDC in case there isn't a valid ticket present in the credentials cache. The NAS which is be the GSS Server will not have any interaction with the KDC. The credentials required to authenticate the homeserver WOULD be present in the keytab file present on the NAS. This would simplify key exchange procedure at the NAS. Moreover the administrative overhead on the NAS is minimal since the NAS need not have a security token (like a TGT or Certificate in case of PKINIT) from a third party security server (KDC) to participate in the key exchange. Kaushik expires September 2001 [Page 5] Internet-Draft March 2001 The key exchange of the Kerberos GSS mechanism would happen as follows. NAS homeserver --- ---------- ESSR --------> Origin-FQDN, Origin-Realm. GSS_Init_sec_context(TTL,integ_req_flag) returns GSS_S_COMPLETE, output_token <-------- ESSA E2ESecureList, GSS-Token (output_token). GSS_Accept_sec_context(input_token) returns GSS_S_COMPLETE. At the end of the above exchange, the homeserver WOULD have authenticated to the NAS and both the Diameter nodes would have a context handle which would provide the security services to both Diameter nodes. The key exchange of the Kerberos GSS mechanism WOULD take only half a round trip and the SA creation WOULD take one round trip. 5.0 Deployment Issues A valid cross-realm TGT should be present on the homeserver to create a security associations with NASes in that realm. The initial TGT can be obtained manually during bootup of the homeserver. Alternatively PKINIT can be employed wherein the homeserver's public key certificate WOULD be used in the initial authentication exchange with the local KDC. Cross realm trust in Kerberos can be established in multiple ways. The simplest way is to maintain separate keys for every realm which wishes to exchange authentication information with another realm (which implies n(n-1) keys). Kerberos v5 support transitive trust which allows hierarchichal arrangement of realms for better scalability. Kaushik expires September 2001 [Page 6] Internet-Draft March 2001 Another option available is PKCROSS which utilizes a public key infrastructure (PKI) [X509] to simplify the administrative burden of maintaining cross-realm keys. PKCROSS take advantage of the distributed trust management capabilities of public key cryptography for establishing cross realm trust. The model proposed in this draft has the NAS as the GSS server and the Diameter homeserver as the GSS client. This significantly simplifies the administration and operation on the NAS WOULD NOT have any interaction with the KDC. 6.0 Strong Security AVPs This section contains AVPs that are used to establish a Diameter End-to-End Security Association. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| GSS-Data 310 6.1 Grouped | M | P | | V | N | GSS-Token 348 6.2 OctetString| M | P | | V | N | E2ESecureList 349 6.3 OctetString| M | P | | V | Y | 6.1 GSS-Data AVP The GSS-Data AVP (AVP Code 350) is of type Grouped and contains the AVPs which are required for End to End security. The grammar for the grouped Data field is defined is: GSS-Data = Digest ptextlen Encrypted-Data Digest = ; the output token of GSS_GetMIC call which provides e2e integrity protection and data origin authentication for Diameter AVPs. ptextlen = ; Plaintext-Data-Length. Encrypted-Data = ; the output token of the GSS_Wrap call which provides confidentiality for Diameter AVPs. +---------------------------------------------------------------+ | AVP Header (AVP Code = 320) | +---------------------------------------------------------------+ | Digest AVP | +---------------------------------------------------------------+ | Plaintext-Data-Length AVP | +---------------------------------------------------------------+ | Encrypted-Data AVP | +---------------------------------------------------------------+ Kaushik expires September 2001 [Page 7] Internet-Draft March 2001 6.2 GSS-Token AVP The GSS-Token AVP (AVP Code = 351) is of type OctetString. This AVP carries the GSS token exchanged during context initialization. 6.3 E2ESecureList The E2ESecureList AVP (AVP Code = 352) is of type OctetString. The AVP contains the list of AVPs that need end-to-end protection. The string value consists of a space separated list of AVP numbers to be encrypted, followed by a comma, followed by a space separated list of AVP numbers where origin authentication is required. For example: "123 456, 768" ",768 910" "123 456" 7.0 Result-Code AVP Values This section defines new Result-Code [1] values that MUST be supported by all Diameter implementations that conform to this specification. 8.0 IANA Considerations The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the Diameter name spaces. 9.0 Security Considerations This draft determines whether to use Kerberos purely on the basis of the existence or non-existence of a Kerberos service principal. This presents an opportunity for a downgrade attack wherein because an attacker can spoof an error message from the KDC and make the Diameter client not use end to end security which would compromise end to end security. Implementations should provide users with a policy knob which would prevent Diameter clients from using only hop-by-hop security in case they encounter an error while acquiring the service principal ticket from the KDC. 10.0 References [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "Diameter Base Protocol", draft-calhoun-diameter-17.txt, IETF work in progress, September 2000. [2] P. Calhoun, W. Bulley, S. Farrell, "Diameter Strong Security Extension", draft-calhoun-diameter-strong-crypto-07.txt (work in progress), March 2001. Kaushik expires September 2001 [Page 8] Internet-Draft March 2001 [3] J. Linn, "Generic Security Service Application Program Interface", Version 2, Update 1, RFC 2743, January 2000 [4] Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work in progress, June 2000. [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep- tember 2000. [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Authorization, and Accounting Requirements", draft-ietf- mobileip-aaa-reqs-04.txt, IETF work in progress, June 2000. [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol (OCSP)", RFC 2560, June 1999. [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999. [11] P. Calhoun, W. Bulley, "Diameter NASREQ Extension", draft- calhoun-diameter-nasreq-05.txt, IETF work in progress, September 2000. [12] P. Calhoun, C. Perkins, "Diameter Mobile IP Extensions", draft- calhoun-diameter-mobileip-11.txt, IETF work in progress, Sep- tember 2000. [13] Arkko, Calhoun, Patel, Zorn, "Diameter Accounting Extension", draft-calhoun-diameter-accounting-08.txt, IETF work in progress, 11.0 Author's Address Kaushik Narayan HCL-Cisco Offshore Development Centre, 158, NSK Salai, Vadapalani Chennai, Tamilnadu 600 026, India EMail: kaushik@cisco.com Phone: +091-44-3741939 Kaushik expires September 2001 [Page 9] Internet-Draft March 2001 11.0 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Kaushik expires September 2001 [Page 10] --%--multipart-mixed-boundary-1.11530.984593238--%-- From owner-aaa-bof@merit.edu Wed Mar 14 14:45:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02730 for ; Wed, 14 Mar 2001 14:45:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1928D5DF37; Wed, 14 Mar 2001 14:03:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 692215DE1D; Wed, 14 Mar 2001 13:48:19 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DE0205E41D for ; Wed, 14 Mar 2001 13:35:46 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 2A0F075; Wed, 14 Mar 2001 13:36:01 -0500 (EST) Message-ID: <3AAFB9E9.72011D61@Interlinknetworks.com> Date: Wed, 14 Mar 2001 13:35:21 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com Subject: Re: [AAA-WG]: Mobile IP Extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See comments interspersed below. Pat Calhoun wrote: > > All, > > It has come to my attention that the following changes are required in the > Mobile IP extension. > > 1. Support for the Filter-Rule > > I have been informed that there is demand for downloading Filter Rules, > as defined in the NASREQ extension to Foreign Agents, and Home Agents > (so in the AMA and HAR, respectively). However, the Filter-Rule AVP is > defined in the NASREQ extension. So, we have the following options: > > a) Move the Filter-Rule AVP to the base protocol And after this starts down the standards track and someone else discovers an attribute in one extension that would be useful in another extension, we would stop the standards train, add yet another AVP to the base protocol and restart the train? So I don't like "a)" because it doesn't provide a good model for how to handle this kind of problem in the future. > b) Redefine another Filter-Ruls AVP in the mobile IP extension I kinda like the concept of reusability myself -- define Filter-Rule AVP once and reuse it wherever it's needed. > c) Simply have the Mobile IP extension refer to the Filter-Rule AVP > from the NASREQ extension, or I think that would work. It does mean you have to download more RFCs to get everything you need, but it works. > d) Create a new extension that ONLY defines the Filter-Rules, but no > command code (so I am not even sure that it would require an > Extension-Id). Sounds like a great way to multiply the number of RFCs required to define Diameter: "This RFC defines AVPs common to both the NASREQ and Mobile IP extensions." "This RFC defines AVPs common to both the NASREQ and Chicken Fryer extensions." "This RFC defines AVPs common to both the Mobile IP and Chicken Fryer extensions." > > Does anyone have an opinion on the best approach? So far, I guess I like "c)". Are there any other ideas? >... -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Wed Mar 14 16:16:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04545 for ; Wed, 14 Mar 2001 16:16:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id F22C65DF1A; Wed, 14 Mar 2001 15:40:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A26875DE76; Wed, 14 Mar 2001 15:08:26 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by segue.merit.edu (Postfix) with ESMTP id 934D45E13B for ; Wed, 14 Mar 2001 14:22:39 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA21230; Wed, 14 Mar 2001 11:22:52 -0800 (PST) Received: from johnalw2k (sj-dial-4-123.cisco.com [171.68.181.252]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id ADA22683; Wed, 14 Mar 2001 11:22:30 -0800 (PST) From: "John Alayari" To: "Pat Calhoun" , , Cc: Subject: [AAA-WG]: RE: [diameter] Mobile IP Extension Date: Wed, 14 Mar 2001 11:21:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See my comments below: >All, > >It has come to my attention that the following changes are required in the >Mobile IP extension. > >1. Support for the Filter-Rule > > I have been informed that there is demand for downloading Filter Rules, > as defined in the NASREQ extension to Foreign Agents, and Home Agents > (so in the AMA and HAR, respectively). However, the Filter-Rule AVP is > defined in the NASREQ extension. So, we have the following options: > > a) Move the Filter-Rule AVP to the base protocol > b) Redefine another Filter-Ruls AVP in the mobile IP extension > c) Simply have the Mobile IP extension refer to the Filter-Rule AVP > from the NASREQ extension, or > d) Create a new extension that ONLY defines the Filter-Rules, but no > command code (so I am not even sure that it would require an > Extension-Id). > > Does anyone have an opinion on the best approach? > > >2. Support for co-located Mobile Nodes > > The Mobile IP extension currently requires the Foreign Agent to contact > the AAA infrastructure. However, when a mobile node is co-located there > is no Foreign Agent, and therefore the Home Agent would be the > instigator of the AMR to the AAAH. I propose keeping the AMR/AMA messages > for this purpose, but would create a new Feature-Vector value that would > indicate this was a co-located mobile node. Pat, I agree with using a bit in the MIP-Feature-Vector avp. However, all 8 bits are allocated and we need to extend it to 16 bits or more. BTW, in the Mobile IP extension, do we need a section to describe co-location scenario? John Alayari >Any comments? > >PatC From owner-aaa-bof@merit.edu Wed Mar 14 16:35:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04853 for ; Wed, 14 Mar 2001 16:35:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 466615E1F0; Wed, 14 Mar 2001 16:03:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AE3B05E331; Wed, 14 Mar 2001 15:33:03 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 817455E13D for ; Wed, 14 Mar 2001 14:59:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01964; Wed, 14 Mar 2001 11:59:35 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20752; Wed, 14 Mar 2001 11:59:07 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA26698; Wed, 14 Mar 2001 11:59:05 -0800 (PST) Date: Wed, 14 Mar 2001 11:54:32 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: RE: [diameter] Mobile IP Extension To: John Alayari Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >2. Support for co-located Mobile Nodes > > > > The Mobile IP extension currently requires the Foreign Agent to contact > > the AAA infrastructure. However, when a mobile node is co-located there > > is no Foreign Agent, and therefore the Home Agent would be the > > instigator of the AMR to the AAAH. I propose keeping the AMR/AMA messages > > for this purpose, but would create a new Feature-Vector value that would > > indicate this was a co-located mobile node. > > Pat, > > I agree with using a bit in the MIP-Feature-Vector avp. However, all 8 bits > are allocated and we need to extend it to 16 bits or more. BTW, in the > Mobile IP extension, do we need a section to describe co-location scenario? The Feature-Vector avp is of type Unsigned32, and yes we section will be necessary to describe the expected behavior. PatC From owner-aaa-bof@merit.edu Wed Mar 14 20:22:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07469 for ; Wed, 14 Mar 2001 20:22:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 625785EA42; Wed, 14 Mar 2001 19:28:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A6EE5DFA9; Wed, 14 Mar 2001 18:06:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9D8015E524 for ; Wed, 14 Mar 2001 17:20:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00658 for ; Wed, 14 Mar 2001 14:20:06 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02271 for ; Wed, 14 Mar 2001 14:20:05 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA00401 for ; Wed, 14 Mar 2001 14:20:03 -0800 (PST) Date: Wed, 14 Mar 2001 14:15:29 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Comments on draft-kaushik-diameter-strong-sec-02.txt To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk ok, here are my comments on the new version: 1. "The Diameter base protocol [1] defines message integrity and AVP encryption using symmetric transforms to secure the communication between two Diameter nodes." Since you no longer use these, I will remove them from the base protocol, so this sentence was be removed in your next version. Please go through the I-D as there are many other places where you refer to the ICV, and how it works. replace that with your favorite hop-by-hop protocol (e.g. TLS or IPSec). (FWIW, the CMS I-D will also include such changes in its next revision) 2. "The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that non-repudiation is a requirement for AAA data, such as accounting records." I *thought* you agreed that Kerberos cannot provide non-repudiation in your last response to me. Therefore, I am curious as to why you insist on keeping this sentence in the I-D, unless it is to make it clear that your proposal doesn't meet the requirements ?!?! 3. It is my understanding that only the CMS or the Kerberos approach will be selected, so refering to messages created in the CMS I-D is probably not a good long term approach. 4. Section 3.0. Thank you very much for this explanation. I think it really adds alot to the proposal. I believe that this type of language will ease interoperability. 5. Section 3.0, at the end of step 2, you state " This ESSA message WOULD contain ... - List of AVPs to be protected." This one really confuses me. An SA should be created for a long time (tm). So given that one has no idea what AVPs will be provided in the future, should all possibly encrypted AVPs be listed, or rather just subset of those? Which ones? I am confused with this sentence. 6. Section 3.0, step 3. I believe this proposal is "abusing" the ESS command codes. It appears as if this step causes an Answer to be sent in response to an Answer. Is this correct?? Diameter doesn't work this way, so either a new ESSR is to be sent, or another set of messages should be created. 7. The figure in section 4.0 does not seem to match section 3.0. Doesn't step 3 require that another ESSA be sent back in response to an ESSA? 8. "The key exchange of the Kerberos GSS mechanism WOULD take only half a round trip and the SA creation WOULD take one round trip. " Now I am confused because the diagram only shows a single round trip, not 1.5 round trips. 9. Sorry for the perhaps dumb question, but what the #ell is "123 456, 768" ",768 910" "123 456" I don't understand the random placement of commas and quotes. 10. If you don't need new Result-Codes, you can get rid of section 7.0 11. Oh, and an acknowledgement to the authors from whom you "borrowed" text would be nice too :) See y'all next week, PatC From owner-aaa-bof@merit.edu Thu Mar 15 02:27:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26661 for ; Thu, 15 Mar 2001 02:27:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5CB975DEC9; Thu, 15 Mar 2001 02:24:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 354C35DF26; Thu, 15 Mar 2001 02:24:44 -0500 (EST) Received: from cisco.com (pilu.cisco.com [192.122.173.199]) by segue.merit.edu (Postfix) with ESMTP id B2ED15DEC9 for ; Thu, 15 Mar 2001 02:24:37 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id MAA00992; Thu, 15 Mar 2001 12:53:20 +0530 (IST) From: Kaushik Narayan Message-Id: <200103150723.MAA00992@cisco.com> Subject: Re: [AAA-WG]: Comments on draft-kaushik-diameter-strong-sec-02.txt To: pcalhoun@nasnfs.Eng.Sun.COM Date: Thu, 15 Mar 2001 12:53:20 +0530 (IST) Cc: aaa-wg@merit.edu In-Reply-To: from "Pat Calhoun" at Mar 14, 2001 02:15:29 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit pat, hi! Thanks for your comments. Find my reply inline. > > ok, here are my comments on the new version: > > 1. "The Diameter base protocol [1] defines message integrity and AVP > encryption using symmetric transforms to secure the communication > between two Diameter nodes." > > Since you no longer use these, I will remove them from the base protocol, > so this sentence was be removed in your next version. Please go through the > I-D as there are many other places where you refer to the ICV, and how it > works. replace that with your favorite hop-by-hop protocol (e.g. TLS or > IPSec). > > (FWIW, the CMS I-D will also include such changes in its next revision) I will change this. > > > 2. "The Mobile-IP and NASREQ Working Groups have stated in [6, 7, 8] that > non-repudiation is a requirement for AAA data, such as accounting records." > > I *thought* you agreed that Kerberos cannot provide non-repudiation in your > last response to me. Therefore, I am curious as to why you insist on keeping > this sentence in the I-D, unless it is to make it clear that your proposal > doesn't meet the requirements ?!?! I will remove this line. > > 3. It is my understanding that only the CMS or the Kerberos approach will be > selected, so refering to messages created in the CMS I-D is probably not a > good long term approach. I will add new messages to my draft. > > 4. Section 3.0. Thank you very much for this explanation. I think it really > adds > alot to the proposal. I believe that this type of language will ease > interoperability. > > 5. Section 3.0, at the end of step 2, you state " This ESSA message WOULD > contain > ... - List of AVPs to be protected." This one really confuses me. An SA > should > be created for a long time (tm). So given that one has no idea what AVPs > will > be provided in the future, should all possibly encrypted AVPs be listed, or > rather just subset of those? Which ones? I am confused with this sentence. The list should contains all AVPs that need e2e protection (both encryption and origin authentication). > > 6. Section 3.0, step 3. I believe this proposal is "abusing" the ESS command > codes. It appears as if this step causes an Answer to be sent in response > to > an Answer. Is this correct?? Diameter doesn't work this way, so either a new > ESSR is to be sent, or another set of messages should be created. I will use new messages for this. > > 7. The figure in section 4.0 does not seem to match section 3.0. Doesn't step > 3 require that another ESSA be sent back in response to an ESSA? Section 3.0 describes the process of context establishment for any GSS mechanism which may take n round trips. Section 4.0 illustrates the actual usage wherein GSSAPI would use the Kerberos v5 mechanism. In this case the Kerberos GSS mechanism is used in single-TGT mode (this is without the mutual authentication). This mechanism completes key exchange with a single message sent from the client to the server to authenticate the client to the server and exchange keys. The server doesnot reply to client's request. The client here is the Diameter homeserver which wants to authenticate itself to the server(NAS) and GSS token would be sent from the homeserver to the NAS in the ESSA. The NAS doesnot reply back. So the SA setup involves one ESSR and ESSA. This is the singficant changes made in this proposal are. * The security context (SA) is initiated by the Diameter homeserver since the parameters of the SA (like TTL) are defined by the based on the policy. * The process of setting up the security context using the Kerberos v5 mechanism takes one single message from the homeserver to the NAS. * Since the NAS is the GSS (Kerberos) server (as opposed to the client in previous proposals), the NAS neednot have security tokens from third party servers and the NAS neednot communicate with the KDC. * GSS takes care of the context management (SA management). > > 8. "The key exchange of the Kerberos GSS mechanism WOULD take only > half a round trip and the SA creation WOULD take one round trip. " > > Now I am confused because the diagram only shows a single round trip, not > 1.5 round trips. Well the sentence is not very clear. It should read The key exchange of the Kerberos GSS mechanism WOULD involve a single message from the homeserver to the NAS. > > 9. Sorry for the perhaps dumb question, but what the #ell is > "123 456, 768" ",768 910" "123 456" > > I don't understand the random placement of commas and quotes. Well the quotes represent different examples of what the E2ESecureList can contain. There are three illustrations given. 1> "123 456, 768" AVPs with codes 123 and 456 needs confidentiality and 768 needs origin authentication. 2> ",768 910" AVPs with codes 768 and 910 need origin authentication. 3> "123 456" AVPs with codes 123 and 456 need confidentiality protection. > > 10. If you don't need new Result-Codes, you can get rid of section 7.0 I will look at that. > > 11. Oh, and an acknowledgement to the authors from whom you "borrowed" text > would > be nice too :) sure. kaushik! > > See y'all next week, > > PatC > > > > From owner-aaa-bof@merit.edu Fri Mar 16 00:08:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15919 for ; Fri, 16 Mar 2001 00:08:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E94D5DEE0; Thu, 15 Mar 2001 23:43:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AB7D25E0BE; Thu, 15 Mar 2001 22:16:08 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id A31745E4D0 for ; Thu, 15 Mar 2001 21:16:30 -0500 (EST) Received: from fredrikj (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id DAA24932; Fri, 16 Mar 2001 03:15:44 +0100 From: "Fredrik Johansson" To: "David Spence" , "Pat Calhoun" Cc: , Subject: RE: [diameter] Re: [AAA-WG]: Mobile IP Extension Date: Fri, 16 Mar 2001 02:17:45 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3AAFB9E9.72011D61@Interlinknetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I like the reusablility, but here is a problem with reusing the filter rules as defined in NASREQ since they specified the order of evaluation. FreeBSD uses in order and first match terminates evaluation, however, in OpenBSD the filters are evaluated in order and the last match determines what to do with the packet (unless you add 'quick' to the rule) I'm not sure if we should try to come up with a general filter rule that can be used no matter what implementation, and perhaps specify some new AVP that takes care of the differences. Or perhaps, the way to go is to define a new set of AVPs which would make it easy for the implementation to determine if it is supported or not. There should not be a case where a subset of the received AVPs are supported, it would make it hard to determine what to do with the ones that are understood. A third way could be to keep the filter rules as they are today, and if someone would like to support another implementation they will make it vendor specific. /Fredrik >-----Original Message----- >From: owner-diameter@diameter.org [mailto:owner-diameter@diameter.org]On >Behalf Of David Spence >Sent: den 14 mars 2001 19:35 >To: Pat Calhoun >Cc: aaa-wg@merit.edu; diameter@diameter.org; pcalhoun@eng.sun.com >Subject: [diameter] Re: [AAA-WG]: Mobile IP Extension > > >See comments interspersed below. > >Pat Calhoun wrote: >> >> All, >> >> It has come to my attention that the following changes are >required in the >> Mobile IP extension. >> >> 1. Support for the Filter-Rule >> >> I have been informed that there is demand for >downloading Filter Rules, >> as defined in the NASREQ extension to Foreign Agents, >and Home Agents >> (so in the AMA and HAR, respectively). However, the >Filter-Rule AVP is >> defined in the NASREQ extension. So, we have the >following options: >> >> a) Move the Filter-Rule AVP to the base protocol > >And after this starts down the standards track and someone else >discovers an >attribute in one extension that would be useful in another extension, we >would stop the standards train, add yet another AVP to the base >protocol and >restart the train? So I don't like "a)" because it doesn't provide a good >model for how to handle this kind of problem in the future. > >> b) Redefine another Filter-Ruls AVP in the mobile IP extension > >I kinda like the concept of reusability myself -- define Filter-Rule AVP >once and reuse it wherever it's needed. > >> c) Simply have the Mobile IP extension refer to the >Filter-Rule AVP >> from the NASREQ extension, or > >I think that would work. It does mean you have to download more >RFCs to get >everything you need, but it works. > >> d) Create a new extension that ONLY defines the >Filter-Rules, but no >> command code (so I am not even sure that it would require an >> Extension-Id). > >Sounds like a great way to multiply the number of RFCs required to define >Diameter: > >"This RFC defines AVPs common to both the NASREQ and Mobile IP extensions." > >"This RFC defines AVPs common to both the NASREQ and Chicken Fryer >extensions." > >"This RFC defines AVPs common to both the Mobile IP and Chicken Fryer >extensions." > >> >> Does anyone have an opinion on the best approach? > >So far, I guess I like "c)". Are there any other ideas? > >>... > >-- >David Spence email: >DSpence@Interlinknetworks.com >Interlink Networks, Inc. phone: (734) 821-1203 >775 Technology Drive, Suite 200 fax: (734) 821-1235 >Ann Arbor, MI 48108 >U.S.A. From owner-aaa-bof@merit.edu Fri Mar 16 00:52:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16502 for ; Fri, 16 Mar 2001 00:52:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67ABB5E42F; Fri, 16 Mar 2001 00:13:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CF5115E1DF; Thu, 15 Mar 2001 23:48:37 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 4024A5E1E6 for ; Thu, 15 Mar 2001 22:54:45 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2G3kBN21095; Thu, 15 Mar 2001 19:46:11 -0800 From: "Bernard Aboba" To: "Pat Calhoun" , , Subject: RE: [AAA-WG]: Mobile IP Extension Date: Thu, 15 Mar 2001 19:55:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just a question. Can you provide some background on what constitutes an extension? What, for example, distinguishes an extension from something in the base protocol? Also, how is the DIAMETER extensibility model different from the RADIUS model? Can a DIAMETER server send an arbitrary AVP to a DIAMETER client, as can be done in RADIUS? Or is it more like RPC, where you have a way of transmitting arbitrary data over the wire (XDR), but you need to have the same functions implemented on both client and server? From owner-aaa-bof@merit.edu Fri Mar 16 02:37:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00377 for ; Fri, 16 Mar 2001 02:37:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id C19765DF96; Fri, 16 Mar 2001 02:06:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 944795DF97; Fri, 16 Mar 2001 01:28:15 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 620B65EA9E for ; Fri, 16 Mar 2001 00:50:42 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2G5nxT13335; Fri, 16 Mar 2001 00:49:59 -0500 (EST) (envelope-from barney) Date: Fri, 16 Mar 2001 00:49:59 -0500 From: Barney Wolff To: Fredrik Johansson Cc: David Spence , Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension Message-ID: <20010316004959.A13218@mx.databus.com> References: <3AAFB9E9.72011D61@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Fri, Mar 16, 2001 at 02:17:45AM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk We MUST NOT leave the order of evaluation unspecified. Personally I think anything but first match counts is crazy, but whatever we do, we cannot leave it to the creativity of the enforcement point. How could any inter-domain or inter-vendor scenario be viable, if that were so? A NAS that runs on last-match can reverse the order of the rules before evaluation, but the home server cannot and should not know the style of the NAS, so must issue the rules in a standardized form. As a simple example, take the rules deny tcp eq 6000 permit tcp ge 1024 In all of AAA, semantics is far more important than syntax. I'd generalize that to any protocol design, and in fact to all of Life. Barney Wolff On Fri, Mar 16, 2001 at 02:17:45AM +0100, Fredrik Johansson wrote: > I like the reusablility, but here is a problem with reusing the filter rules > as defined in NASREQ since they specified the order of evaluation. FreeBSD > uses in order and first match terminates evaluation, however, in OpenBSD the > filters are evaluated in order and the last match determines what to do with > the packet (unless you add 'quick' to the rule) > > I'm not sure if we should try to come up with a general filter rule that can > be used no matter what implementation, and perhaps specify some new AVP that > takes care of the differences. > > Or perhaps, the way to go is to define a new set of AVPs which would make it > easy for the implementation to determine if it is supported or not. There > should not be a case where a subset of the received AVPs are supported, it > would make it hard to determine what to do with the ones that are > understood. > > A third way could be to keep the filter rules as they are today, and if > someone would like to support another implementation they will make it > vendor specific. > > /Fredrik From owner-aaa-bof@merit.edu Fri Mar 16 06:32:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA02039 for ; Fri, 16 Mar 2001 06:32:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A7435DDCA; Fri, 16 Mar 2001 06:30:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 59E7A5DDD5; Fri, 16 Mar 2001 06:30:02 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id A4B445DDCA for ; Fri, 16 Mar 2001 06:29:58 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f2GBTvC01414 for ; Fri, 16 Mar 2001 12:29:57 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 16 12:29:56 2001 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 12:27:51 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FF0E@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" , "'pcalhoun@eng.sun.com'" Subject: [AAA-WG]: AAA Registration Keys for Mobile IP? Date: Fri, 16 Mar 2001 12:29:48 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, From reading the "AAA Registration Keys for Mobile IP" document (draft-ietf-mobileip-aaa-key-04.txt), I was wondering if you could help me understand the sections 6 and 7? The thing is that I don't see exactly what they can be used for. For example, is the MN-FA Key Request (section 6) sent in the MIP Registration Request in order to suggest a SPI between the MN and the FA? Then, I guess that the FA can suggest it to the AAAH in the AMR using the MIP-FA-MN-Preferred-SPI AVP, right? I guess the FA can also suggest a SPI between the FA and the HA using the MIP-FA-HA-Preferred-SPI AVP, right? However, if the MN sends a MN-HA Key Request (section 7) including a preferred SPI to be used between the MN and the HA, how can it be sent to the AAAH? It does not seem to exist any AVP for that in the Diameter Mobile-IP protocol. Can that subtype be used at all within the AAA infrastucture meaningfully? Also, note that in section 7, it is referred to the foreign agent instead of the Home Agent??? Regards, Martin From owner-aaa-bof@merit.edu Fri Mar 16 08:36:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03253 for ; Fri, 16 Mar 2001 08:36:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7FE3C5DDEE; Fri, 16 Mar 2001 08:33:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B57F5DE22; Fri, 16 Mar 2001 08:33:47 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 006585DDEE for ; Fri, 16 Mar 2001 08:33:45 -0500 (EST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 16 Mar 2001 07:17:43 -0600 Received: from crchy28c.us.nortel.com ([47.103.121.38]) by zrchb200.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GMXHGVLV; Fri, 16 Mar 2001 07:17:40 -0600 Received: from Haseeb (archt2ma.us.nortel.com [47.134.244.2]) by crchy28c.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G1JD0LZF; Fri, 16 Mar 2001 07:17:36 -0600 Reply-To: "Haseeb Akhtar" X-Sybari-Space: 00000000 00000000 00000000 From: "Haseeb Akhtar" To: aaa-wg Subject: [AAA-WG]: Let's go forward with the Base Protocol Date: Fri, 16 Mar 2001 07:18:40 -0600 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01C0ADE9.533BFF40" X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001D_01C0ADE9.533BFF40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Do we need end-to-end security right now?Folks, Since I'm not going to be attending the IETF next week, here are some of my thoughts on Diameter as it stands today. - Going over the recent Base Protocol (.01) and the issues found at the Connectathon, I feel that the protocol now looks pretty good. The next version should be ready for the WG last call. - Having accounting extension merged with the Base, in my opinion, is not necessary as long as the WG feels that the Accounting Extension meets all the requirements. - I also strongly feel that we should not wait for the end-to-end security solution to be resolved to go forward with the Base Protocol. The e-2-e security may not be required for the initial implementation of the Diameter (such as 3GPP2). Regards, Haseeb ------=_NextPart_000_001D_01C0ADE9.533BFF40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do we need end-to-end security right now?

Folks,

Since I'm not going to be attending the IETF next = week,=20 here

are some of my thoughts on Diameter as it stands = today.=20

 

 - Going over the recent Base Protocol (.01) and = the=20 issues 

   found at the Connectathon, I feel = that the protocol = now looks 

   pretty=20 good. The next version = should be=20 ready for the WG last

  =20 call.

 

  - Having accounting extension = merged with=20 the Base, 

   in my opinion, is not necessary as long = as the WG=20 feels 

   that the Accounting Extension meets all the = requirements.

 

 -  I = also=20 strongly feel that we should not wait for the

    = end-to-end=20 security solution to be resolved to go forward

    = with the Base=20 Protocol. The e-2-e=20 security may not be required

    = for the=20 initial  implementation of the Diameter (such=20 as 3GPP2). 

Regards,

Haseeb


------=_NextPart_000_001D_01C0ADE9.533BFF40-- From owner-aaa-bof@merit.edu Fri Mar 16 09:55:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04545 for ; Fri, 16 Mar 2001 09:55:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 848F65DF6A; Fri, 16 Mar 2001 09:54:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 669225DF68; Fri, 16 Mar 2001 09:54:14 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id B21A65DF57 for ; Fri, 16 Mar 2001 09:54:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27009; Fri, 16 Mar 2001 06:54:03 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26311; Fri, 16 Mar 2001 06:53:59 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA20911; Fri, 16 Mar 2001 06:53:56 -0800 (PST) Date: Fri, 16 Mar 2001 06:53:55 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension To: Barney Wolff Cc: Fredrik Johansson , David Spence , Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010316004959.A13218@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I *completely* agree with Barney. If you are writing to an implementation that does not meet the AAA requirements, then it is up to the developer to do what it takes to make it work. PatC > We MUST NOT leave the order of evaluation unspecified. Personally > I think anything but first match counts is crazy, but whatever we > do, we cannot leave it to the creativity of the enforcement point. > How could any inter-domain or inter-vendor scenario be viable, if > that were so? A NAS that runs on last-match can reverse the order > of the rules before evaluation, but the home server cannot and > should not know the style of the NAS, so must issue the rules in > a standardized form. As a simple example, take the rules > deny tcp eq 6000 > permit tcp ge 1024 > > In all of AAA, semantics is far more important than syntax. I'd > generalize that to any protocol design, and in fact to all of Life. > > Barney Wolff > > On Fri, Mar 16, 2001 at 02:17:45AM +0100, Fredrik Johansson wrote: > > I like the reusablility, but here is a problem with reusing the filter rules > > as defined in NASREQ since they specified the order of evaluation. FreeBSD > > uses in order and first match terminates evaluation, however, in OpenBSD the > > filters are evaluated in order and the last match determines what to do with > > the packet (unless you add 'quick' to the rule) > > > > I'm not sure if we should try to come up with a general filter rule that can > > be used no matter what implementation, and perhaps specify some new AVP that > > takes care of the differences. > > > > Or perhaps, the way to go is to define a new set of AVPs which would make it > > easy for the implementation to determine if it is supported or not. There > > should not be a case where a subset of the received AVPs are supported, it > > would make it hard to determine what to do with the ones that are > > understood. > > > > A third way could be to keep the filter rules as they are today, and if > > someone would like to support another implementation they will make it > > vendor specific. > > > > /Fredrik From owner-aaa-bof@merit.edu Fri Mar 16 10:00:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04584 for ; Fri, 16 Mar 2001 10:00:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA4A75DE17; Fri, 16 Mar 2001 09:59:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A617B5DE19; Fri, 16 Mar 2001 09:59:01 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 57A565DE17 for ; Fri, 16 Mar 2001 09:58:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA29845; Fri, 16 Mar 2001 06:58:47 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26966; Fri, 16 Mar 2001 06:58:43 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA20949; Fri, 16 Mar 2001 06:58:41 -0800 (PST) Date: Fri, 16 Mar 2001 06:58:39 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Mobile IP Extension To: Bernard Aboba Cc: Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Can you provide some background on what constitutes an extension? > What, for example, distinguishes an extension from something in the > base protocol? Historically, an extension consists of at least one command code. I realize my e-mail was off the wall, but I listed it as an option. Taking that option, of course, would lead us in unchartered Diameter territory... > Also, how is the DIAMETER extensibility model different from the > RADIUS model? Can a DIAMETER server send an arbitrary AVP to a > DIAMETER client, as can be done in RADIUS? Or is it more like > RPC, where you have a way of transmitting arbitrary data over > the wire (XDR), but you need to have the same functions > implemented on both client and server? A mix of both. During the DRI, you discovery your peer's capabilities, and don't send any messages whose extension wasn't advertised. Each message has a list of AVPs that MUST, and SHOULD, be present. Of course, one can always add some other arbitrary AVP in the message, and hope that the other end supports it, as in RADIUS, and there isn't much we can do to protect against that, IMHO. However, if the Mobile IP extension does include the Filter-Rule AVP from the NASREQ extension, then people will expect it to be present, and we will not get in any trouble. However, if it isn't explicitely stated in the extension, chances are it will be unrecognized by implementations that do not support the NASREQ extension. Hope this helps, PatC From owner-aaa-bof@merit.edu Fri Mar 16 15:47:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12645 for ; Fri, 16 Mar 2001 15:47:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 936AE5DF10; Fri, 16 Mar 2001 15:19:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 68F225E1E4; Fri, 16 Mar 2001 15:00:22 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 343BD5DEDF for ; Fri, 16 Mar 2001 14:42:52 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2GJXwN04752; Fri, 16 Mar 2001 11:33:58 -0800 From: "Bernard Aboba" To: "Patrice Calhoun" Cc: , Subject: RE: [AAA-WG]: Mobile IP Extension Date: Fri, 16 Mar 2001 11:43:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Historically, an extension consists of at least one command code. I realize my >e-mail was off the wall, but I listed it as an option. Taking that option, of >course, would lead us in unchartered Diameter territory... OK, this makes sense. Extensions are created only to support new message types, not just new AVPs. I'd recommend that these paragraphs be put in the spec somewhere to make sure this is clear. >A mix of both. >During the DRI, you discovery your peer's capabilities, and don't send any >messages whose extension wasn't advertised. Each message has a list of AVPs >that MUST, and SHOULD, be present. Of course, one can always add some other >arbitrary AVP in the message, and hope that the other end supports it, as in >RADIUS, and there isn't much we can do to protect against that, IMHO. OK. As a result of this, I would say that any AVP that is listed as a MUST, SHOULD or MAY within multiple extensions should go into the Base Protocol. Also, for RADIUS interoperability, I would suggest that any AVP or message that is defined in RFC 2865-2869 should also go into the base protocol. That way any DIAMETER implementation can be guaranteed to be able to gateway RADIUS messages, as noted in the requirements. This means that Accounting and NASREQ extensions need to be mandatory to implement. From owner-aaa-bof@merit.edu Fri Mar 16 15:52:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12778 for ; Fri, 16 Mar 2001 15:52:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id D055E5DF25; Fri, 16 Mar 2001 15:24:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AFBC65E056; Fri, 16 Mar 2001 15:03:14 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 521F25E14C for ; Fri, 16 Mar 2001 14:52:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15315; Fri, 16 Mar 2001 11:52:04 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23018; Fri, 16 Mar 2001 11:52:04 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA20676; Fri, 16 Mar 2001 11:52:02 -0800 (PST) Date: Fri, 16 Mar 2001 11:52:01 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Mobile IP Extension To: Bernard Aboba Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Historically, an extension consists of at least one command code. I realize > my > >e-mail was off the wall, but I listed it as an option. Taking that option, > of > >course, would lead us in unchartered Diameter territory... > > OK, this makes sense. Extensions are created only to support new message > types, > not just new AVPs. I'd recommend that these paragraphs be put in the spec > somewhere to make sure this is clear. ok, will do. > > >A mix of both. > > >During the DRI, you discovery your peer's capabilities, and don't send any > >messages whose extension wasn't advertised. Each message has a list of AVPs > >that MUST, and SHOULD, be present. Of course, one can always add some other > >arbitrary AVP in the message, and hope that the other end supports it, as > in > >RADIUS, and there isn't much we can do to protect against that, IMHO. > > OK. As a result of this, I would say that any AVP that is listed as a MUST, > SHOULD > or MAY within multiple extensions should go into the Base Protocol. Also, > for > RADIUS interoperability, I would suggest that any AVP or message that is > defined in > RFC 2865-2869 should also go into the base protocol. That way any DIAMETER > implementation can be guaranteed to be able to gateway RADIUS messages, as > noted in the requirements. This means that Accounting and NASREQ extensions > need to be mandatory to implement. hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of Diamter-only AVPs, and mandating those would be a mistake, IMHO. Perhaps it is necessary to split up the NASREQ extension into two. One containing all of the RADIUS attributes, and the other containing the Diameter-only attributes. Or perhaps just a paragraph in the base that states that a Diameter implementation MUST support all attributes in RFC 2865-2869. However, both of the above is a red herring, since the initial Diameter deployment will be for Mobile IP, and they don't even need any RADIUS compatibility. PatC From owner-aaa-bof@merit.edu Fri Mar 16 17:14:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14016 for ; Fri, 16 Mar 2001 17:14:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06CB05DF01; Fri, 16 Mar 2001 17:01:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A60455DE34; Fri, 16 Mar 2001 16:52:11 -0500 (EST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by segue.merit.edu (Postfix) with ESMTP id 819355E0FD for ; Fri, 16 Mar 2001 16:40:42 -0500 (EST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Fri, 16 Mar 2001 15:32:29 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 15:37:34 -0600 Message-ID: From: "Haseeb Akhtar" To: "'Patrice Calhoun'" , Bernard Aboba Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Mobile IP Extension Date: Fri, 16 Mar 2001 15:37:29 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE61.4D4B38D0" X-Orig: Sender: owner-aaa-bof@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_01C0AE61.4D4B38D0 Content-Type: text/plain; charset="iso-8859-1" Hello all, I also agree that there should be a separate extension that would only describe the Radius only attributes for Diameter. That could also be part of the base protocol. Since the early implementation of Diameter (Mobile IP) does not require the Nasreq extension, it ought be optional. Regards, Haseeb -----Original Message----- From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] Sent: Friday, March 16, 2001 1:52 PM To: Bernard Aboba Cc: Patrice Calhoun; aaa-wg@merit.edu; diameter@diameter.org Subject: RE: [AAA-WG]: Mobile IP Extension > >Historically, an extension consists of at least one command code. I realize > my > >e-mail was off the wall, but I listed it as an option. Taking that option, > of > >course, would lead us in unchartered Diameter territory... > > OK, this makes sense. Extensions are created only to support new message > types, > not just new AVPs. I'd recommend that these paragraphs be put in the spec > somewhere to make sure this is clear. ok, will do. > > >A mix of both. > > >During the DRI, you discovery your peer's capabilities, and don't send any > >messages whose extension wasn't advertised. Each message has a list of AVPs > >that MUST, and SHOULD, be present. Of course, one can always add some other > >arbitrary AVP in the message, and hope that the other end supports it, as > in > >RADIUS, and there isn't much we can do to protect against that, IMHO. > > OK. As a result of this, I would say that any AVP that is listed as a MUST, > SHOULD > or MAY within multiple extensions should go into the Base Protocol. Also, > for > RADIUS interoperability, I would suggest that any AVP or message that is > defined in > RFC 2865-2869 should also go into the base protocol. That way any DIAMETER > implementation can be guaranteed to be able to gateway RADIUS messages, as > noted in the requirements. This means that Accounting and NASREQ extensions > need to be mandatory to implement. hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of Diamter-only AVPs, and mandating those would be a mistake, IMHO. Perhaps it is necessary to split up the NASREQ extension into two. One containing all of the RADIUS attributes, and the other containing the Diameter-only attributes. Or perhaps just a paragraph in the base that states that a Diameter implementation MUST support all attributes in RFC 2865-2869. However, both of the above is a red herring, since the initial Diameter deployment will be for Mobile IP, and they don't even need any RADIUS compatibility. PatC ------_=_NextPart_001_01C0AE61.4D4B38D0 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: Mobile IP Extension

Hello all,

I also agree that there should be a separate extension
that would only describe the Radius only attributes for
Diameter. That could also be part of the base protocol.

Since the early implementation of Diameter (Mobile IP)
does not require the Nasreq extension, it ought be optional.

Regards,

Haseeb

-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM]
Sent: Friday, March 16, 2001 1:52 PM
To: Bernard Aboba
Cc: Patrice Calhoun; aaa-wg@merit.edu; diameter@diameter.org
Subject: RE: [AAA-WG]: Mobile IP Extension


> >Historically, an extension consists of at least one command code. I realize
> my
> >e-mail was off the wall, but I listed it as an option. Taking that option,
> of
> >course, would lead us in unchartered Diameter territory...
>
> OK, this makes sense. Extensions are created only to support new message
> types,
> not just new AVPs. I'd recommend that these paragraphs be put in the spec
> somewhere to make sure this is clear.

ok, will do.

>
> >A mix of both.
>
> >During the DRI, you discovery your peer's capabilities, and don't send any
> >messages whose extension wasn't advertised. Each message has a list of AVPs
> >that MUST, and SHOULD, be present. Of course, one can always add some other
> >arbitrary AVP in the message, and hope that the other end supports it, as
> in
> >RADIUS, and there isn't much we can do to protect against that, IMHO.
>
> OK. As a result of this, I would say that any AVP that is listed as a MUST,
> SHOULD
> or MAY within multiple extensions should go into the Base Protocol. Also,
> for
> RADIUS interoperability, I would suggest that any AVP or message that is
> defined in
> RFC 2865-2869 should also go into the base protocol. That way any DIAMETER
> implementation can be guaranteed to be able to gateway RADIUS messages, as
> noted in the requirements. This means that Accounting and NASREQ extensions
> need to be mandatory to implement.

hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of
Diamter-only AVPs, and mandating those would be a mistake, IMHO.

Perhaps it is necessary to split up the NASREQ extension into two. One
containing all of the RADIUS attributes, and the other containing the
Diameter-only attributes.

Or perhaps just a paragraph in the base that states that a Diameter
implementation MUST support all attributes in RFC 2865-2869. However, both of
the above is a red herring, since the initial Diameter deployment will be for
Mobile IP, and they don't even need any RADIUS compatibility.

PatC


------_=_NextPart_001_01C0AE61.4D4B38D0-- From owner-aaa-bof@merit.edu Fri Mar 16 18:19:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14821 for ; Fri, 16 Mar 2001 18:19:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 580945DE5C; Fri, 16 Mar 2001 18:17:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20BD35DDD5; Fri, 16 Mar 2001 18:09:19 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 245A05DDED for ; Fri, 16 Mar 2001 18:03:34 -0500 (EST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Fri, 16 Mar 2001 16:57:52 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Mar 2001 16:57:48 -0600 Message-ID: From: "Haseeb Akhtar" To: "'Pat Calhoun'" , John Alayari , "'Tony Johansson'" Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: More about Dynamic HA at visited domain and reducing delay Date: Fri, 16 Mar 2001 16:57:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0AE6C.80CEEE80" Sender: owner-aaa-bof@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_01C0AE6C.80CEEE80 Content-Type: text/plain; charset="iso-8859-1" Hello all, The following is the detail of the proposal that I mentioned last week that deals with allocating an HA at the visited network. Of course, this proposal only uses two messages (namely AMR and AAR) through out this entire process. FA --AMR(1)------>AAAF----AMR(2)--->AAAH HA <--AMA(4)------AAAF<---AMA(3)----AAAH FA <---AMA(6)-----AAAF<---AMA(5)----HA (1) The FA sends an AMR to AAAF (Destination Realm = AAAH, Origin FQDN = FA, MIP Feature Vector = HA_in_Foreign_Network). (2) AAAF receives the message and forwards it to AAAH based on the Destination Realm (Destination Realm = AAAH, Origin FQDN = FA, MIP Feature Vector = HA_in_Foreign_Network). (3) The AAAH receives the message, sees the MIP Feature Vector and does other necessary functions. It then sends an AMA to the AAAF with rest of the keys and so forth. It attaches the MIP Feature Vector into the AMA and copies the Origin FQDN into a new AVP called FA FQDN (Destination Realm = AAAF, MIP Feature Vector = HA_in_Foreign_Network, FA FQDN = FA). (4) The AAAF now receives an AMA and sees the MIP Feature Vector to contain HA_in_Foreign_Network and the Destination Realm is same as its own realm. Therefore, it knows to select an HA (at the visited network) and hence forwards pretty much the same AMA to a selected HA (Destination Realm = AAAF, MIP Feature Vector = HA_in_Foreign_Network, FA FQDN = FA). (5) The HA does its thing and forwards the AMA to the AAAF with Destination FQDN = FA. This will also allow multiple FAs to interface with single AAAF and the everybody in the route will exactly know as to what FA the final message needs to go to (Destination Realm = AAAF, Destination FQDN = FA). (6) The AAAF looks at the Destination FQDN of the AMA and then ships it to the appropriate FA (Destination Realm = AAAF). The only time that the AAAF/AAAH needs to behave differently, that is do different things from the current implementation, is when it receives the MIP Feature Vector as HA_in_Foreign_Network, and the Destination Realm contains its own Realm (as in step 4 above). As I mentioned earlier, a new AVP FA FQDN is needed to scale multiple FAs with one AAAF server. Regards, Haseeb ------_=_NextPart_001_01C0AE6C.80CEEE80 Content-Type: text/html; charset="iso-8859-1" More about Dynamic HA at visited domain and reducing delay

Hello all,

The following is the detail of the proposal that I mentioned last
week that deals with allocating an HA at the visited network.

Of course, this proposal only uses two messages (namely AMR and
AAR) through out this entire process.

FA --AMR(1)------>AAAF----AMR(2)--->AAAH

HA <--AMA(4)------AAAF<---AMA(3)----AAAH

FA <---AMA(6)-----AAAF<---AMA(5)----HA


(1) The FA sends an AMR to AAAF (Destination Realm = AAAH, Origin
    FQDN = FA, MIP Feature Vector = HA_in_Foreign_Network).

(2) AAAF receives the message and forwards it to AAAH based on the
    Destination Realm (Destination Realm = AAAH, Origin
    FQDN = FA, MIP Feature Vector = HA_in_Foreign_Network).

(3) The AAAH receives the message, sees the MIP Feature Vector
    and does other necessary functions. It then sends an AMA to the
    AAAF with rest of the keys and so forth. It attaches the MIP
    Feature Vector into the AMA and copies the Origin FQDN into
    a new AVP called FA FQDN (Destination Realm = AAAF,
    MIP Feature Vector = HA_in_Foreign_Network, FA FQDN = FA).

(4) The AAAF now receives an AMA and sees the MIP Feature Vector
    to contain HA_in_Foreign_Network and the Destination Realm is
    same as its own realm. Therefore, it knows to select an HA
    (at the visited network) and hence forwards pretty much
    the same AMA to a selected HA (Destination Realm = AAAF,
    MIP Feature Vector = HA_in_Foreign_Network,
    FA FQDN = FA).

(5) The HA does its thing and forwards the AMA to the AAAF with
    Destination FQDN = FA. This will also allow multiple FAs to
    interface with single AAAF and the everybody in the route will
    exactly know as to what FA the final message needs to go to
    (Destination Realm = AAAF, Destination FQDN = FA).

(6) The AAAF looks at the Destination FQDN of the AMA and then
    ships it to the appropriate FA (Destination Realm = AAAF).

The only time that the AAAF/AAAH needs to behave differently, that is
do different things from the current implementation, is when it receives
the MIP Feature Vector as HA_in_Foreign_Network, and the Destination
Realm contains its own Realm (as in step 4 above).

As I mentioned earlier, a new AVP FA FQDN is needed to scale multiple
FAs with one AAAF server.

Regards,

Haseeb

------_=_NextPart_001_01C0AE6C.80CEEE80-- From owner-aaa-bof@merit.edu Fri Mar 16 21:38:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18387 for ; Fri, 16 Mar 2001 21:38:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95D615DDF7; Fri, 16 Mar 2001 21:35:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 840785DDDE; Fri, 16 Mar 2001 21:35:29 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 86C8B5DD8D for ; Fri, 16 Mar 2001 21:35:27 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2H2QmN25863; Fri, 16 Mar 2001 18:26:48 -0800 From: "Bernard Aboba" To: "Patrice Calhoun" Cc: , Subject: RE: [AAA-WG]: Mobile IP Extension Date: Fri, 16 Mar 2001 18:36:29 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >hmm... well NASREQ has much more than just RADIUS, it has a whole bunch of >Diamter-only AVPs, and mandating those would be a mistake, IMHO. What is the downside of including these attributes in the base protocol? Assuming that the additional attributes require no new server code, then we're just talking about shipping some additional dictionary entries, right? I suppose that there is now the risk of introducing semantic errors that wouldn't exist otherwise. For example, a Diameter server sending a dialup-only attribute to a Mobile-IP enabled NAS. However, if you send those attributes to a client that doesn't understand them, you get an error message back, so nothing bad happens. >since the initial Diameter deployment will be for Mobile IP, and they >don't even need any RADIUS compatibility. Are we saying that the ability to gateway to RADIUS is not a requirement of the base protocol? I think that this is an important decision to make. From owner-aaa-bof@merit.edu Sun Mar 18 22:25:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15879 for ; Sun, 18 Mar 2001 22:25:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F3125DDE4; Sun, 18 Mar 2001 22:24:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1F1705DDE9; Sun, 18 Mar 2001 22:24:46 -0500 (EST) Received: from internaut.internaut.COM (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4079A5DDE4 for ; Sun, 18 Mar 2001 22:24:44 -0500 (EST) Received: from localhost (aboba@localhost) by internaut.internaut.COM (8.9.3/8.9.3) with ESMTP id TAA15850; Sun, 18 Mar 2001 19:19:21 -0800 (PST) (envelope-from aboba@internaut.com) Date: Sun, 18 Mar 2001 19:19:21 -0800 (PST) From: Bernard Aboba To: randy@psg.com, bwijnen@lucent.com Cc: dmitton@nortelnetworks.com, aaa-wg@merit.edu, aboba@internaut.com Subject: [AAA-WG]: Completion of AAA WG last call on draft-ietf-aaa-proto-eval-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk The AAA WG has completed last call on draft-ietf-aaa-proto-eval-02.txt. No comments were received during last call. The AAA WG recomments to the IESG that this draft be published as an informational RFC. From owner-aaa-bof@merit.edu Mon Mar 19 17:23:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23868 for ; Mon, 19 Mar 2001 17:23:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3687C5DE87; Mon, 19 Mar 2001 17:22:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1FCAD5DF58; Mon, 19 Mar 2001 17:22:39 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B7FC95E1F8 for ; Mon, 19 Mar 2001 17:16:43 -0500 (EST) Received: from fredrikj (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id XAA09204; Mon, 19 Mar 2001 23:16:20 +0100 From: "Fredrik Johansson" To: "Barney Wolff" Cc: "David Spence" , "Pat Calhoun" , , Subject: RE: [diameter] Re: [AAA-WG]: Mobile IP Extension Date: Mon, 19 Mar 2001 22:18:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20010316004959.A13218@mx.databus.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Of course we can not leave the evaluation order unspecified. And I agree that the semantics are more important than the syntax. What I don't like is to not have a framework that allows for new options to be added (or at least enables the use of the options available today). What about making the into a grouped avp? Call it which contains a and something like a which is a uint32 with flags for options like keep state, quick ... I also think that one should have the option of grouping filters, i.e. perhaps a , which contains all within a certain group. If it is true that one can just reverse the order of evaluation (would like to check some real examples) we can leave it as it is today, or perhaps indicate the order in the Filter-Option Avp. Comments?!? /Fredrik >-----Original Message----- >From: Barney Wolff [mailto:barney@databus.com] >Sent: den 16 mars 2001 06:50 >To: Fredrik Johansson >Cc: David Spence; Pat Calhoun; aaa-wg@merit.edu; diameter@diameter.org >Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension > > >We MUST NOT leave the order of evaluation unspecified. Personally >I think anything but first match counts is crazy, but whatever we >do, we cannot leave it to the creativity of the enforcement point. >How could any inter-domain or inter-vendor scenario be viable, if >that were so? A NAS that runs on last-match can reverse the order >of the rules before evaluation, but the home server cannot and >should not know the style of the NAS, so must issue the rules in >a standardized form. As a simple example, take the rules > deny tcp eq 6000 > permit tcp ge 1024 > >In all of AAA, semantics is far more important than syntax. I'd >generalize that to any protocol design, and in fact to all of Life. > >Barney Wolff > >On Fri, Mar 16, 2001 at 02:17:45AM +0100, Fredrik Johansson wrote: >> I like the reusablility, but here is a problem with reusing the >filter rules >> as defined in NASREQ since they specified the order of >evaluation. FreeBSD >> uses in order and first match terminates evaluation, however, in >OpenBSD the >> filters are evaluated in order and the last match determines >what to do with >> the packet (unless you add 'quick' to the rule) >> >> I'm not sure if we should try to come up with a general filter >rule that can >> be used no matter what implementation, and perhaps specify some >new AVP that >> takes care of the differences. >> >> Or perhaps, the way to go is to define a new set of AVPs which >would make it >> easy for the implementation to determine if it is supported or not. There >> should not be a case where a subset of the received AVPs are >supported, it >> would make it hard to determine what to do with the ones that are >> understood. >> >> A third way could be to keep the filter rules as they are today, and if >> someone would like to support another implementation they will make it >> vendor specific. >> >> /Fredrik From owner-aaa-bof@merit.edu Mon Mar 19 18:29:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25712 for ; Mon, 19 Mar 2001 18:29:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 85ECD5DF7F; Mon, 19 Mar 2001 18:24:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E04585DF9E; Mon, 19 Mar 2001 18:24:29 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 2EBFA5DE63 for ; Mon, 19 Mar 2001 18:21:34 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2JNL6830782; Mon, 19 Mar 2001 18:21:06 -0500 (EST) (envelope-from barney) Date: Mon, 19 Mar 2001 18:21:06 -0500 From: Barney Wolff To: Fredrik Johansson Cc: Barney Wolff , David Spence , Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension Message-ID: <20010319182106.A30727@mx.databus.com> References: <20010316004959.A13218@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Mon, Mar 19, 2001 at 10:18:27PM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk The filter capability is a compromise. On one side, we want to be able to express powerful filtering. On the other, we don't want to seduce the server into specifying filtering that the NAS (or other enforcement point) does not implement, as we then get into the very messy question of what the NAS should do if it does not implement a particular rule. I made a conscious choice NOT to include keep-state, but that's certainly a debatable issue. Said another way, I hoped to encourage NAS vendors to implement better filtering but not ask for so much that they would decline. Barney On Mon, Mar 19, 2001 at 10:18:27PM +0100, Fredrik Johansson wrote: > Of course we can not leave the evaluation order unspecified. And I agree > that the semantics are more important than the syntax. What I don't like is > to not have a framework that allows for new options to be added (or at least > enables the use of the options available today). > > What about making the into a grouped avp? Call it AVP> which contains a and something like a AVP> which is a uint32 with flags for options like keep state, quick ... > > I also think that one should have the option of grouping filters, i.e. > perhaps a , which contains all within a > certain group. > > If it is true that one can just reverse the order of evaluation (would like > to check some real examples) we can leave it as it is today, or perhaps > indicate the order in the Filter-Option Avp. > > Comments?!? > > /Fredrik From owner-aaa-bof@merit.edu Tue Mar 20 14:56:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21401 for ; Tue, 20 Mar 2001 14:56:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2AD6B5DDCF; Tue, 20 Mar 2001 14:55:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1110A5DDC1; Tue, 20 Mar 2001 14:55:42 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 12DE15DDCF for ; Tue, 20 Mar 2001 14:55:39 -0500 (EST) Received: from fredrikj (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id UAA22758; Tue, 20 Mar 2001 20:55:13 +0100 From: "Fredrik Johansson" To: "Barney Wolff" Cc: "David Spence" , "Pat Calhoun" , , Subject: RE: [diameter] Re: [AAA-WG]: Mobile IP Extension Date: Tue, 20 Mar 2001 19:57:22 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010319182106.A30727@mx.databus.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Ok, the filter capability is a compromise, and all implementations will certainly not support all possible options, but to remove the options of one of the most commonly used freewares is something that can be discussed. I don't know much about how filters are used in a NAS, but I can only assume that that was a valid choise considering it is only specified for use with NASREQ. However, as more extensions (MIP) are looking at using filter rules, I believe that it would be nice to have a common set rules that can be reused. The question is where they should be located (NASREQ, MIP, BASE, or stand alone) and the format and options to include. The problem with a NAS (or other enforcement point) that does not support an option can be solved by having the NAS responde with a failed AVP idicating what options that was not supported. The server can then try to send another set of rules. Another thing is that AAA server usually know from what kind of enforcement point it is receiving the request from, i.e. it can decide on what kind of filters to send to it. This way it is easy to configure not to send keep state to a NAS. /Fredrik >-----Original Message----- >From: Barney Wolff [mailto:barney@databus.com] >Sent: den 20 mars 2001 00:21 >To: Fredrik Johansson >Cc: Barney Wolff; David Spence; Pat Calhoun; aaa-wg@merit.edu; >diameter@diameter.org >Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension > > >The filter capability is a compromise. On one side, we want to be >able to express powerful filtering. On the other, we don't want >to seduce the server into specifying filtering that the NAS (or >other enforcement point) does not implement, as we then get into >the very messy question of what the NAS should do if it does not >implement a particular rule. I made a conscious choice NOT >to include keep-state, but that's certainly a debatable issue. > >Said another way, I hoped to encourage NAS vendors to implement >better filtering but not ask for so much that they would decline. > >Barney > >On Mon, Mar 19, 2001 at 10:18:27PM +0100, Fredrik Johansson wrote: >> Of course we can not leave the evaluation order unspecified. And I agree >> that the semantics are more important than the syntax. What I >don't like is >> to not have a framework that allows for new options to be added >(or at least >> enables the use of the options available today). >> >> What about making the into a grouped avp? Call >it > AVP> which contains a and something like a >> AVP> which is a uint32 with flags for options like keep state, quick ... >> >> I also think that one should have the option of grouping filters, i.e. >> perhaps a , which contains all within a >> certain group. >> >> If it is true that one can just reverse the order of evaluation >(would like >> to check some real examples) we can leave it as it is today, or perhaps >> indicate the order in the Filter-Option Avp. >> >> Comments?!? >> >> /Fredrik From owner-aaa-bof@merit.edu Tue Mar 20 15:39:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23748 for ; Tue, 20 Mar 2001 15:39:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id AAE7B5DE63; Tue, 20 Mar 2001 15:38:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 971715DE5E; Tue, 20 Mar 2001 15:38:48 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7EE1A5DE41 for ; Tue, 20 Mar 2001 15:38:47 -0500 (EST) Received: from merit.edu (pcp001293pcs.wireless.meeting.ietf.org [135.222.67.25]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 5C47F72 for ; Tue, 20 Mar 2001 15:39:02 -0500 (EST) Message-ID: <3AB7BFB9.65FC17E@merit.edu> Date: Tue, 20 Mar 2001 14:38:17 -0600 From: "John R. Vollbrecht" Reply-To: JRV@Interlinknetworks.com Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [Fwd: Re: [AAA-WG]: AAA WG last call on draft-ietf-aaa-isssues-04.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > This is the AAA Working Group last call on draft-ietf-aaa-isssues-04.txt > before sending it on to IETF Last Call. This draft is recommended > for Informational status. If you have comments on it, please > send them to the authors or to the aaa-wg@merit.edu mailing > list BEFORE February 28, 2001. http://www.ietf.org/internet-drafts/draft-ietf-aaa-isssues-04.txt > I would like to suggest a couple issues that I do not think have been covered. I am unable to access the draft on the ietf repository, so I am unable to suggest exactly how these would be incorporated in the draft. 1. Hop by hop security and audit. It seems desirable to be able to demonstrate that a valid security association existed between servers at the time a transaction occurs. This might be accomplished by including a MAC (as proposed for ete security) on each message. For those willing to support the overhead of a MAC this would be sufficient. Alternatively, the AAA servers might know about hop by hop security associations and include an indication of this in useage logs for accounting purposes. In RADIUS this indication is in the message authenticator. If DIAMETER uses IPSEC or SSL for hop by hop security a mechanism for providing auditing of the security association needs to be described. 2. Managing multiple resources DIAMETER currently assumes that a Session ID will be created by the requestor (NAS) and used by all subsequent proxies. This approach seems to mean that adding a resource to a session, for example adding an additional ISDN channel to a multilink call, requires a separate session to be created and then linked somehow to the initial session. Some method of handling multiple resource sessions associated with a single useage session should be described. Regards John Vollbrecht From owner-aaa-bof@merit.edu Tue Mar 20 15:46:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24147 for ; Tue, 20 Mar 2001 15:46:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 59DE55DDA0; Tue, 20 Mar 2001 15:41:25 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3AE2E5DE0C; Tue, 20 Mar 2001 15:41:25 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id EB2F95DDA0 for ; Tue, 20 Mar 2001 15:41:19 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2KKf8I34803; Tue, 20 Mar 2001 15:41:08 -0500 (EST) (envelope-from barney) Date: Tue, 20 Mar 2001 15:41:08 -0500 From: Barney Wolff To: Fredrik Johansson Cc: Barney Wolff , David Spence , Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Mobile IP Extension Message-ID: <20010320154108.A34699@mx.databus.com> References: <20010319182106.A30727@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from fredrik.johansson@ipunplugged.com on Tue, Mar 20, 2001 at 07:57:22PM +0100 Sender: owner-aaa-bof@merit.edu Precedence: bulk The point of the compromise is to *avoid* the situation where some rule types are not supported by a popular implementation. If we were willing to make the server deal with negotiation of rule sets we could have defined an infinitely powerful filter capability. IMHO that would be a very bad idea. Diameter is a security protocol, and simplicity is your friend. (Yes I know, "simplicity" and "Diameter" in the same sentence approaches parody. But we shouldn't make it even worse.) Regards, Barney On Tue, Mar 20, 2001 at 07:57:22PM +0100, Fredrik Johansson wrote: > Ok, the filter capability is a compromise, and all implementations will > certainly not support all possible options, but to remove the options of one > of the most commonly used freewares is something that can be discussed. ... From owner-aaa-bof@merit.edu Tue Mar 20 17:12:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA28055 for ; Tue, 20 Mar 2001 17:12:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29D515DF50; Tue, 20 Mar 2001 17:12:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0A4F05DFE2; Tue, 20 Mar 2001 17:12:14 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 4B3AE5DF50 for ; Tue, 20 Mar 2001 17:12:12 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id OAA14311; Tue, 20 Mar 2001 14:12:15 -0800 (PST) Date: Tue, 20 Mar 2001 17:10:44 -0500 (EST) From: Justin Britten To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: username len Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I can't find any reference to a maximum username length in the Diameter drafts. Since User-Name AVP is of type OctetString, and the draft states that the maximum avp length is 65527, does this mean the username can be up to 65519 bytes? (8 bytes go to avp header) Also, how was the maximum length value of 65527 determined? If the minimum diameter packet header is 16 bytes doesn't this mean the maximum avp length is 65535 - 16 = 65519 (techically 65516 when set on an even word boundary)? Now, the max username is 65508. OctetString The data contains arbitrary data of variable length. Unless otherwise noted, the AVP Length field MUST be set to at least 9 (13 if the 'V' bit is enabled). Data used to transmit (human readable) character string data uses the UTF-8 [24] character set and is NOT NULL-terminated. The minimum Length field MUST be 9, but can be set to any value up to 65527 bytes. AVP Values of this type that do not align on a 32-bit boundary MUST have the necessary padding. Thanks, Justin From owner-aaa-bof@merit.edu Tue Mar 20 17:35:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29091 for ; Tue, 20 Mar 2001 17:35:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0415B5DF7C; Tue, 20 Mar 2001 17:33:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CF06D5DF13; Tue, 20 Mar 2001 17:33:28 -0500 (EST) Received: from mail01.bridgewatersystems.com (unknown [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 860A45DF7C for ; Tue, 20 Mar 2001 17:33:25 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id SAA10597; Tue, 20 Mar 2001 18:29:32 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA13382; Tue, 20 Mar 2001 17:33:52 -0500 (EST) From: "Mark Jones" To: "David Spence" Cc: "Pat Calhoun" , , Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Tue, 20 Mar 2001 17:34:31 -0500 Message-ID: <005901c0b18d$ee39e2d0$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <3AAEA200.5DFF02FD@Interlinknetworks.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have been giving the implementation of the DRI some further thought and have a few comments and questions. I think the communication of a device reboot event should be decoupled from the identity/capability exchange since the establishment of the transport connection does not necessarily imply a reboot of either peer. For example, a routing proxy may wait until it has a command destined for a particular Diameter peer before establishing a connection. New event types in the Device-Status-Indicator command should be used to communicate the device reboot events instead. If this proposal is accepted, I suggest renaming the Device-Reboot-Indicator command to Device-Capability-Indicator. Command names aside, I understand that the capabilities of a Diameter peer are unlikely to be fully described by the list of extension ids that it supports. The receiver of the DRI also needs to be aware of the vendor-specific AVPs and commands supported by the peer and I agree that we should not attempt to communicate this in the DRI. It follows that this capability set must already be known by the receiver in order for any vendor-specific AVPs/commands to be exchanged. In other words, the receiver must know that firmware revision [x] running on product [y] from device vendor [z] supports a given set of extensions and/or vendor-specific AVPs/commands. Hence, the DRI should contain these device identity AVPs in a machine-friendly format in order for the peer to lookup the device's capability set. I think this requirement would be better served by three separate AVPs (Firmware-Revision/Product-Id/Vendor-Id) than the free-format Vendor-Product-Name AVP that was proposed for debugging purposes. Does the inclusion of an extension id in the DRI imply that the device supports the functionality described in the extension using only the commands and attributes defined in the extension, i.e. without addition of any mandatory vendor-specific commands/attributes? Would it be valid for a device claiming support for the Mobile-IP extension to discard an AMA command because it was missing a vendor-specific AVP that the device's vendor considered mandatory? Regards, Mark From owner-aaa-bof@merit.edu Tue Mar 20 17:59:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29977 for ; Tue, 20 Mar 2001 17:59:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id E03315DF4E; Tue, 20 Mar 2001 17:54:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 993635DF6B; Tue, 20 Mar 2001 17:54:55 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 1AA165DE41 for ; Tue, 20 Mar 2001 17:44:35 -0500 (EST) Received: (qmail 10379 invoked by uid 500); 20 Mar 2001 23:15:37 -0000 Date: Tue, 20 Mar 2001 17:15:36 -0600 From: David Frascone To: Justin Britten Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: username len Message-ID: <20010320171536.A20497@newman.frascone.com> Mail-Followup-To: Justin Britten , aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jbritten@cisco.com on Tue, Mar 20, 2001 at 05:10:44PM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Mar 20, 2001 at 05:10:44PM -0500, Justin Britten wrote: > > I can't find any reference to a maximum username length in the Diameter > drafts. Since User-Name AVP is of type OctetString, and the draft > states that the maximum avp length is 65527, does this mean the > username can be up to 65519 bytes? (8 bytes go to avp header) I have always assumed that the username could be arbitrarily long. (I.e. only constrained by the maximum payloads) > Also, how was the maximum length value of 65527 determined? If the > minimum diameter packet header is 16 bytes doesn't this mean the maximum > avp length is 65535 - 16 = 65519 (techically 65516 when set on an even > word boundary)? Now, the max username is 65508. I think I see what Pat did :) He did his math only taking into consideration the size of the AVP header, and did not notice that it would cause the AVP to grow too large to be able to fit into a Diameter message. i.e.: The maximum length of an avp is 0xffff or 65535 bytes. Subtracting the minimum header length (8 bytes) yields a AVP size of 65527 bytes. I think your number is more accurate. . . . anyone else wanna check the math? From owner-aaa-bof@merit.edu Tue Mar 20 20:17:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05717 for ; Tue, 20 Mar 2001 20:17:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 417F25DECB; Tue, 20 Mar 2001 20:16:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 278F75DF81; Tue, 20 Mar 2001 20:16:06 -0500 (EST) Received: from cairo.funk.com (unknown [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 468705DECB for ; Tue, 20 Mar 2001 20:16:04 -0500 (EST) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id UAA20763; Tue, 20 Mar 2001 20:09:28 -0500 (EST) Message-Id: <4.1.20010320194913.01716720@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 20 Mar 2001 19:57:18 -0500 To: aaa-wg@merit.edu, diameter@diameter.org, Patrice Calhoun From: Paul Funk Subject: [AAA-WG]: Connections that pass in the night Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk It has been decided that a pair of Diameter peers may have at most one open transport layer connection between them. This poses some difficulty when both peers attempt to open connections simultaneously. An election process is required to allow both peers to come to the same conclusion as to which connection will survive. Implementing such a mechanism can be tricky. Specifying peer behavior via a state machine is trickier still, since the different stages that each of the connections may be in leads to an unwieldy number of states to consider. In his Connectathon summary, Pat described an approach as to how an election might proceed. This proposal attempts to make such an approach quite explicit. It differs from Pat's approach in two respects. Origin-FQDN, rather than Identifier, is used for the election, because Identifier could result in a tie. And, while Pat's approach requires that the responder wait for the initiator's DRI before sending its own, this proposal permits the responder to send DRI immediately in most cases, reducing startup latency. What follows is a state machine proposal that I believe produces the desired behavior, can be expressed (relatively) clearly, and can be readily translated to an implementation. The basic idea is to define two state machines, one for each direction. Thus, each Diameter peer implements two state machines, one as the "initiator" of a connection, and one as the "responder". There is a minimum of interaction between the two state machines, and it is guaranteed that the result will be a single open connection. Also, it is guaranteed that even if one of the peers behaves incorrectly, a maximum of one open connection will be established. The two stable states that either state machine may be in are Closed and Open; all other states are intermediate. The overall connection with the peer is considered open if either the initiator or responder is in the Open state. I apologize for the excruciating detail, but I do think that this level of specificity is necessary to ensure correct interoperation. Initiator --------- state event action next state ------------------------------------------------------------- Closed Start Snd-Conn-Req Wait-Conn-Ack OR Closed (see note 1) Wait-Conn-Ack Rcv-Conn-Ack Snd-DRI Wait-DRI Rcv-Conn-Nack Closed Cancel Canceling Timeout Error Closed Canceling Rcv-Conn-Ack Snd-Disc-Req Closing Rcv-Conn-Nack Closed Timeout Error Closed Wait-DRI Rcv-DRI Open Rcv-Non-DRI Error Closed Cancel Snd-Disc-Req Closing Rcv-Disc-Req Snd-Disc-Ack Closed Timeout Error Closed Closing Rcv-Disc-Ack Closed Rcv-DRI Discard Closing Rcv-Non-DRI Error Closed Timeout Error Closed Responder --------- state event action next state ---------------------------------------------------------- Closed Rcv-Conn-Req Snd-Conn-Ack Wait-DRI OR Snd-Conn-Ack, Snd-DRI Wait-Open OR Snd-Conn-Nack Closed (see note 2) Wait-Open Rcv-DRI Open Rcv-Non-DRI Error Closed Rcv-Disc-Req Snd-Disc-Ack Closed Rcv-Conn-Req Snd-Conn-Nack Wait-Open Timeout Error Closed Wait-DRI Rcv-DRI Snd-DRI Open OR Snd-DRI, Cancel Open OR Wait-Disc-Req OR Error Closed (see note 3) Rcv-Non-DRI Error Closed Rcv-Disc-Req Snd-Disc-Ack Closed Rcv-Conn-Req Snd-Conn-Nack Wait-DRI Timeout Error Closed Wait-Disc-Req Rcv-Disc-Req Snd-Disc-Ack Closed Rcv-DRI Error Closed Rcv-Non-DRI Error Closed Rcv-Conn-Req Snd-Conn-Nack Wait-Disc-Req Timeout Error Closed Once Open, a single state machines describes further bevavior, regardless of who initiated the surviving connection: state event action next state ---------------------------------------------------------- Open Rcv-Non-DRI Process Open Rcv-DRI Error Closed Stop Snd-Disc-Req Stopping Rcv-Disc-Req Snd-Disc-Ack Closed Stopping Rcv-Disc-Ack Closed Rcv-DRI Error Closed Rcv-Non-DRI Discard Stopping Note 1 ------ When the initiator is in the Closed state and processes a Start event, it acts as follows: (a) If the responder is also in the Closed state, it issues a Snd-Conn-Req to start the connection process. (b) If the responder is not in the Closed state, it ignores the Start event. Note 2 ------ When the responder is in the Closed state and processes a Rcv-Conn-Req, it acts as follows: (a) If the initiator is not in the Open state, it issues a Snd-Conn-Ack. (b) If the initiator is in the Closed state, it MAY follow the Snd-Conn-Ack with Snd-DRI. This is permissible because it knows that only one direction of connection is occurring and no election will be needed. Issuing DRI immediately upon accepting a connection can shorten the time it takes to establish an open connection, and could provide the benefit of piggybacking the DRI onto the same packet carrying the ack. (c) If the initiator is in the Open state, it issues a Snd-Conn-Nack. Note 3 ------ When the responder is in the Wait-DRI state and processes a Rcv-DRI, it acts as follows: (a) If the initiator is in the Closed, Canceling, or Closing states, it issues a Snd-DRI and transitions to Open. (b) If the initiator is in the Wait-Conn-Ack or Wait-DRI state, it performs an election to determine which transport layer connection survives. If it determines that the responder's connection survives, it issues a Snd-DRI followed by a Cancel, and transitions to Open. If it determines that the initiator's connection survives, it takes no action but transitions to Wait-Disc-Req (expecting a disconnect request from its peer). (c) If the initiator is in the Open state, it performs its Error action to close this transport layer connection. This will occur only if the peer misbehaved, by incorrectly or prematurely electing the initiator's connection as the surviving one. Oddly enough, despite the failure of one of the peers to behave properly, the result is that exactly one transport layer connection survives. The Election Process -------------------- The election is performed by the responder. The responder compares the Origin-FQDN received in the DRI sent by its peer with its own Origin-FQDN (which it may or may not have actually sent). The transport layer connection with the higher value of Origin-FQDN is the one that survives. The comparison proceeds by considering the shorter OctetString to be null-padded to the length of the longer, then performing an octet by octet unsigned comparison with the first octet being most significant. Hanging octets are assumed to have value 0x80, but dimpled octets are ignored. Note that, depending on the sequence, the election process might be performed by one of the peers or by both of the peers. Action Glossary --------------- "Snd-Conn-Req" means to send a request to open a transport layer connection. "Snd-Conn-Ack" means to send an acknowledgement in response to a connect request, confirming that the transport layer connection is open. "Snd-Conn-Nack" means to send a negative acknowledgement in response to a connect request, indicating that the request was refused. "Snd-DRI" means to send a DRI. "Error" means to drop the transport layer connection, either politely or abortively, in response to an error condition. "Snd-Disc-Req" means to send a request to close a transport layer connection. "Snd-Disc-Ack" means to acknowledge closure of a transport layer connection, in response to receipt of a disconnect request. "Cancel" means that the responder issues the Cancel event to the initiator state machine, indicating that the responder's transport layer connection will survive and the initiator's transport layer connection will be closed. The Cancel event is the only interaction between the two state machines. "Process" means to service a Diameter message. "Discard" means to ignore a Diameter message. The purpose here is to flush pending reads while waiting for disconnect to be acknowledged. Failure to do this under TCP could (depending on stack implementation) leave the connection half closed. The TCP stack will be in timed wait state, and might refuse subsequent connections from the same address/port for several minutes. I don't know if SCTP has a comparable issue. Event Glossary -------------- "Start" means that the Diameter application has signalled that a connection should be initiated. "Stop" means that the Diameter application has signalled that a connection should be terminated (e.g., on system shutdown). "Cancel" means that the responder state machine has determined that the responder connection will survive and that the initiator's connection should be closed. "Rcv-Conn-Ack" means that the peer has opened the transport layer connection requested by a Snd-Conn-Req. "Rcv-Conn-Nack" means that the peer has refused the transport layer connection requested by a Snd-Conn-Req. "Rcv-Disc-Req" means that the peer has requested that the transport layer connection be closed. "Rcv-Disc-Ack" means that the peer has acknowledged the closure of the transport layer connection requested by a Snd-Disc-Req. "Timeout" means that an application-defined timer has expired while waiting for some event. "Rcv-DRI" means that a DRI has been received. "Rcv-Non-DRI" means that a Diameter message other than DRI has been received. Final Note ---------- I think the draft should clearly state that the state machine specification constrains the only the behavior of a Diameter implementation as seen by Diameter peers through events on the wire. Any implementation that produces equivalent results is considered compliant. Paul Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-bof@merit.edu Wed Mar 21 02:41:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06073 for ; Wed, 21 Mar 2001 02:41:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id B75AF5DEB0; Wed, 21 Mar 2001 02:41:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A62415DEAA; Wed, 21 Mar 2001 02:41:32 -0500 (EST) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by segue.merit.edu (Postfix) with ESMTP id 8E44B5DEA3 for ; Wed, 21 Mar 2001 02:41:30 -0500 (EST) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id JAA22696 for ; Wed, 21 Mar 2001 09:41:29 +0200 (EET) From: "Rami Lehtonen" To: Subject: [AAA-WG]: AAA for IPv6, Key reply option Date: Wed, 21 Mar 2001 09:42:08 +0200 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.00.2919.6700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was reading through the draft, didn't find any information how the attendant can decode the host-attendant key, if the key was encoded by the AAAH (AAAH SPI). Could someone of you help me with this? Regards, Rami Lehtonen From owner-aaa-bof@merit.edu Wed Mar 21 07:35:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17406 for ; Wed, 21 Mar 2001 07:35:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65AF65DE20; Wed, 21 Mar 2001 07:33:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 47C9B5DDE6; Wed, 21 Mar 2001 07:33:52 -0500 (EST) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by segue.merit.edu (Postfix) with ESMTP id E309F5DE6A for ; Wed, 21 Mar 2001 07:33:49 -0500 (EST) Received: from rami (root@varis.cs.tut.fi [130.230.4.42]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id OAA19993 for ; Wed, 21 Mar 2001 14:33:48 +0200 (EET) From: "Rami Lehtonen" To: Subject: [AAA-WG]: AAA for IPv6 draft Date: Wed, 21 Mar 2001 14:34:29 +0200 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.00.2919.6700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Section 4.2.3 says that client may request termination by sending an AAA Request message with a zero lifetime. So it seems that the AAA Request message should also list the lifetime option in the 4.2.1 chapter, where all possible options are listed. Rami From owner-aaa-bof@merit.edu Wed Mar 21 09:59:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23701 for ; Wed, 21 Mar 2001 09:59:27 -0500 (EST) Received: by segue.merit.edu (Postfix) id DEB375DF5E; Wed, 21 Mar 2001 09:57:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6F14A5DFAD; Wed, 21 Mar 2001 09:57:22 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id E73925DFA4 for ; Wed, 21 Mar 2001 09:53:04 -0500 (EST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f2LEr3d26442 for ; Wed, 21 Mar 2001 15:53:03 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Mar 21 15:53:03 2001 +0100 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Mar 2001 15:53:02 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FF1F@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'tony.johansson@ericsson.com'" , "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Indication for Home Agent allocation?? Date: Wed, 21 Mar 2001 15:53:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, 1. What happens if a MN requests an Home Agent in the Foreign Domain, by setting the address of the Home Agent to 255.255.255.255, and that the AAAF does not allow an HA to be allocated within its Foreign Domain? What error should be returned to MN? Should the AMR reach the AAAH at all? Is it at all possible to reject such a request? Should we use the DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE result-code? If yes, then I guess we need to change its description in section 3.1. In fact, I'm wondering if that Home Agent set to 255.255.255.255 is only an indication of a preferred location for the HA?, or it is strongly required for the HA to be in the Foreign Domain??? If it is not strongly required, then I'd say that it would be possible to allocate one in the Home Domain, right? I would say that an AAAF should always recommend an HA to be allocated within the Foreign Domain for optimization purposes, by setting the Foreign-Home-Agent-Available flag whenever it supports it, right? In that case, what is the real need for the indication from the MN? 2. What happens if the MN requests an Home Agent by specifying an address different then 0.0.0.0 and 255.255.255.255, if that HA is unknown in the Home Domain and also in the Foreign Domain? There is no result-code for indicating this to the MN, i.e. that the requested HA is bad, similar as the error for a bad Home Address, we might need DIAMETER_ERROR_BAD_HOME_AGENT, right? Unless an HA should be allocated anyway, assuming that it is a different Home Agent address? Also, the spec says, in section 1.2 page 5 of the Diameter MIP extension -01, that an AMA (now an HAR I guess) must be sent to the AAAF in the case the Home Agent is not known by the AAAH. The thing is that it is not sure yet at this point that the AAAF will necessarily know it either. Then I was wondering if the AAAF should inform that the HA is available by setting the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP, when an HA is specified and it is available locally. That information could be used in the AAAH to be sure that the HA is available as specified in the Home Agent AVP in the Foreign Domain, and allocate a new Home Agent in the Home Domain directly, without asking unnecessarily to the AAAF, if ever it is allowed by the spec to override the Home Agent address when the one sent from the MN is not valid. Regards, /Martin From owner-aaa-bof@merit.edu Wed Mar 21 16:57:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16994 for ; Wed, 21 Mar 2001 16:57:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 29F8E5E032; Wed, 21 Mar 2001 16:52:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 735D55DFC5; Wed, 21 Mar 2001 16:52:19 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 24A985DF8F for ; Wed, 21 Mar 2001 16:50:11 -0500 (EST) Received: (qmail 18997 invoked by uid 500); 21 Mar 2001 22:21:31 -0000 Received: (qmail 11366 invoked from network); 21 Mar 2001 02:02:47 -0000 Received: from jerry.frascone.com (HELO www.frascone.com) (god@192.168.1.1) by newman.frascone.com with SMTP; 21 Mar 2001 02:02:47 -0000 Received: (qmail 30116 invoked by alias); 21 Mar 2001 01:31:53 -0000 Received: (qmail 30113 invoked by uid 7770); 21 Mar 2001 01:31:52 -0000 Received: from unknown (HELO mail01.bridgewatersystems.com) (216.113.7.9) by frascone.com with SMTP; 21 Mar 2001 01:31:52 -0000 Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id VAA11160 for ; Tue, 20 Mar 2001 21:27:43 -0500 Received: from preston (cisconas245.bridgewatersys.com [192.168.150.245]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id UAA15017 for ; Tue, 20 Mar 2001 20:32:03 -0500 (EST) From: "Mark Jones" To: "David Frascone" Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Tue, 20 Mar 2001 20:33:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20010320172056.B20497@newman.frascone.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Whatcha think of that? > I agree that works great for extensions produced by WGs but I'm concerned about the vendor-specific AVPs and commands. If a vendor comes up with a slight variant on mobile IP registration which includes a few additional vendor-specific AVPs, I just can not see them publishing a new extension document for it. From my RADIUS experience, they will simply add the AVPs to the dictionary for their Diameter server (and maybe to their device documentation if we're lucky). Some vendor's even treat their RADIUS VSAs as proprietary information available solely under NDA! My proposal comes out of a reluctant acceptance that the same thing will happen with Diameter and at least the base protocol could provide a means of discovering the identity of the device. Adding the list of supported extension ids to the DRI is useful only if "supports" means the device implements the functionality described in the extension using only the commands and attributes defined in the extension, i.e. without addition of any mandatory vendor-specific AVPs/commands. The extensions then become a useful baseline ensuring interoperability amongst devices from different vendors. I do not remember seeing confirmation of this in the Diameter drafts but I may have missed it. I'm lukewarm on the idea of adding a list of the supported vendor ids to the DRI. On one hand, it does allow the Diameter server to check whether it has a dictionary for that vendor. On the other, the server still has no idea if it has the latest dictionary for that vendor so it still risks receiving unknown VSA. What is your opinion? Regards, Mark From owner-aaa-bof@merit.edu Wed Mar 21 16:59:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17066 for ; Wed, 21 Mar 2001 16:59:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id DAB1C5E033; Wed, 21 Mar 2001 16:52:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E6E135DFE6; Wed, 21 Mar 2001 16:52:20 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 4DBEC5DFA0 for ; Wed, 21 Mar 2001 16:50:32 -0500 (EST) Received: (qmail 19207 invoked by uid 500); 21 Mar 2001 22:21:53 -0000 Received: (qmail 10747 invoked from network); 21 Mar 2001 18:51:48 -0000 Received: from jerry.frascone.com (HELO www.frascone.com) (god@192.168.1.1) by newman.frascone.com with SMTP; 21 Mar 2001 18:51:48 -0000 Received: (qmail 30577 invoked by alias); 21 Mar 2001 18:20:58 -0000 Received: (qmail 30574 invoked by uid 7770); 21 Mar 2001 18:20:57 -0000 Received: from unknown (HELO mail01.bridgewatersystems.com) (216.113.7.9) by frascone.com with SMTP; 21 Mar 2001 18:20:57 -0000 Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA15920 for ; Wed, 21 Mar 2001 14:16:34 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA03646 for ; Wed, 21 Mar 2001 13:20:55 -0500 (EST) From: "Mark Jones" To: "David Frascone" Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Wed, 21 Mar 2001 13:21:32 -0500 Message-ID: <002701c0b233$c1a9a290$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <20010321104642.E19524@newman.frascone.com> Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Well, vendor specific AVPs are ignored by applications/servers that do not > know how to handle them. (Unless, of course, the M bit is set. Then, an > error (MRI) would be returned). > > So, Vendor attributes are currently supported exactly like in > RADIUS. In fact, > you can send any extra AVPs you want, and if they are not > supported/expected, > they will just be ignored. > The approach of ignoring unknown VSAs is (mostly) harmless but it frequently results in a failure to setup the desired service for the subscriber. When the finger pointing stops, the result will be that the Diameter server dictionary gets updated with the AVPs whether they were published in an extension or not. > But, a server can *also* advertise that it knows how to handle specific > vendor AVPs, or optional AVPs by documentint those AVPs in an > extension, and > then advertising that the extension is supported. > > So, I still think that my preposal handles both cases. Don't get me wrong; I think extension ids in the DRI are an excellent idea. I am certainly not arguing for their removal or replacement by vendor ids. But if I understand your proposal correctly, vendors MUST publish the extensions documenting their vendor-specific AVPs/commands. If they do not then their vendor-specific AVPs/commands will simply be ignored by Diameter servers. This sounds like a recipe for a Diameter device only working predictably with a Diameter server if they are both provided by the same vendor. I just don't see the motivation for a vendor to publish their extensions especially if they are also pushing their own Diameter server. The intent of my original email was to stress the importance of the devices identifying themselves (Vendor/Product/Firmware) in the DRI. Although this does not solve the problem, it at least gives third-party Diameter server vendors a chance at interoperability because they can build a knowledge base of the vendor-specific quirks of the devices. > Adding a list of vendor ids or supported AVPs to a DRI is very > ugly, in my > opinion. That's why I'm pushing registering extensions so that several > commands/avps/whatever can be supported with only one addition to the DRI. > I agree that value of the supported vendor ids in the DRI is pretty limited and adding supported AVPs/commands is way too verbose. BTW, I've seen no reaction to my email on the WG mailing lists. Even if I was deemed totally out-to-lunch, somebody is usually kind enough to tell me why. I was unable to attend IETF50 so was there some DRI decision taken down there that would invalidate this discussion? I assume you are in attendence. Regards, Mark From owner-aaa-bof@merit.edu Wed Mar 21 17:01:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17226 for ; Wed, 21 Mar 2001 17:01:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 369B25DF6E; Wed, 21 Mar 2001 16:53:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D5D005DFA0; Wed, 21 Mar 2001 16:52:21 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 6DE245DFD5 for ; Wed, 21 Mar 2001 16:51:14 -0500 (EST) Received: (qmail 19714 invoked by uid 500); 21 Mar 2001 22:22:35 -0000 Date: Tue, 20 Mar 2001 17:20:56 -0600 From: David Frascone To: Mark Jones Subject: Re: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Message-ID: <20010320172056.B20497@newman.frascone.com> References: <3AAEA200.5DFF02FD@Interlinknetworks.com> <005901c0b18d$ee39e2d0$2096a8c0@mjones.bridgewatersys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <005901c0b18d$ee39e2d0$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Tue, Mar 20, 2001 at 05:34:31PM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree that there needs to be a mechanism to exchange what AVPs might be supported, but I disagree with your method. I would prefer to allow extensions to not only specify AVPs in new command codes, but also specify new sets of AVPs for extensions. For example, extension 123 could be a list of 5 AVPs that some application needs supported with existing command codes defined in the base protocol or other extensions drafts. So, in my opinion, the current protocol could easily support mandating the support of particular AVPs, by loosening the definition of "extension" to handle arbitrary AVPs. Whatcha think of that? On Tue, Mar 20, 2001 at 05:34:31PM -0500, Mark Jones wrote: > I have been giving the implementation of the DRI some further thought and > have a few comments and questions. > > I think the communication of a device reboot event should be decoupled from > the identity/capability exchange since the establishment of the transport > connection does not necessarily imply a reboot of either peer. For example, > a routing proxy may wait until it has a command destined for a particular > Diameter peer before establishing a connection. New event types in the > Device-Status-Indicator command should be used to communicate the device > reboot events instead. If this proposal is accepted, I suggest renaming the > Device-Reboot-Indicator command to Device-Capability-Indicator. > > Command names aside, I understand that the capabilities of a Diameter peer > are unlikely to be fully described by the list of extension ids that it > supports. The receiver of the DRI also needs to be aware of the > vendor-specific AVPs and commands supported by the peer and I agree that we > should not attempt to communicate this in the DRI. It follows that this > capability set must already be known by the receiver in order for any > vendor-specific AVPs/commands to be exchanged. In other words, the receiver > must know that firmware revision [x] running on product [y] from device > vendor [z] supports a given set of extensions and/or vendor-specific > AVPs/commands. Hence, the DRI should contain these device identity AVPs in a > machine-friendly format in order for the peer to lookup the device's > capability set. I think this requirement would be better served by three > separate AVPs (Firmware-Revision/Product-Id/Vendor-Id) than the free-format > Vendor-Product-Name AVP that was proposed for debugging purposes. > > Does the inclusion of an extension id in the DRI imply that the device > supports the functionality described in the extension using only the > commands and attributes defined in the extension, i.e. without addition of > any mandatory vendor-specific commands/attributes? Would it be valid for a > device claiming support for the Mobile-IP extension to discard an AMA > command because it was missing a vendor-specific AVP that the device's > vendor considered mandatory? > > Regards, > Mark > > From owner-aaa-bof@merit.edu Wed Mar 21 17:05:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17511 for ; Wed, 21 Mar 2001 17:05:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id D47B85DE17; Wed, 21 Mar 2001 16:53:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6CC755DFD5; Wed, 21 Mar 2001 16:52:22 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 003055DFE4 for ; Wed, 21 Mar 2001 16:51:22 -0500 (EST) Received: (qmail 19719 invoked by uid 500); 21 Mar 2001 22:22:43 -0000 Date: Wed, 21 Mar 2001 10:46:42 -0600 From: David Frascone To: Mark Jones Subject: Re: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Message-ID: <20010321104642.E19524@newman.frascone.com> References: <20010320172056.B20497@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mjones@bridgewatersystems.com on Tue, Mar 20, 2001 at 08:33:06PM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk On Tue, Mar 20, 2001 at 08:33:06PM -0500, Mark Jones wrote: > > Whatcha think of that? > > > > I agree that works great for extensions produced by WGs but I'm concerned > about the vendor-specific AVPs and commands. If a vendor comes up with a > slight variant on mobile IP registration which includes a few additional > vendor-specific AVPs, I just can not see them publishing a new extension > document for it. From my RADIUS experience, they will simply add the AVPs to > the dictionary for their Diameter server (and maybe to their device > documentation if we're lucky). Some vendor's even treat their RADIUS VSAs as > proprietary information available solely under NDA! My proposal comes out of > a reluctant acceptance that the same thing will happen with Diameter and at > least the base protocol could provide a means of discovering the identity of > the device. Well, vendor specific AVPs are ignored by applications/servers that do not know how to handle them. (Unless, of course, the M bit is set. Then, an error (MRI) would be returned). So, Vendor attributes are currently supported exactly like in RADIUS. In fact, you can send any extra AVPs you want, and if they are not supported/expected, they will just be ignored. But, a server can *also* advertise that it knows how to handle specific vendor AVPs, or optional AVPs by documentint those AVPs in an extension, and then advertising that the extension is supported. So, I still think that my preposal handles both cases. > > I'm lukewarm on the idea of adding a list of the supported vendor ids to the > DRI. On one hand, it does allow the Diameter server to check whether it has > a dictionary for that vendor. On the other, the server still has no idea if > it has the latest dictionary for that vendor so it still risks receiving > unknown VSA. What is your opinion? > Adding a list of vendor ids or supported AVPs to a DRI is very ugly, in my opinion. That's why I'm pushing registering extensions so that several commands/avps/whatever can be supported with only one addition to the DRI. -Dave From owner-aaa-bof@merit.edu Thu Mar 22 15:37:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20791 for ; Thu, 22 Mar 2001 15:37:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id A19655DE2A; Thu, 22 Mar 2001 15:34:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E5225DDA7; Thu, 22 Mar 2001 15:34:47 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 939B85DD96 for ; Thu, 22 Mar 2001 15:34:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA22904 for ; Thu, 22 Mar 2001 12:34:42 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04811 for ; Thu, 22 Mar 2001 12:34:30 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA14216 for ; Thu, 22 Mar 2001 12:34:26 -0800 (PST) From: James Kempf Message-Id: <200103222034.MAA14216@heliopolis.Eng.Sun.COM> Date: Thu, 22 Mar 2001 14:34:46 -0700 To: Reply-To: Subject: [AAA-WG]: Synchronous C Diameter API? X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Now that the Diameter API is a working group item, the authors have a question we would like to pose to the list. The C API is currently asynchronous. Someone has pointed out that it is difficult to debug an asynchronous API, and unnecessary for a simple client that uses RPC semantics. The suggestion has been made that we add a synchronous, client-side style C API, similar to the Java client API. The asynchronous API would remain, with perhaps a few modifications to remove any duplicated functionality. The only downside that we can see is that on an operating system with a single thread, a synchronous API would not be usable since it would block the process. As a note, the Java API will be updated shortly to the latest Diameter spec, and it will also include a server side API. Comments? jak From owner-aaa-bof@merit.edu Thu Mar 22 17:35:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23847 for ; Thu, 22 Mar 2001 17:35:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id DA1EA5DDC3; Thu, 22 Mar 2001 17:33:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C82475DDBF; Thu, 22 Mar 2001 17:33:14 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 969C55DDB0 for ; Thu, 22 Mar 2001 17:33:12 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2MMWpg19794 for ; Thu, 22 Mar 2001 16:33:11 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 22 Mar 2001 16:32:47 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Thu, 22 Mar 2001 16:32:47 -0600 Message-ID: From: Yogesh.Solanki@nokia.com To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Base Protocol Date: Thu, 22 Mar 2001 16:32:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, I was going through Diameter drafts and I came across some inconsistencies in their description. -- AAASetMessageResultCode : In description, functionality mentioned is totally inconsistency with its name and what it supposed to do. According to my understanding it will set resultcode in message. But I am not sure whether it will create Result - Code AVP or not. -- AAAConvertAVPToString : I am not clear whether this function will convert only data part of AVP into printable format or whole AVP ( means code, length, data etc ). -- AAAJoinAVPLists : This function takes two avp's and join their *lists*. So, if we join two avplists in the middle, is it necessary to re-assign head and tail newly generated list ? What will happen to that remaining list that is handing and not a part of newly generated list ? My feeling is, it is better to pass that two lists that are going to be joined. So, we can either free their memory or reassign their head and tail and make them proper lists. -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString it is mentioned that "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 (13 if the 'V' bit is enabled). " My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum length should be 8 as data length can be 0 or more octect. regards, Yogesh Solanki From owner-aaa-bof@merit.edu Sat Mar 24 13:29:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07368 for ; Sat, 24 Mar 2001 13:29:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id A249E5DDF1; Sat, 24 Mar 2001 13:28:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8FD3E5DE05; Sat, 24 Mar 2001 13:28:41 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 2C8265DDF1 for ; Sat, 24 Mar 2001 13:28:39 -0500 (EST) Received: (qmail 10296 invoked by uid 500); 24 Mar 2001 19:00:13 -0000 Date: Sat, 24 Mar 2001 13:00:13 -0600 From: David Frascone To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: AAA API (was [AAA-WG]: Base Protocol) Message-ID: <20010324130013.F2294@newman.frascone.com> Mail-Followup-To: Yogesh.Solanki@nokia.com, aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yogesh.Solanki@nokia.com on Thu, Mar 22, 2001 at 04:32:46PM -0600 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Hmmm, you titled the subject "Base Protocol", but this seems like an API question, so I'm going to re-title the subject. On Thu, Mar 22, 2001 at 04:32:46PM -0600, Yogesh.Solanki@nokia.com wrote: > Hi, > > -- AAASetMessageResultCode : In description, functionality mentioned is > totally inconsistency with its name and what it supposed to do. According to > my understanding it will set resultcode in message. But I am not sure > whether it will create Result - Code AVP or not. The result code AVP will be created if the Result Code in the AAAMessage is set. So, this function will set the result code, which will cause the AVP to be added when the message is sent. I'll make a note to my self to clarify the document. > > -- AAAConvertAVPToString : I am not clear whether this function will convert > only data part of AVP into printable format or whole AVP ( means code, > length, data etc ). This routine will convert the DATA portion of an AVP to a string format. The type of conversion depends on what we know about the AVP. So, if the implementation knows that the data item is a string, it will just be returned. If it is an octet-string, then a hexdump will be returned. If an integer, ltoa() or an equilivant will be used to convert the number to a string. So, this function is usefull for displaying the data portion of an AVP for accounting purposes, or debugging. > > -- AAAJoinAVPLists : This function takes two avp's and join their *lists*. > So, if we join two avplists in the middle, is it necessary to re-assign head > and tail newly generated list ? What will happen to that remaining list > that is handing and not a part of newly generated list ? My feeling is, it > is better to pass that two lists that are going to be joined. So, we can > either free their memory or reassign their head and tail and make them > proper lists. Agreed. It should take two lists. This might be slightly broken, and it is definatly confusing. > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > it is mentioned that > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > (13 if the 'V' bit is enabled). " > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > length should be 8 as data length can be 0 or more octect. Why would you ever send a zero length octet string? -Dave From owner-aaa-bof@merit.edu Sat Mar 24 17:35:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12397 for ; Sat, 24 Mar 2001 17:35:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 14BFF5DDBD; Sat, 24 Mar 2001 17:31:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 015CD5DDB6; Sat, 24 Mar 2001 17:31:25 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 579785DD8C for ; Sat, 24 Mar 2001 17:31:23 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2OMM5N21277; Sat, 24 Mar 2001 14:22:05 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Cc: "Dmitton@Nortelnetworks. Com" Subject: [AAA-WG]: IETF 50 proceedings Date: Sat, 24 Mar 2001 14:32:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If you took minutes at the AAA WG meetings, or gave a presentation, please send the relevant documents to myself and Dave. Thanks! From owner-aaa-bof@merit.edu Sat Mar 24 17:46:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12620 for ; Sat, 24 Mar 2001 17:46:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EF7E5DE5C; Sat, 24 Mar 2001 17:43:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3A4EC5DE5B; Sat, 24 Mar 2001 17:43:37 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 1D9B85DE56 for ; Sat, 24 Mar 2001 17:43:23 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2OMY5N21902 for ; Sat, 24 Mar 2001 14:34:06 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA WG Interim meeting dates Date: Sat, 24 Mar 2001 14:44:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit As mentioned at IETF 50, the AAA WG will be scheduling a two-day interim meeting in order to make further progress on completing the DIAMETER specification. In order to meet the 30 day notice requirements, the earliest dates would be Monday, April 30 and Tuesday, May 1, 2001. Suggested meeting location is the SF Bay Area. An alternative set of suggested dates is May 21-22, 2001. Any opinions on the best time for the meeting? From owner-aaa-bof@merit.edu Sun Mar 25 21:08:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06650 for ; Sun, 25 Mar 2001 21:08:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 330CA5DDB7; Sun, 25 Mar 2001 21:07:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0F1285DD90; Sun, 25 Mar 2001 21:07:45 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 252605DDFB for ; Sun, 25 Mar 2001 21:07:41 -0500 (EST) Received: from gwzpc (sjc-vpn-410.cisco.com [10.21.65.154]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id SAA28774; Sun, 25 Mar 2001 18:04:58 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Sun, 25 Mar 2001 18:04:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > As mentioned at IETF 50, the AAA WG will be scheduling a > two-day interim meeting in order to make further progress > on completing the DIAMETER specification. > > In order to meet the 30 day notice requirements, the earliest > dates would be Monday, April 30 and Tuesday, May 1, 2001. > Suggested meeting location is the SF Bay Area. > > An alternative set of suggested dates is May 21-22, 2001. I would _much_ prefer May 21-22. > > Any opinions on the best time for the meeting? > > > From owner-aaa-bof@merit.edu Mon Mar 26 07:27:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05296 for ; Mon, 26 Mar 2001 07:27:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 653775DDC7; Mon, 26 Mar 2001 07:27:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D4C65DE1B; Mon, 26 Mar 2001 07:27:37 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id A52295DDC7 for ; Mon, 26 Mar 2001 07:27:34 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.0) with ESMTP id OAA22494; Mon, 26 Mar 2001 14:27:33 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id OAA17112; Mon, 26 Mar 2001 14:27:32 +0200 Date: Mon, 26 Mar 2001 14:27:32 +0200 Message-Id: <200103261227.OAA17112@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: aboba@internaut.com, dmitton@nortelnetworks.com Cc: aaa-wg@merit.edu In-reply-to: Subject: Re: [AAA-WG]: IETF 50 proceedings References: Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Bernard Aboba writes: Bernard> If you took minutes at the AAA WG meetings, or gave a Bernard> presentation, please send the relevant documents to myself Bernard> and Dave. My slides are available from the following locations: http://www.ibr.cs.tu-bs.de/~schoenw/sming-diameter.ppt http://www.ibr.cs.tu-bs.de/~schoenw/slides/ietf-50-sming-diameter.ps.gz /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Mon Mar 26 09:54:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29988 for ; Mon, 26 Mar 2001 09:54:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 64B765DDA2; Mon, 26 Mar 2001 09:54:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D0C35DE1B; Mon, 26 Mar 2001 09:54:15 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B72FE5DDA2 for ; Mon, 26 Mar 2001 09:54:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28656; Mon, 26 Mar 2001 06:54:04 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21472; Mon, 26 Mar 2001 06:54:03 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA23871; Mon, 26 Mar 2001 06:54:01 -0800 (PST) Date: Mon, 26 Mar 2001 06:54:00 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: AAA WG Interim meeting dates To: gwz@cisco.com Cc: Bernard Aboba , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > As mentioned at IETF 50, the AAA WG will be scheduling a > > two-day interim meeting in order to make further progress > > on completing the DIAMETER specification. > > > > In order to meet the 30 day notice requirements, the earliest > > dates would be Monday, April 30 and Tuesday, May 1, 2001. > > Suggested meeting location is the SF Bay Area. > > > > An alternative set of suggested dates is May 21-22, 2001. > > I would _much_ prefer May 21-22. As much as I'd like to accomodate Glen, my preference would be for the April date, since we need these specs in WG last call ASAP. Three weeks is a LONG time. PatC From owner-aaa-bof@merit.edu Mon Mar 26 10:25:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08469 for ; Mon, 26 Mar 2001 10:25:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 70AED5DD92; Mon, 26 Mar 2001 10:24:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5AE9C5DE61; Mon, 26 Mar 2001 10:24:41 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 7BA465DD92 for ; Mon, 26 Mar 2001 10:24:39 -0500 (EST) Received: from gwzpc (sjc-vpn-532.cisco.com [10.21.66.20]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA00379; Mon, 26 Mar 2001 07:22:41 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" Cc: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Mon, 26 Mar 2001 07:21:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > > As mentioned at IETF 50, the AAA WG will be scheduling a > > > two-day interim meeting in order to make further progress > > > on completing the DIAMETER specification. > > > > > > In order to meet the 30 day notice requirements, the earliest > > > dates would be Monday, April 30 and Tuesday, May 1, 2001. > > > Suggested meeting location is the SF Bay Area. > > > > > > An alternative set of suggested dates is May 21-22, 2001. > > > > I would _much_ prefer May 21-22. > > As much as I'd like to accomodate Glen, my preference would be > for the April > date, since we need these specs in WG last call ASAP. Three weeks > is a LONG > time. Indeed. In fact, it might just be long enough to complete the work the way it's supposed to be done: on the list. > > PatC > > From owner-aaa-bof@merit.edu Mon Mar 26 10:29:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09500 for ; Mon, 26 Mar 2001 10:29:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 401FC5DE20; Mon, 26 Mar 2001 10:28:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C2455DE61; Mon, 26 Mar 2001 10:28:51 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1C5735DE20 for ; Mon, 26 Mar 2001 10:28:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23679; Mon, 26 Mar 2001 07:28:36 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00573; Mon, 26 Mar 2001 07:28:35 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA24114; Mon, 26 Mar 2001 07:28:33 -0800 (PST) Date: Mon, 26 Mar 2001 07:28:32 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: AAA WG Interim meeting dates To: gwz@cisco.com Cc: Patrice Calhoun , Bernard Aboba , "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > > > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > > > > As mentioned at IETF 50, the AAA WG will be scheduling a > > > > two-day interim meeting in order to make further progress > > > > on completing the DIAMETER specification. > > > > > > > > In order to meet the 30 day notice requirements, the earliest > > > > dates would be Monday, April 30 and Tuesday, May 1, 2001. > > > > Suggested meeting location is the SF Bay Area. > > > > > > > > An alternative set of suggested dates is May 21-22, 2001. > > > > > > I would _much_ prefer May 21-22. > > > > As much as I'd like to accomodate Glen, my preference would be > > for the April > > date, since we need these specs in WG last call ASAP. Three weeks > > is a LONG > > time. > > Indeed. In fact, it might just be long enough to complete the work the way > it's supposed to be done: on the list. Just to be clear, both weeks do work for me. My preference was simply because I was concerned that we could possibly miss 3GPP2 deadlines by pushing it out too far. However, now that I think of it, if the document is sent out the week after the interim meeting, and automatically enters WG last call, we can probably be done with the specs by the end of June. So the later date *could* work, if the WG is willing to be a little more aggresive, and I am willing to do my share... As for working on the list, I agree that's the preferred way, but we all know how much work really gets done face to face :( PatC From owner-aaa-bof@merit.edu Mon Mar 26 12:38:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12879 for ; Mon, 26 Mar 2001 12:38:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 93A5E5DE52; Mon, 26 Mar 2001 12:37:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8149B5DE35; Mon, 26 Mar 2001 12:37:51 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id EB7E85DD99 for ; Mon, 26 Mar 2001 12:37:49 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14haur-000F9f-00; Mon, 26 Mar 2001 09:36:29 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: "Patrice Calhoun" , "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates References: Message-Id: Date: Mon, 26 Mar 2001 09:36:29 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Indeed. In fact, it might just be long enough to complete the work the way > it's supposed to be done: on the list. to clarify/quibble: your wording might be misinterpreted to imply that interim meetings are not part of the "supposed to be done" ietf process, when in fact they are. randy, wearing AD hat From owner-aaa-bof@merit.edu Mon Mar 26 14:05:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14334 for ; Mon, 26 Mar 2001 14:05:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 332915DDD0; Mon, 26 Mar 2001 14:05:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 228E05DDBC; Mon, 26 Mar 2001 14:05:19 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id EBEAB5DD9E for ; Mon, 26 Mar 2001 14:05:16 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA27828 for ; Mon, 26 Mar 2001 11:05:16 -0800 (PST) Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AAS02087; Mon, 26 Mar 2001 11:05:11 -0800 (PST) From: "John Alayari" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: base protocol per hop error handling Date: Mon, 26 Mar 2001 11:04:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On the per-hop Error signaling in section 9.0, the Device Status Ind(DSI) message is used for reporting an error downstream next hop. I have 2 questions: Question 1) Could error reporting be handled within response to a message such as accounting-answer? Why are we using a new -IND message (DSI) message? and those message are supposed to unsolicited. Question 2)By looking at DSI-Event AVP (section 9.1.1) and Result-code AVP (section 10.2), I see lots of similarities between the two AVPs. The DSI-event AVP can easily and with minimum effort can be included into Result-code AVP. Is there any reason why we did not do this? One advantage would be less code size. John Alayari. From owner-aaa-bof@merit.edu Mon Mar 26 14:10:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14470 for ; Mon, 26 Mar 2001 14:10:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 36E975DDD6; Mon, 26 Mar 2001 14:10:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 25FA15DDBC; Mon, 26 Mar 2001 14:10:13 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 62C0E5DD9E for ; Mon, 26 Mar 2001 14:10:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25369; Mon, 26 Mar 2001 11:10:07 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24905; Mon, 26 Mar 2001 11:10:05 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA28157; Mon, 26 Mar 2001 11:10:03 -0800 (PST) Date: Mon, 26 Mar 2001 11:10:02 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: base protocol per hop error handling To: John Alayari Cc: "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Question 1) Could error reporting be handled within response to a message > such as accounting-answer? Why are we using a new -IND message (DSI) > message? and those message are supposed to unsolicited. Let's assume that a proxy is out there that doesn't know about extension 'X', but it needs to report an error. How would the proxy know to convert X-request to X-answer (specifically what the command code should be). So a generic return code needs to be supported. > > Question 2)By looking at DSI-Event AVP (section 9.1.1) and Result-code AVP > (section 10.2), I see lots of similarities between the two AVPs. The > DSI-event AVP can easily and with minimum effort can be included into > Result-code AVP. Is there any reason why we did not do this? One advantage > would be less code size. Although there seems to be some overlap, there are significant differences in how the events/errors are handled. It doesn't seem that significant to have two separate switch statements, which they probably would be given the type of error anyways (one is in the proxying code, and the other at the "extension" level). PatC > > John Alayari. > > From owner-aaa-bof@merit.edu Mon Mar 26 17:19:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19020 for ; Mon, 26 Mar 2001 17:19:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id BF6175DE17; Mon, 26 Mar 2001 17:15:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C8285DE7A; Mon, 26 Mar 2001 17:14:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CE3E25DE69 for ; Mon, 26 Mar 2001 17:14:15 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28579; Mon, 26 Mar 2001 14:14:13 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05961; Mon, 26 Mar 2001 14:14:12 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA01934; Mon, 26 Mar 2001 14:14:08 -0800 (PST) Date: Mon, 26 Mar 2001 14:14:08 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: [diameter] Base Protocol To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk [API questions answered by Dave, and deleted] > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > it is mentioned that > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > (13 if the 'V' bit is enabled). " > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > length should be 8 as data length can be 0 or more octect. Length of an OctetString is one (!0) or more octets. PatC From owner-aaa-bof@merit.edu Mon Mar 26 17:23:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19374 for ; Mon, 26 Mar 2001 17:23:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id BA25D5DEF6; Mon, 26 Mar 2001 17:20:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A1BB15DEF7; Mon, 26 Mar 2001 17:20:05 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 243BA5DEF6 for ; Mon, 26 Mar 2001 17:20:03 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03185; Mon, 26 Mar 2001 14:20:00 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07127; Mon, 26 Mar 2001 14:19:59 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA02016; Mon, 26 Mar 2001 14:19:57 -0800 (PST) Date: Mon, 26 Mar 2001 14:19:56 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: username len To: Justin Britten Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I can't find any reference to a maximum username length in the Diameter > drafts. Since User-Name AVP is of type OctetString, and the draft > states that the maximum avp length is 65527, does this mean the > username can be up to 65519 bytes? (8 bytes go to avp header) Correct, Diameter doesn't impose a maximum length on *any* AVPs of type OctetString. I would note, however, that RFC 2486 does state that all implementations MUST support a minimum length of 72 bytes, but doesn't set a maximum size. > > Also, how was the maximum length value of 65527 determined? If the > minimum diameter packet header is 16 bytes doesn't this mean the maximum > avp length is 65535 - 16 = 65519 (techically 65516 when set on an even > word boundary)? Now, the max username is 65508. You are correct, the spec had a bug, and it will be corrected in -02. Thanks for the feedback. PatC From owner-aaa-bof@merit.edu Mon Mar 26 17:40:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19612 for ; Mon, 26 Mar 2001 17:40:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id F02F85DEA6; Mon, 26 Mar 2001 17:39:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D82FD5DE91; Mon, 26 Mar 2001 17:39:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 08D5B5DEA5 for ; Mon, 26 Mar 2001 17:39:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07496; Mon, 26 Mar 2001 14:39:36 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11472; Mon, 26 Mar 2001 14:39:36 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA02306; Mon, 26 Mar 2001 14:39:34 -0800 (PST) Date: Mon, 26 Mar 2001 14:39:33 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [Fwd: Re: [AAA-WG]: AAA WG last call on draft-ietf-aaa-isssues-04.txt] To: JRV@Interlinknetworks.com Cc: AAA Working Group In-Reply-To: "Your message with ID" <3AB7BFB9.65FC17E@merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > 1. Hop by hop security and audit. > > It seems desirable to be able to demonstrate that a valid security > association existed between servers at the time a transaction occurs. > This might be accomplished by including a MAC (as proposed for ete > security) on each message. For those willing to support the > overhead of a MAC this would be sufficient. > > Alternatively, the AAA servers might know about hop by hop security > associations and include an indication of this in useage logs for > accounting purposes. In RADIUS this indication is in the message > authenticator. If DIAMETER uses IPSEC or SSL for hop by hop > security a mechanism for providing auditing of the security > association needs to be described. As far as TLS is concerned, I think this is a no brainer because there is an API used to access the protocol. As for IPSec, I am not sure that there is a standardized way to access the underlying policy database. Either way, it isn't clear to me how (or why) the protocol specification needs to expand on this. > 2. Managing multiple resources > > DIAMETER currently assumes that a Session ID will be created by the > requestor (NAS) and used by all subsequent proxies. This approach > seems to mean that adding a resource to a session, for example adding > an additional ISDN channel to a multilink call, requires a separate > session to be created and then linked somehow to the initial session. > > Some method of handling multiple resource sessions associated with a > single useage session should be described. If this is true, then there is something broken in the protocol spec. Could you tell me what led you to believe that adding resources required a new session identifier? PatC From owner-aaa-bof@merit.edu Mon Mar 26 22:42:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28095 for ; Mon, 26 Mar 2001 22:42:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 545665DEA0; Mon, 26 Mar 2001 22:42:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3E5C15DE9E; Mon, 26 Mar 2001 22:42:04 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 6DDB25DE95 for ; Mon, 26 Mar 2001 22:42:02 -0500 (EST) Received: from gwzpc (sjc-vpn-229.cisco.com [10.21.64.229]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA16869; Mon, 26 Mar 2001 19:40:11 -0800 (PST) Reply-To: From: "Glen Zorn" To: , "Patrice Calhoun" Cc: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Mon, 26 Mar 2001 19:37:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn [mailto:gwz@cisco.com] writes: > Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > > > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > > > > As mentioned at IETF 50, the AAA WG will be scheduling a > > > > two-day interim meeting in order to make further progress > > > > on completing the DIAMETER specification. > > > > > > > > In order to meet the 30 day notice requirements, the earliest > > > > dates would be Monday, April 30 and Tuesday, May 1, 2001. > > > > Suggested meeting location is the SF Bay Area. > > > > > > > > An alternative set of suggested dates is May 21-22, 2001. > > > > > > I would _much_ prefer May 21-22. > > > > As much as I'd like to accomodate Glen, my preference would be > > for the April > > date, since we need these specs in WG last call ASAP. Three weeks > > is a LONG > > time. > > Indeed. In fact, it might just be long enough to complete the > work the way it's supposed to be done: on the list. I have another meeting in Illinois on the 30th; if we can move the AAA interim (_if_ it is _necessary_ at all) to May 1-2, I'm OK with it. > > > > > PatC > > > > From owner-aaa-bof@merit.edu Mon Mar 26 22:53:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA28204 for ; Mon, 26 Mar 2001 22:53:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6DCF35DE83; Mon, 26 Mar 2001 22:48:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5A7D55DE82; Mon, 26 Mar 2001 22:48:43 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 9F2C15DDBE for ; Mon, 26 Mar 2001 22:48:41 -0500 (EST) Received: from gwzpc (sjc-vpn-229.cisco.com [10.21.64.229]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA22440; Mon, 26 Mar 2001 19:46:21 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Randy Bush" Cc: "Patrice Calhoun" , "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Mon, 26 Mar 2001 19:43:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > > Indeed. In fact, it might just be long enough to complete the > work the way > > it's supposed to be done: on the list. > > to clarify/quibble: your wording might be misinterpreted to imply that > interim meetings are not part of the "supposed to be done" ietf process, > when in fact they are. Sorry, I actually thought that interim meetings were something of a last resort, to be held only if all other methods failed to produce consensus. I only wish that I had known this when I was co-chairing roamops: we would have had interim meetings all the time. I'm thinking Cancun in February, Amsterdam in July, Nice, Munich in late September... ;-) > > randy, wearing AD hat gwz, wearing tourist hat > > From owner-aaa-bof@merit.edu Tue Mar 27 00:00:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29495 for ; Tue, 27 Mar 2001 00:00:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 80B4D5DDEB; Mon, 26 Mar 2001 23:35:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6061C5DE88; Mon, 26 Mar 2001 23:35:14 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id E05155DDEB for ; Mon, 26 Mar 2001 23:35:12 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14hlAv-000AVk-00; Mon, 26 Mar 2001 20:33:45 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: "Patrice Calhoun" , "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates References: Message-Id: Date: Mon, 26 Mar 2001 20:33:45 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> to clarify/quibble: your wording might be misinterpreted to imply that >> interim meetings are not part of the "supposed to be done" ietf process, >> when in fact they are. > Sorry, I actually thought that interim meetings were something of a last > resort, to be held only if all other methods failed to produce consensus. nah. for that, we lock everyone in a room in minneapolis and only let them eat pizza until they agree. :-) sometimes, a wg needs to get a LOT of serious work done, and email just isn't doing it. this is the gap interims fill. randy From owner-aaa-bof@merit.edu Tue Mar 27 02:44:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA14878 for ; Tue, 27 Mar 2001 02:44:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id D0C8D5DE9B; Tue, 27 Mar 2001 02:44:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BEDC85DE97; Tue, 27 Mar 2001 02:44:08 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 919835DE82 for ; Tue, 27 Mar 2001 02:44:06 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2R7YWN04978; Mon, 26 Mar 2001 23:34:32 -0800 From: "Bernard Aboba" To: , "Randy Bush" Cc: "Patrice Calhoun" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Mon, 26 Mar 2001 23:45:00 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Sorry, I actually thought that interim meetings were something of a last >resort, to be held only if all other methods failed to produce consensus. I ...or when deadlines loom and concentrated effort is needed to meet WG milestones. In AAA WG, we've been extraordinarily productive in interim meetings; I shudder to think where we'd be without them. At this point, while I think that we've hashed out the meta issues with DIAMETER, there are a lot of smaller issues that we need to get out of the way. Focusing on these for two days could get us much closer to being done. Given that we're serious about getting to WG last call by June, we need that kind of intense effort. In terms of the interim meeting plan, the thinking is to have a two-day specification bug bash. Interim meeting participants will be expected to have read the DIAMETER specification over with a fine tooth comb, and be ready to discuss issues along with concrete recommendations for changes. We'll also take on a few larger issues with the goal of making decisions. >only wish that I had known this when I was co-chairing roamops: we would >have had interim meetings all the time. I'm thinking Cancun in February, >Amsterdam in July, Nice, Munich in late September... ;-) Remember, they call them Working Groups because they're supposed to do work ;) From owner-aaa-bof@merit.edu Tue Mar 27 07:25:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17236 for ; Tue, 27 Mar 2001 07:25:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id B11FE5DE9E; Tue, 27 Mar 2001 07:25:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 940125DDB3; Tue, 27 Mar 2001 07:25:02 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 62B345DD95 for ; Tue, 27 Mar 2001 07:25:00 -0500 (EST) Received: from bkopacz98 (nic-131-c68-216.mw.mediaone.net [24.131.68.216]) by aaa.interlinknetworks.com (Postfix) with SMTP id 3B45C73; Tue, 27 Mar 2001 07:25:16 -0500 (EST) Message-ID: <008e01c0b6b8$e6c0b300$d8448318@mw.mediaone.net> From: "Bob Kopacz" To: "Patrice Calhoun" Cc: "aaa-wg" References: Subject: Re: [AAA-WG]: Re: [diameter] Base Protocol Date: Tue, 27 Mar 2001 07:24:42 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I think it was good, though, that you added the "unless otherwise noted" phrase, as this allows cases where the presence of a string-type attribute with a null string can convey a different meaning than the absence of the AVP. I'm thinkin here of EAP. In RADIUS's EAP-Message attribute and in Diameter's EAP-Payload AVP, both of type string, a null string indicates EAP-Start. Bob K. ----- Original Message ----- From: Patrice Calhoun To: Cc: ; Sent: Monday, March 26, 2001 5:14 PM Subject: [AAA-WG]: Re: [diameter] Base Protocol [API questions answered by Dave, and deleted] > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > it is mentioned that > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > (13 if the 'V' bit is enabled). " > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > length should be 8 as data length can be 0 or more octect. Length of an OctetString is one (!0) or more octets. PatC From owner-aaa-bof@merit.edu Tue Mar 27 07:53:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17526 for ; Tue, 27 Mar 2001 07:53:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74FA25DEA9; Tue, 27 Mar 2001 07:51:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5EB1B5DEA8; Tue, 27 Mar 2001 07:51:42 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 6E2FC5DDB3 for ; Tue, 27 Mar 2001 07:51:40 -0500 (EST) Received: from gwzpc (sjc-vpn-154.cisco.com [10.21.64.154]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id EAA17069; Tue, 27 Mar 2001 04:49:26 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Randy Bush" Cc: "Patrice Calhoun" , "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Tue, 27 Mar 2001 04:49:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rady Bush [mailto:randy@psg.com] writes: > >> to clarify/quibble: your wording might be misinterpreted to imply that > >> interim meetings are not part of the "supposed to be done" > ietf process, > >> when in fact they are. > > Sorry, I actually thought that interim meetings were something of a last > > resort, to be held only if all other methods failed to produce > consensus. > > nah. for that, we lock everyone in a room in minneapolis and > only let them > eat pizza until they agree. :-) That would definitely work! > > sometimes, a wg needs to get a LOT of serious work done, and email just > isn't doing it. this is the gap interims fill. I agree, but Bernard's description of the interim sounds basically like a document reading party. I have nothing against document reading parties, and they can be quite useful (witness L2TP), but realistically, they're nothing that can't be accomplished on a mailing list (in fact, much of IETF activity could be described as an on-line document reading party. > > randy > > From owner-aaa-bof@merit.edu Tue Mar 27 07:56:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17565 for ; Tue, 27 Mar 2001 07:56:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7CEF45DDDB; Tue, 27 Mar 2001 07:56:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C6E65DDD3; Tue, 27 Mar 2001 07:56:24 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 51E1C5DDB3 for ; Tue, 27 Mar 2001 07:56:22 -0500 (EST) Received: from gwzpc (sjc-vpn-154.cisco.com [10.21.64.154]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id EAA20540; Tue, 27 Mar 2001 04:54:00 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Randy Bush" Cc: "Patrice Calhoun" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: AAA WG Interim meeting dates Date: Tue, 27 Mar 2001 04:53:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: ... > In terms of the interim meeting plan, the thinking is to have a > two-day specification bug bash. Interim meeting participants will > be expected to have read the DIAMETER specification over with > a fine tooth comb, and be ready to discuss issues along with > concrete recommendations for changes. But isn't that precisely where the IETF "method" shines -- I'd hate to think that nobody on this list had read the drafts... > We'll also take on a few > larger issues with the goal of making decisions. But, by definition, we don't _make_ decisions in meetings (interin or other), right? > > >only wish that I had known this when I was co-chairing roamops: we would > >have had interim meetings all the time. I'm thinking Cancun in February, > >Amsterdam in July, Nice, Munich in late September... ;-) > > Remember, they call them Working Groups because they're supposed to do > work ;) define "work" ;-) > > > > From owner-aaa-bof@merit.edu Tue Mar 27 10:04:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19226 for ; Tue, 27 Mar 2001 10:04:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1F5175DEE3; Tue, 27 Mar 2001 10:00:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CE315DEE1; Tue, 27 Mar 2001 10:00:50 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 409035DE3B for ; Tue, 27 Mar 2001 10:00:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00571; Tue, 27 Mar 2001 07:00:45 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23175; Tue, 27 Mar 2001 07:00:45 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA11318; Tue, 27 Mar 2001 07:00:42 -0800 (PST) Date: Tue, 27 Mar 2001 07:00:41 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Re: [diameter] Base Protocol To: Bob Kopacz Cc: Patrice Calhoun , aaa-wg In-Reply-To: "Your message with ID" <008e01c0b6b8$e6c0b300$d8448318@mw.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk hmmmm.... looks like I can't even read my own text :( You are correct that the spec does allow a zero octetstring AVP, as Bob points out below. The way the text is written, it is a special case, where it states that a specific AVP MAY have a zero length, but this needs to be speficied in the AVP definition, otherwise the minimum lenghs apply. So does the text need to change? PatC > Hi Pat, > > I think it was good, though, that you added the > "unless otherwise noted" phrase, as this allows cases > where the presence of a string-type attribute with > a null string can convey a different meaning than > the absence of the AVP. > > I'm thinkin here of EAP. In RADIUS's EAP-Message > attribute and in Diameter's EAP-Payload AVP, both > of type string, a null string indicates EAP-Start. > > Bob K. > > ----- Original Message ----- > From: Patrice Calhoun > To: > Cc: ; > Sent: Monday, March 26, 2001 5:14 PM > Subject: [AAA-WG]: Re: [diameter] Base Protocol > > > [API questions answered by Dave, and deleted] > > > > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > > it is mentioned that > > > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > > (13 if the 'V' bit is enabled). " > > > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > > length should be 8 as data length can be 0 or more octect. > > Length of an OctetString is one (!0) or more octets. > > PatC > > > > From owner-aaa-bof@merit.edu Tue Mar 27 10:21:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19728 for ; Tue, 27 Mar 2001 10:21:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id BEB245DEDB; Tue, 27 Mar 2001 10:20:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AD7BA5DED3; Tue, 27 Mar 2001 10:20:48 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 3295D5DECC for ; Tue, 27 Mar 2001 10:20:46 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA13967 for ; Tue, 27 Mar 2001 11:17:06 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA02653 for ; Tue, 27 Mar 2001 10:21:26 -0500 (EST) From: "Mark Jones" To: "IETF AAA WG" Subject: [AAA-WG]: Vendor-Name in DRI Date: Tue, 27 Mar 2001 10:22:19 -0500 Message-ID: <000d01c0b6d1$b67b2e00$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I understand that the new DRI format is: ::= < Diameter Header: 257 > { Origin-FQDN } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Name } * { Extension-Id } [ Firmware-Revision ] * { Supported-Vendor-Id } * [ AVP ] 0*1< Integrity-Check-Value > I am repeating my request to keep the device Vendor-Id in this message instead of the Vendor-Name AVP. If the DRI is meant to eliminate a configuration file mapping peer IP Address to Vendor then a well-known integer is more machine-friendly than the free-format Vendor-Name string which SHOULD contain the vendor name and/or product name. I understand this change was made following objections from Diameter implementors at Connectathon to having to obtain a Private Enterprise Code from IANA solely for this purpose. This strikes me as a somewhat lame excuse given how easy it is to obtain such a code (goto http://www.iana.org/cgi-bin/enterprise.pl, fill in the form, hit submit, wait one week). Were there other issues with obtaining a Private Enterprise Code for this purpose (inappropriate use...)? I know that the Vendor-Id with Firmware-Revision does not fully identify the device so a Product-Id (or Product-Name) is still required in the DRI. And I have absolutely no objections to vendors issuing this Id/Name rather than IANA :) Regards, Mark From owner-aaa-bof@merit.edu Tue Mar 27 10:52:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20653 for ; Tue, 27 Mar 2001 10:52:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 720F35DF09; Tue, 27 Mar 2001 10:51:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5F38A5DF07; Tue, 27 Mar 2001 10:51:03 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A0A645DF05 for ; Tue, 27 Mar 2001 10:51:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22266; Tue, 27 Mar 2001 07:50:48 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18570; Tue, 27 Mar 2001 07:50:46 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA11886; Tue, 27 Mar 2001 07:50:40 -0800 (PST) Date: Tue, 27 Mar 2001 07:50:37 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Indication for Home Agent allocation?? To: "Martin Julien (ECE)" Cc: "'tony.johansson@ericsson.com'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FF1F@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Sorry for the latency.... just starting to catch up. > 1. What happens if a MN requests an Home Agent in the Foreign Domain, by > setting the address of the Home Agent to 255.255.255.255, and that the AAAF > does not allow an HA to be allocated within its Foreign Domain? What error > should be returned to MN? Should the AMR reach the AAAH at all? Is it at all > possible to reject such a request? Should we use the > DIAMETER_ERROR_NO_FOREIGN_HA_SERVICE result-code? If yes, then I guess we > need to change its description in section 3.1. > > In fact, I'm wondering if that Home Agent set to 255.255.255.255 is only an > indication of a preferred location for the HA?, or it is strongly required > for the HA to be in the Foreign Domain??? If it is not strongly required, > then I'd say that it would be possible to allocate one in the Home Domain, > right? I would say that an AAAF should always recommend an HA to be > allocated within the Foreign Domain for optimization purposes, by setting > the Foreign-Home-Agent-Available flag whenever it supports it, right? In > that case, what is the real need for the indication from the MN? I think that setting the Home Agent to all ones expresses a preference for having the HA in the visited network, but only if possible. If the AAAF decides for some reason that it cannot, or does not want to, allocate additional resources in the visited network, it forwards the AMR to the AAAH without the Foreign-Home-Agent-Available bit set. > > 2. What happens if the MN requests an Home Agent by specifying an address > different then 0.0.0.0 and 255.255.255.255, if that HA is unknown in the > Home Domain and also in the Foreign Domain? There is no result-code for > indicating this to the MN, i.e. that the requested HA is bad, similar as the > error for a bad Home Address, we might need DIAMETER_ERROR_BAD_HOME_AGENT, > right? Unless an HA should be allocated anyway, assuming that it is a > different Home Agent address? ok, well the MN doesn't speak Diameter, so it would have to receive a Registration Reply with the code set to 136 (unknown home agent address). I suppose your comment here is more to the fact that there doesn't exist a Diameter error code to indicate this. > > Also, the spec says, in section 1.2 page 5 of the Diameter MIP extension > -01, that an AMA (now an HAR I guess) must be sent to the AAAF in the case > the Home Agent is not known by the AAAH. The thing is that it is not sure > yet at this point that the AAAF will necessarily know it either. Then I was > wondering if the AAAF should inform that the HA is available by setting the > Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP, when an HA > is specified and it is available locally. Well, that would require less state on the AAAH, which is goodness, and only requires a small modification (specifying when the flag is to be set in the AVP). > That information could be used in > the AAAH to be sure that the HA is available as specified in the Home Agent > AVP in the Foreign Domain, and allocate a new Home Agent in the Home Domain > directly, without asking unnecessarily to the AAAF, if ever it is allowed by > the spec to override the Home Agent address when the one sent from the MN is > not valid. > ok, but now that I think of this, the AAAH needs to maintain state as to where the HA is, because the HA MAY in fact be in a third network, and the AAAF in that network has no opportunity to twiddle the bit in the vector AVP. So, I guess I am saying that the above would only work for one of two cases, and therefore is not that useful. PatC From owner-aaa-bof@merit.edu Tue Mar 27 11:45:32 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22425 for ; Tue, 27 Mar 2001 11:45:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0C8925DEE0; Tue, 27 Mar 2001 11:01:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ED2465DEDE; Tue, 27 Mar 2001 11:01:28 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 2BEBE5DED5 for ; Tue, 27 Mar 2001 11:01:26 -0500 (EST) Received: from fredrikj (c24.local.ipunplugged.com [192.168.4.223]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA07299 for ; Tue, 27 Mar 2001 18:01:09 +0200 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Base Session State Machine Date: Tue, 27 Mar 2001 18:03:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Some questions about the session state machine. 1. I guess that this state applies to Session-Timeout Expires on FA as well. Open Session-Timeout Expires on send STR Discon NAS Suggestion: Open Session-Timeout Expires on send STR Discon access device 2. Is there a possible raise condition if the Session-Timeout in the NAS/FA and the Session-Timeout in the home AAA server expires at the same time? The AAA server will send a STI and go to disconnected when it receives the STR from the NAS/FA it will disconnect and go to closed but it will never send a STA, thus the NAS/FA will never receive a STA and will never go to closed. Or is the STR only sent in response to a STI? /Fredrik From owner-aaa-bof@merit.edu Tue Mar 27 12:16:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23330 for ; Tue, 27 Mar 2001 12:16:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id DD48C5E094; Tue, 27 Mar 2001 12:14:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C6EB45DFC7; Tue, 27 Mar 2001 12:14:30 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 057F05E08B for ; Tue, 27 Mar 2001 12:14:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02759; Tue, 27 Mar 2001 09:14:21 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16141; Tue, 27 Mar 2001 09:14:20 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA13179; Tue, 27 Mar 2001 09:14:14 -0800 (PST) Date: Tue, 27 Mar 2001 09:14:12 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: Connections that pass in the night To: Paul Funk Cc: aaa-wg@merit.edu, diameter@diameter.org, Patrice Calhoun In-Reply-To: "Your message with ID" <4.1.20010320194913.01716720@cairo.funk.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Paul, I believe that the only way to really figure out whether this will work or not is by implementation. Given this is a fairly critical component of the protocol, I would feel uncomfortable putting it in the draft without a successful interop. So, would anyone out there be game to implement this, and we could run a test over the net? I'm willing to do it, and could probably have this done by the end of the day. Any other takers? PatC > It has been decided that a pair of Diameter peers may have at > most one open transport layer connection between them. This > poses some difficulty when both peers attempt to open > connections simultaneously. An election process is required to > allow both peers to come to the same conclusion as to which > connection will survive. > > Implementing such a mechanism can be tricky. Specifying peer > behavior via a state machine is trickier still, since the > different stages that each of the connections may be in leads > to an unwieldy number of states to consider. > > In his Connectathon summary, Pat described an approach as to how > an election might proceed. This proposal attempts to make such > an approach quite explicit. It differs from Pat's approach in > two respects. Origin-FQDN, rather than Identifier, is used for > the election, because Identifier could result in a tie. And, > while Pat's approach requires that the responder wait for the > initiator's DRI before sending its own, this proposal permits > the responder to send DRI immediately in most cases, reducing > startup latency. > > What follows is a state machine proposal that I believe produces > the desired behavior, can be expressed (relatively) clearly, and > can be readily translated to an implementation. > > The basic idea is to define two state machines, one for each > direction. Thus, each Diameter peer implements two state > machines, one as the "initiator" of a connection, and one as the > "responder". There is a minimum of interaction between the two > state machines, and it is guaranteed that the result will be a > single open connection. Also, it is guaranteed that even if one > of the peers behaves incorrectly, a maximum of one open > connection will be established. > > The two stable states that either state machine may be in are > Closed and Open; all other states are intermediate. The overall > connection with the peer is considered open if either the > initiator or responder is in the Open state. > > I apologize for the excruciating detail, but I do think that > this level of specificity is necessary to ensure correct > interoperation. > > > Initiator > --------- > > state event action next state > ------------------------------------------------------------- > Closed Start Snd-Conn-Req Wait-Conn-Ack > OR > Closed > (see note 1) > Wait-Conn-Ack Rcv-Conn-Ack Snd-DRI Wait-DRI > Rcv-Conn-Nack Closed > Cancel Canceling > Timeout Error Closed > Canceling Rcv-Conn-Ack Snd-Disc-Req Closing > Rcv-Conn-Nack Closed > Timeout Error Closed > Wait-DRI Rcv-DRI Open > Rcv-Non-DRI Error Closed > Cancel Snd-Disc-Req Closing > Rcv-Disc-Req Snd-Disc-Ack Closed > Timeout Error Closed > Closing Rcv-Disc-Ack Closed > Rcv-DRI Discard Closing > Rcv-Non-DRI Error Closed > Timeout Error Closed > > > Responder > --------- > > state event action next state > ---------------------------------------------------------- > Closed Rcv-Conn-Req Snd-Conn-Ack Wait-DRI > OR > Snd-Conn-Ack, > Snd-DRI Wait-Open > OR > Snd-Conn-Nack Closed > (see note 2) > Wait-Open Rcv-DRI Open > Rcv-Non-DRI Error Closed > Rcv-Disc-Req Snd-Disc-Ack Closed > Rcv-Conn-Req Snd-Conn-Nack Wait-Open > Timeout Error Closed > Wait-DRI Rcv-DRI Snd-DRI Open > OR > Snd-DRI, Cancel Open > OR > Wait-Disc-Req > OR > Error Closed > (see note 3) > Rcv-Non-DRI Error Closed > Rcv-Disc-Req Snd-Disc-Ack Closed > Rcv-Conn-Req Snd-Conn-Nack Wait-DRI > Timeout Error Closed > Wait-Disc-Req Rcv-Disc-Req Snd-Disc-Ack Closed > Rcv-DRI Error Closed > Rcv-Non-DRI Error Closed > Rcv-Conn-Req Snd-Conn-Nack Wait-Disc-Req > Timeout Error Closed > > > Once Open, a single state machines describes further bevavior, > regardless of who initiated the surviving connection: > > state event action next state > ---------------------------------------------------------- > Open Rcv-Non-DRI Process Open > Rcv-DRI Error Closed > Stop Snd-Disc-Req Stopping > Rcv-Disc-Req Snd-Disc-Ack Closed > Stopping Rcv-Disc-Ack Closed > Rcv-DRI Error Closed > Rcv-Non-DRI Discard Stopping > > > Note 1 > ------ > When the initiator is in the Closed state and processes a Start > event, it acts as follows: > > (a) If the responder is also in the Closed state, it issues > a Snd-Conn-Req to start the connection process. > > (b) If the responder is not in the Closed state, it ignores > the Start event. > > > Note 2 > ------ > When the responder is in the Closed state and processes a > Rcv-Conn-Req, it acts as follows: > > (a) If the initiator is not in the Open state, it issues a > Snd-Conn-Ack. > > (b) If the initiator is in the Closed state, it MAY follow > the Snd-Conn-Ack with Snd-DRI. This is permissible > because it knows that only one direction of connection > is occurring and no election will be needed. Issuing DRI > immediately upon accepting a connection can shorten the > time it takes to establish an open connection, and could > provide the benefit of piggybacking the DRI onto the > same packet carrying the ack. > > (c) If the initiator is in the Open state, it issues a > Snd-Conn-Nack. > > > Note 3 > ------ > When the responder is in the Wait-DRI state and processes a > Rcv-DRI, it acts as follows: > > (a) If the initiator is in the Closed, Canceling, or Closing > states, it issues a Snd-DRI and transitions to Open. > > (b) If the initiator is in the Wait-Conn-Ack or Wait-DRI > state, it performs an election to determine which > transport layer connection survives. If it determines > that the responder's connection survives, it issues a > Snd-DRI followed by a Cancel, and transitions to Open. > If it determines that the initiator's connection > survives, it takes no action but transitions to > Wait-Disc-Req (expecting a disconnect request from its > peer). > > (c) If the initiator is in the Open state, it performs its > Error action to close this transport layer connection. > This will occur only if the peer misbehaved, by > incorrectly or prematurely electing the initiator's > connection as the surviving one. Oddly enough, despite > the failure of one of the peers to behave properly, > the result is that exactly one transport layer > connection survives. > > > The Election Process > -------------------- > The election is performed by the responder. The responder > compares the Origin-FQDN received in the DRI sent by its peer > with its own Origin-FQDN (which it may or may not have actually > sent). The transport layer connection with the higher value of > Origin-FQDN is the one that survives. The comparison proceeds by > considering the shorter OctetString to be null-padded to the > length of the longer, then performing an octet by octet unsigned > comparison with the first octet being most significant. Hanging > octets are assumed to have value 0x80, but dimpled octets are > ignored. > > Note that, depending on the sequence, the election process might > be performed by one of the peers or by both of the peers. > > > Action Glossary > --------------- > "Snd-Conn-Req" means to send a request to open a transport > layer connection. > > "Snd-Conn-Ack" means to send an acknowledgement in response > to a connect request, confirming that the transport layer > connection is open. > > "Snd-Conn-Nack" means to send a negative acknowledgement in > response to a connect request, indicating that the request was > refused. > > "Snd-DRI" means to send a DRI. > > "Error" means to drop the transport layer connection, either > politely or abortively, in response to an error condition. > > "Snd-Disc-Req" means to send a request to close a transport > layer connection. > > "Snd-Disc-Ack" means to acknowledge closure of a transport > layer connection, in response to receipt of a disconnect > request. > > "Cancel" means that the responder issues the Cancel event to > the initiator state machine, indicating that the responder's > transport layer connection will survive and the initiator's > transport layer connection will be closed. The Cancel event is > the only interaction between the two state machines. > > "Process" means to service a Diameter message. > > "Discard" means to ignore a Diameter message. The purpose here > is to flush pending reads while waiting for disconnect to be > acknowledged. Failure to do this under TCP could (depending on > stack implementation) leave the connection half closed. The TCP > stack will be in timed wait state, and might refuse subsequent > connections from the same address/port for several minutes. I > don't know if SCTP has a comparable issue. > > > Event Glossary > -------------- > "Start" means that the Diameter application has signalled that a > connection should be initiated. > > "Stop" means that the Diameter application has signalled that a > connection should be terminated (e.g., on system shutdown). > > "Cancel" means that the responder state machine has determined > that the responder connection will survive and that the > initiator's connection should be closed. > > "Rcv-Conn-Ack" means that the peer has opened the transport > layer connection requested by a Snd-Conn-Req. > > "Rcv-Conn-Nack" means that the peer has refused the transport > layer connection requested by a Snd-Conn-Req. > > "Rcv-Disc-Req" means that the peer has requested that the > transport layer connection be closed. > > "Rcv-Disc-Ack" means that the peer has acknowledged the closure > of the transport layer connection requested by a Snd-Disc-Req. > > "Timeout" means that an application-defined timer has expired > while waiting for some event. > > "Rcv-DRI" means that a DRI has been received. > > "Rcv-Non-DRI" means that a Diameter message other than DRI has > been received. > > > Final Note > ---------- > I think the draft should clearly state that the state machine > specification constrains the only the behavior of a Diameter > implementation as seen by Diameter peers through events on > the wire. Any implementation that produces equivalent results > is considered compliant. > > Paul > > > Paul Funk > Funk Software, Inc. > 617 497-6339 > paul@funk.com > From owner-aaa-bof@merit.edu Tue Mar 27 13:17:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24960 for ; Tue, 27 Mar 2001 13:17:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 353A25E01F; Tue, 27 Mar 2001 13:10:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AAD395E01D; Tue, 27 Mar 2001 13:10:33 -0500 (EST) Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105]) by segue.merit.edu (Postfix) with ESMTP id D14A75DFEB for ; Tue, 27 Mar 2001 13:10:22 -0500 (EST) Received: from erilab.com (eblcl50.erilab.com [192.168.174.190]) by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f2RIAGo13294; Tue, 27 Mar 2001 10:10:16 -0800 (PST) Message-ID: <3AC0D7AF.BB3ACAE9@erilab.com> Date: Tue, 27 Mar 2001 10:10:55 -0800 From: Michael Chen X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: "Martin Julien (ECE)" , "'tony.johansson@ericsson.com'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Indication for Home Agent allocation?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, Correct me if I am wrong. If Mobile_Node_Address is NULL(0.0.0.0) it request a home address. If Home_Agent_Address is NULL(0.0.0.0) MN is willing Home Agent alocate in visit domain. If Home_Agent_Address is -1(255.255.255.255) Home Agent MUST alocate in home domain What they describe in session 4.7 MIP-Feature-Vector AVP in diameter_mobileip_01 is not correct. Home address is differ from "home agent" address. This term confuse reader and some "home address" which is not correct in the draft need change to "home agent address". I would suggest you to use "mobile node address" instead of home address. Michael Patrice Calhoun wrote: > > I think that setting the Home Agent to all ones expresses a preference for > having the HA in the visited network, but only if possible. If the AAAF > decides for some reason that it cannot, or does not want to, allocate > additional resources in the visited network, it forwards the AMR to the AAAH > without the Foreign-Home-Agent-Available bit set. > From owner-aaa-bof@merit.edu Tue Mar 27 13:44:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25713 for ; Tue, 27 Mar 2001 13:44:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F9595E21E; Tue, 27 Mar 2001 13:42:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A888E5E121; Tue, 27 Mar 2001 13:39:52 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id DF80D5DF9F for ; Tue, 27 Mar 2001 13:35:38 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08728; Tue, 27 Mar 2001 10:35:31 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23452; Tue, 27 Mar 2001 10:35:30 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA14492; Tue, 27 Mar 2001 10:35:23 -0800 (PST) Date: Tue, 27 Mar 2001 10:35:22 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Indication for Home Agent allocation?? To: Michael Chen Cc: Patrice Calhoun , "Martin Julien (ECE)" , "'tony.johansson@ericsson.com'" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <3AC0D7AF.BB3ACAE9@erilab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > If Mobile_Node_Address is NULL(0.0.0.0) it request a home address. > If Home_Agent_Address is NULL(0.0.0.0) MN is willing Home Agent alocate in > visit domain. > If Home_Agent_Address is -1(255.255.255.255) Home Agent MUST alocate in home > domain What they describe in session 4.7 MIP-Feature-Vector AVP in > diameter_mobileip_01 is not correct. > Home address is differ from "home agent" address. This term confuse reader > and some "home address" which is not correct in the draft need change to > "home agent address". I would suggest you to use "mobile node address" > instead of home address. That sounds about right. I'll have a look at -02 and see what it says. PatC From owner-aaa-bof@merit.edu Tue Mar 27 14:20:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26862 for ; Tue, 27 Mar 2001 14:20:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0555D5DF51; Tue, 27 Mar 2001 14:16:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4D9B25DF59; Tue, 27 Mar 2001 14:16:39 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id D966A5DF50 for ; Tue, 27 Mar 2001 14:16:14 -0500 (EST) Received: (qmail 20145 invoked by uid 500); 27 Mar 2001 19:48:44 -0000 Date: Tue, 27 Mar 2001 13:48:44 -0600 From: David Frascone To: Patrice Calhoun Cc: Bob Kopacz , aaa-wg Subject: Re: [AAA-WG]: Re: [diameter] Base Protocol Message-ID: <20010327134844.K22945@newman.frascone.com> Mail-Followup-To: Patrice Calhoun , Bob Kopacz , aaa-wg References: <008e01c0b6b8$e6c0b300$d8448318@mw.mediaone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@nasnfs.Eng.Sun.COM on Tue, Mar 27, 2001 at 07:00:41AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk The, "unless otherwise noted" part works for me. On Tue, Mar 27, 2001 at 07:00:41AM -0800, Patrice Calhoun wrote: > hmmmm.... looks like I can't even read my own text :( > > You are correct that the spec does allow a zero octetstring AVP, > as Bob points out below. The way the text is written, it is a special > case, where it states that a specific AVP MAY have a zero length, but > this needs to be speficied in the AVP definition, otherwise the > minimum lenghs apply. > > So does the text need to change? > > PatC > > > > Hi Pat, > > > > I think it was good, though, that you added the > > "unless otherwise noted" phrase, as this allows cases > > where the presence of a string-type attribute with > > a null string can convey a different meaning than > > the absence of the AVP. > > > > I'm thinkin here of EAP. In RADIUS's EAP-Message > > attribute and in Diameter's EAP-Payload AVP, both > > of type string, a null string indicates EAP-Start. > > > > Bob K. > > > > ----- Original Message ----- > > From: Patrice Calhoun > > To: > > Cc: ; > > Sent: Monday, March 26, 2001 5:14 PM > > Subject: [AAA-WG]: Re: [diameter] Base Protocol > > > > > > [API questions answered by Dave, and deleted] > > > > > > > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > > > it is mentioned that > > > > > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > > > (13 if the 'V' bit is enabled). " > > > > > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > > > length should be 8 as data length can be 0 or more octect. > > > > Length of an OctetString is one (!0) or more octets. > > > > PatC > > > > > > > > > > > From owner-aaa-bof@merit.edu Tue Mar 27 15:21:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28461 for ; Tue, 27 Mar 2001 15:21:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9ADFB5DFA3; Tue, 27 Mar 2001 14:42:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 898675DFA1; Tue, 27 Mar 2001 14:42:24 -0500 (EST) Received: from sapphire.int.ipverse.com (unknown [65.195.29.42]) by segue.merit.edu (Postfix) with ESMTP id C5E8A5DF9E for ; Tue, 27 Mar 2001 14:42:22 -0500 (EST) Received: from matt.ipverse.com (MATT [10.1.1.226]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G9JPB39P; Tue, 27 Mar 2001 11:42:17 -0800 Message-Id: <5.0.2.1.2.20010327114010.01eee9f0@mail.ipverse.com> X-Sender: matt@mail.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 27 Mar 2001 11:42:30 -0800 To: aaa-wg@merit.edu From: Matt Holdrege Subject: RE: [AAA-WG]: AAA WG Interim meeting dates In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk For those who follow other WG's (most of us, I hope) there are many plans for interim meetings coming up around May 1st, since we have to have a 30 day notice. Hopefully the AD's will talk to each other a bit to avoid conflict. For instance, SIP and MIDCOM are hoping to have meetings around May1-4th. From owner-aaa-bof@merit.edu Tue Mar 27 16:45:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00797 for ; Tue, 27 Mar 2001 16:45:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6798D5DFC3; Tue, 27 Mar 2001 15:21:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5583B5DF3C; Tue, 27 Mar 2001 15:21:52 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id ED8B25DFBF for ; Tue, 27 Mar 2001 15:21:49 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2RKLpg16834 for ; Tue, 27 Mar 2001 14:21:51 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 27 Mar 2001 14:21:48 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Tue, 27 Mar 2001 14:21:48 -0600 Message-ID: From: Yogesh.Solanki@nokia.com To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Extension over base api as a separate process Date: Tue, 27 Mar 2001 14:21:42 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello, Does anybody have tried to implement extension(s) over base API. I have a question, whether AAA Base protocol implementation and extension(s) have to be in a single process or they can be separate processes. We are planning to implement extensions that will be separate processes from AAA Diameter base implementation. And we would like to have some guidelines from API specification. Yogesh Solanki From owner-aaa-bof@merit.edu Wed Mar 28 09:24:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28553 for ; Wed, 28 Mar 2001 09:24:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3CC5F5DF11; Wed, 28 Mar 2001 09:21:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B3965DF10; Wed, 28 Mar 2001 09:21:52 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id D5A5C5DF0F for ; Wed, 28 Mar 2001 09:21:49 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f2SELmd12149 for ; Wed, 28 Mar 2001 16:21:48 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f2SELkC27896 for ; Wed, 28 Mar 2001 17:21:47 +0300 (EET DST) Message-ID: <3AC1F37A.E4F36E1E@lmf.ericsson.se> Date: Wed, 28 Mar 2001 17:21:46 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Two accounting spec nits Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi. I went over some issues that Ericsson's 3GPP [UMTS] experts had on the DIAMETER accounting spec. A couple of minor fixes should perhaps be added to the spec. They are described below: - A number of AVPs in the accounting spec are mandatory, even they might not make sense for all applications. (e.g. a SIP proxy would not know the number of transferred packets in a call since it is not a party in the RTP session). The following AVPs should therefore be marked as optional and should appear 0 to 1 times in the accounting request packets. Accounting-Input-Octets Accounting-Input-Packets Accounting-Output-Octets Accounting-Output-Packets Accounting-Session-Time - Use of Accounting-Interim-Interval which appears in the accounting-request should be clarified. I believe the intent is to supply the value given from the authorization server, if any. Also, the use of the same AVP in the -answer message should be clarified in the same manner: I believe the intent is for the server to echo the value in the -request, possibly modify, or supply one if it was missing. This seems to be an important requirement for 3GPP who are going to decouple authorization server and prepaid server from each other and propably supply the AVP as an ack to the start request. Jari From owner-aaa-bof@merit.edu Wed Mar 28 09:41:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29207 for ; Wed, 28 Mar 2001 09:41:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4024E5DD9A; Wed, 28 Mar 2001 09:41:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 26B735DD9D; Wed, 28 Mar 2001 09:41:33 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8372A5DD9A for ; Wed, 28 Mar 2001 09:41:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12770; Wed, 28 Mar 2001 06:41:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05947; Wed, 28 Mar 2001 06:41:24 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA27249; Wed, 28 Mar 2001 06:41:08 -0800 (PST) Date: Wed, 28 Mar 2001 06:41:06 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Two accounting spec nits To: gwz@cisco.com Cc: Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] writes: > > > Hi. I went over some issues that Ericsson's 3GPP [UMTS] > > experts had on the DIAMETER accounting spec. A couple of > > minor fixes should perhaps be added to the spec. They are > > described below: > > > > - A number of AVPs in the accounting spec > > are mandatory, even they might not make > > sense for all applications. > > True, but I think a better approach might be to remove them from the base > spec altogether and place them (or equivalents) into the extension(s) for > which they are intended; in this case, NASREQ (perhaps better named > dial-access, since virtually everything seems to be a NAS these days ;-). Well, Mobile IP also needs these, so putting them in NASREQ may not be that wise... > > > (e.g. a > > SIP proxy would not know the number of > > transferred packets in a call since it > > is not a party in the RTP session). > > > > The following AVPs should therefore be > > marked as optional and should appear 0 to 1 > > times in the accounting request packets. > > > > Accounting-Input-Octets > > Accounting-Input-Packets > > Accounting-Output-Octets > > Accounting-Output-Packets > > Accounting-Session-Time So they should be optional. > > > > - Use of Accounting-Interim-Interval which appears > > in the accounting-request should be clarified. I > > believe the intent is to supply the value given > > from the authorization server, if any. > > Also, the use of the same AVP in the -answer > > message should be clarified in the same manner: > > I believe the intent is for the server to echo > > the value in the -request, possibly modify, or supply > > one if it was missing. This seems to be an > > important requirement for 3GPP who are going to > > decouple authorization server and prepaid server > > from each other and propably supply the AVP as > > an ack to the start request. ok, that's an easy enough fix. PatC From owner-aaa-bof@merit.edu Wed Mar 28 10:04:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00009 for ; Wed, 28 Mar 2001 10:04:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C2FD5DE84; Wed, 28 Mar 2001 10:00:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C0DC5DE73; Wed, 28 Mar 2001 10:00:38 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 9ECD95DDA1 for ; Wed, 28 Mar 2001 10:00:30 -0500 (EST) Received: from gwzpc (sjc-vpn-310.cisco.com [10.21.65.54]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id GAA10781; Wed, 28 Mar 2001 06:59:57 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 06:59:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] writes: > > > > > Hi. I went over some issues that Ericsson's 3GPP [UMTS] > > > experts had on the DIAMETER accounting spec. A couple of > > > minor fixes should perhaps be added to the spec. They are > > > described below: > > > > > > - A number of AVPs in the accounting spec > > > are mandatory, even they might not make > > > sense for all applications. > > > > True, but I think a better approach might be to remove them > from the base > > spec altogether and place them (or equivalents) into the > extension(s) for > > which they are intended; in this case, NASREQ (perhaps better named > > dial-access, since virtually everything seems to be a NAS these > days ;-). > > Well, Mobile IP also needs these, so putting them in NASREQ may > not be that > wise... I'm all for reusing code, but reusing AVPs only makes sense to me in an (extremely) constrained namespace. Is the test for whether AVPs should be included in the base protocol whether more than one extension needs them? If so, then, we can look forward to virtually endless modification of the base, since an extension can invent it's own AVPs, which another extension can see and say, "Gosh that looks good, I want that too" and there we go. A more reasonable criterion, IMHO, is whether the AVP is _necessary_ for the operation of the _base_ protocol. > > > > > > (e.g. a > > > SIP proxy would not know the number of > > > transferred packets in a call since it > > > is not a party in the RTP session). > > > > > > The following AVPs should therefore be > > > marked as optional and should appear 0 to 1 > > > times in the accounting request packets. > > > > > > Accounting-Input-Octets > > > Accounting-Input-Packets > > > Accounting-Output-Octets > > > Accounting-Output-Packets > > > Accounting-Session-Time > > So they should be optional. > > > > > > > - Use of Accounting-Interim-Interval which appears > > > in the accounting-request should be clarified. I > > > believe the intent is to supply the value given > > > from the authorization server, if any. > > > Also, the use of the same AVP in the -answer > > > message should be clarified in the same manner: > > > I believe the intent is for the server to echo > > > the value in the -request, possibly modify, or supply > > > one if it was missing. This seems to be an > > > important requirement for 3GPP who are going to > > > decouple authorization server and prepaid server > > > from each other and propably supply the AVP as > > > an ack to the start request. > > ok, that's an easy enough fix. > > PatC > > From owner-aaa-bof@merit.edu Wed Mar 28 10:08:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00215 for ; Wed, 28 Mar 2001 10:08:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05C7C5DE70; Wed, 28 Mar 2001 10:04:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E6A915DE29; Wed, 28 Mar 2001 10:04:45 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 2B81A5DDFD for ; Wed, 28 Mar 2001 10:04:43 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f2SF4fd21327; Wed, 28 Mar 2001 17:04:41 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f2SF4dC00374; Wed, 28 Mar 2001 18:04:39 +0300 (EET DST) Message-ID: <3AC1FD87.89139353@lmf.ericsson.se> Date: Wed, 28 Mar 2001 18:04:39 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Two accounting spec nits References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn wrote: > True, but I think a better approach > might be to remove them from the base > spec altogether and place them (or > equivalents) into the extension(s) for > which they are intended; in this case, > NASREQ (perhaps better named dial- > access, since virtually everything > seems to be a NAS these days I would agree with this. FYI, the 3GPP would also later define their own extension which adds some of their service-specific attributes in how the accounting is used. Jari From owner-aaa-bof@merit.edu Wed Mar 28 10:09:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00272 for ; Wed, 28 Mar 2001 10:09:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F8E65DF36; Wed, 28 Mar 2001 10:05:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6DD065DEE1; Wed, 28 Mar 2001 10:05:20 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 96BDE5DE29 for ; Wed, 28 Mar 2001 10:05:18 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id B3DB272; Wed, 28 Mar 2001 10:05:34 -0500 (EST) From: "Bob Kopacz" To: "Patrice Calhoun" Cc: "aaa-wg" Subject: RE: [AAA-WG]: Re: [diameter] Base Protocol Date: Wed, 28 Mar 2001 10:03:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit No, I don't think the text needs to change at all. I was just trying to point out that a null octetstring is not disallowed, and offered an existing example (EAP). > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] > Sent: Tuesday, March 27, 2001 10:01 AM > To: Bob Kopacz > Cc: Patrice Calhoun; aaa-wg > Subject: Re: [AAA-WG]: Re: [diameter] Base Protocol > > > hmmmm.... looks like I can't even read my own text :( > > You are correct that the spec does allow a zero octetstring AVP, > as Bob points out below. The way the text is written, it is a special > case, where it states that a specific AVP MAY have a zero length, but > this needs to be speficied in the AVP definition, otherwise the > minimum lenghs apply. > > So does the text need to change? > > PatC > > > > Hi Pat, > > > > I think it was good, though, that you added the > > "unless otherwise noted" phrase, as this allows cases > > where the presence of a string-type attribute with > > a null string can convey a different meaning than > > the absence of the AVP. > > > > I'm thinkin here of EAP. In RADIUS's EAP-Message > > attribute and in Diameter's EAP-Payload AVP, both > > of type string, a null string indicates EAP-Start. > > > > Bob K. > > > > ----- Original Message ----- > > From: Patrice Calhoun > > To: > > Cc: ; > > Sent: Monday, March 26, 2001 5:14 PM > > Subject: [AAA-WG]: Re: [diameter] Base Protocol > > > > > > [API questions answered by Dave, and deleted] > > > > > > > > -- In the section 4.3 of base protocol draft ( page 15 ), for OctectString > > > it is mentioned that > > > > > > "Unlessotherwise noted, the AVP Length field MUST be set to at least 9 > > > (13 if the 'V' bit is enabled). " > > > > > > My question why minimum length is 9 ( or 13 ) and not 8 ( or 12 ). Minimum > > > length should be 8 as data length can be 0 or more octect. > > > > Length of an OctetString is one (!0) or more octets. > > > > PatC > > > > > > > > > > > From owner-aaa-bof@merit.edu Wed Mar 28 10:10:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00363 for ; Wed, 28 Mar 2001 10:10:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C0CB5DE99; Wed, 28 Mar 2001 10:08:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E8D7E5DEEA; Wed, 28 Mar 2001 10:08:28 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 141475DF37 for ; Wed, 28 Mar 2001 10:08:25 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f2SF8Md24575; Wed, 28 Mar 2001 17:08:23 +0200 (MEST) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f2SF8EC00603; Wed, 28 Mar 2001 18:08:14 +0300 (EET DST) Message-ID: <3AC1FE5E.AAF9897F@lmf.ericsson.se> Date: Wed, 28 Mar 2001 18:08:14 +0300 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: gwz@cisco.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Two accounting spec nits References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Well, Mobile IP also needs these, so >putting them in NASREQ may not be that >wise... Yeah. Now I remember that some of these attributes were supposed to be in the base part to ease the applications to not always define their own, when they are likely needed by several apps. Maybe the optionality then is the best course of action here. Jari From owner-aaa-bof@merit.edu Wed Mar 28 10:11:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00420 for ; Wed, 28 Mar 2001 10:11:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 088CE5DF42; Wed, 28 Mar 2001 10:08:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 796455DF7D; Wed, 28 Mar 2001 10:08:41 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D92385DF42 for ; Wed, 28 Mar 2001 10:08:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25732; Wed, 28 Mar 2001 07:08:30 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10823; Wed, 28 Mar 2001 07:08:28 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA27511; Wed, 28 Mar 2001 07:08:09 -0800 (PST) Date: Wed, 28 Mar 2001 07:08:07 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Two accounting spec nits To: gwz@cisco.com Cc: Patrice Calhoun , Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > > Well, Mobile IP also needs these, so putting them in NASREQ may > > not be that > > wise... > > I'm all for reusing code, but reusing AVPs only makes sense to me in an > (extremely) constrained namespace. Is the test for whether AVPs should be > included in the base protocol whether more than one extension needs them? > If so, then, we can look forward to virtually endless modification of the > base, since an extension can invent it's own AVPs, which another extension > can see and say, "Gosh that looks good, I want that too" and there we go. A > more reasonable criterion, IMHO, is whether the AVP is _necessary_ for the > operation of the _base_ protocol. ok, i'd like to open this one up for discussion. The AVPs in question are: Accounting-Input-Octets Accounting-Input-Packets Accounting-Output-Octets Accounting-Output-Packets Accounting-Session-Time To me, these seem generic enough for accounting purposes that they could be used by *any* extension. However, I'll buy Glen's opposition about AVP reuse. What do others think? (of course, my personal preference is to keep them in the base, which is where all of the accounting stuff now resides) PatC From owner-aaa-bof@merit.edu Wed Mar 28 10:34:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01489 for ; Wed, 28 Mar 2001 10:34:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4FA785DE3A; Wed, 28 Mar 2001 10:31:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2EAF35DEBE; Wed, 28 Mar 2001 10:31:36 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 696265DE3A for ; Wed, 28 Mar 2001 10:31:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25581; Wed, 28 Mar 2001 07:31:26 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14234; Wed, 28 Mar 2001 07:31:22 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA27806; Wed, 28 Mar 2001 07:31:17 -0800 (PST) Date: Wed, 28 Mar 2001 07:31:13 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Two accounting spec nits To: Fredrik Johansson Cc: Patrice Calhoun , gwz@cisco.com, Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >> > > >> > Well, Mobile IP also needs these, so putting them in NASREQ may > >> > not be that > >> > wise... > >> > >> I'm all for reusing code, but reusing AVPs only makes sense to me in an > >> (extremely) constrained namespace. Is the test for whether AVPs > >should be > >> included in the base protocol whether more than one extension needs them? > >> If so, then, we can look forward to virtually endless modification of the > >> base, since an extension can invent it's own AVPs, which another > >extension > >> can see and say, "Gosh that looks good, I want that too" and > >there we go. A > >> more reasonable criterion, IMHO, is whether the AVP is > >_necessary_ for the > >> operation of the _base_ protocol. > > > >ok, i'd like to open this one up for discussion. The AVPs in > >question are: > > Accounting-Input-Octets > > Accounting-Input-Packets > > Accounting-Output-Octets > > Accounting-Output-Packets > > Accounting-Session-Time > > > >To me, these seem generic enough for accounting purposes that they could be > >used by *any* extension. However, I'll buy Glen's opposition about > >AVP reuse. > >What do others think? > > Sorry, but I've probably missed this earlier, why should accounting be a > part of the base protocol. I don't see why it should be mandatory when used > with MIP within a corporate environment. > Glen has brought this up ad nauseum on the list, and it was discussed at the IETF. The -01 I-D included a section that stated that Accounting is mandatory to support, but it was still an extension (hence advertised). It was finally decided to merge it into the base protocol. I initially did not like this because of the increased size of the base protocol document, but having an extension (which is advertised) is also the wrong thing to do since Accounting is part of the base protocol. So this is really nothing new, and if corporate networks don't want to use accounting, well they can easily turn that feature off. PatC From owner-aaa-bof@merit.edu Wed Mar 28 10:59:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02618 for ; Wed, 28 Mar 2001 10:59:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id 81A9E5DE73; Wed, 28 Mar 2001 10:59:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6B34C5DEBE; Wed, 28 Mar 2001 10:59:35 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id B44545DE73 for ; Wed, 28 Mar 2001 10:59:32 -0500 (EST) Received: from fredrikj (c24.local.ipunplugged.com [192.168.4.223]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA26435; Wed, 28 Mar 2001 17:59:08 +0200 From: "Fredrik Johansson" To: "Patrice Calhoun" Cc: , "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 18:01:23 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Patrice Calhoun >Sent: den 28 mars 2001 17:31 >To: Fredrik Johansson >Cc: Patrice Calhoun; gwz@cisco.com; Jari Arkko; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Two accounting spec nits > > >> >> > >> >> > Well, Mobile IP also needs these, so putting them in NASREQ may >> >> > not be that >> >> > wise... >> >> >> >> I'm all for reusing code, but reusing AVPs only makes sense >to me in an >> >> (extremely) constrained namespace. Is the test for whether AVPs >> >should be >> >> included in the base protocol whether more than one extension >needs them? >> >> If so, then, we can look forward to virtually endless >modification of the >> >> base, since an extension can invent it's own AVPs, which another >> >extension >> >> can see and say, "Gosh that looks good, I want that too" and >> >there we go. A >> >> more reasonable criterion, IMHO, is whether the AVP is >> >_necessary_ for the >> >> operation of the _base_ protocol. >> > >> >ok, i'd like to open this one up for discussion. The AVPs in >> >question are: >> > Accounting-Input-Octets >> > Accounting-Input-Packets >> > Accounting-Output-Octets >> > Accounting-Output-Packets >> > Accounting-Session-Time >> > >> >To me, these seem generic enough for accounting purposes that >they could be >> >used by *any* extension. However, I'll buy Glen's opposition about >> >AVP reuse. >> >What do others think? >> >> Sorry, but I've probably missed this earlier, why should accounting be a >> part of the base protocol. I don't see why it should be >mandatory when used >> with MIP within a corporate environment. >> > >Glen has brought this up ad nauseum on the list, and it was >discussed at the >IETF. The -01 I-D included a section that stated that Accounting >is mandatory >to support, but it was still an extension (hence advertised). It >was finally >decided to merge it into the base protocol. I initially did not like this >because of the increased size of the base protocol document, but having an >extension (which is advertised) is also the wrong thing to do >since Accounting >is part of the base protocol. > >So this is really nothing new, and if corporate networks don't want to use >accounting, well they can easily turn that feature off. It can easily be turned off, but why implement it in the first place. Following that argument one can make MIP and NASREQ mandatory but easy to turn off :-). Having a AAA protocol without one of the A's does not make a lot of sence and probably makes better explanation to why it should be there :-) I agree that having it as an extension is wrong if it should be mandatory. /Fredrik > >PatC > From owner-aaa-bof@merit.edu Wed Mar 28 11:00:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02674 for ; Wed, 28 Mar 2001 11:00:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 560565DF48; Wed, 28 Mar 2001 09:33:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 36C365DF4D; Wed, 28 Mar 2001 09:33:42 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 58CEF5DF48 for ; Wed, 28 Mar 2001 09:33:40 -0500 (EST) Received: from gwzpc (sjc-vpn-310.cisco.com [10.21.65.54]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id GAA09002; Wed, 28 Mar 2001 06:33:35 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 06:33:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3AC1F37A.E4F36E1E@lmf.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] writes: > Hi. I went over some issues that Ericsson's 3GPP [UMTS] > experts had on the DIAMETER accounting spec. A couple of > minor fixes should perhaps be added to the spec. They are > described below: > > - A number of AVPs in the accounting spec > are mandatory, even they might not make > sense for all applications. True, but I think a better approach might be to remove them from the base spec altogether and place them (or equivalents) into the extension(s) for which they are intended; in this case, NASREQ (perhaps better named dial-access, since virtually everything seems to be a NAS these days ;-). > (e.g. a > SIP proxy would not know the number of > transferred packets in a call since it > is not a party in the RTP session). > > The following AVPs should therefore be > marked as optional and should appear 0 to 1 > times in the accounting request packets. > > Accounting-Input-Octets > Accounting-Input-Packets > Accounting-Output-Octets > Accounting-Output-Packets > Accounting-Session-Time > > - Use of Accounting-Interim-Interval which appears > in the accounting-request should be clarified. I > believe the intent is to supply the value given > from the authorization server, if any. > Also, the use of the same AVP in the -answer > message should be clarified in the same manner: > I believe the intent is for the server to echo > the value in the -request, possibly modify, or supply > one if it was missing. This seems to be an > important requirement for 3GPP who are going to > decouple authorization server and prepaid server > from each other and propably supply the AVP as > an ack to the start request. > > Jari > > From owner-aaa-bof@merit.edu Wed Mar 28 11:15:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03366 for ; Wed, 28 Mar 2001 11:15:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCD4B5DF10; Wed, 28 Mar 2001 10:50:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B43B85DF0F; Wed, 28 Mar 2001 10:50:33 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id D569E5DE2D for ; Wed, 28 Mar 2001 10:50:31 -0500 (EST) Received: from gwzpc (sjc-vpn-310.cisco.com [10.21.65.54]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id HAA19756; Wed, 28 Mar 2001 07:50:13 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Fredrik Johansson" , "Patrice Calhoun" Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 07:48:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] writes: > Sorry, but I've probably missed this earlier, why should accounting be a > part of the base protocol. Um, 'cause it's a AAA protocol, not an AA protocol. > I don't see why it should be mandatory > when used > with MIP within a corporate environment. Nothing is mandatory to deploy, AFAIK... > > /Fredrik > > > > >(of course, my personal preference is to keep them in the base, > >which is where > >all of the accounting stuff now resides) > > > >PatC > > > > > > > From owner-aaa-bof@merit.edu Wed Mar 28 11:23:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03885 for ; Wed, 28 Mar 2001 11:23:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8C9545DEEF; Wed, 28 Mar 2001 11:21:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 638685DF61; Wed, 28 Mar 2001 11:21:51 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 088F45DEEF for ; Wed, 28 Mar 2001 11:21:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29689; Wed, 28 Mar 2001 08:21:30 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13163; Wed, 28 Mar 2001 08:21:28 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA28371; Wed, 28 Mar 2001 08:21:24 -0800 (PST) Date: Wed, 28 Mar 2001 08:21:21 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Two accounting spec nits To: Fredrik Johansson Cc: Patrice Calhoun , gwz@cisco.com, Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > It can easily be turned off, but why implement it in the first place. > Following that argument one can make MIP and NASREQ mandatory but easy to > turn off :-). Having a AAA protocol without one of the A's does not make a > lot of sence and probably makes better explanation to why it should be there > :-) You'd be surprised that you may be wrong. My experience (product, not research experience) shows that many corporate customers want to know who is using what, and how much. In many cases, there is a charge back from the IT dept to the user's department. So, a AAA client or server that doesn't support Accounting may not be very useful in the real world. > > I agree that having it as an extension is wrong if it should be mandatory. Good, the you agree with the strategy. PatC From owner-aaa-bof@merit.edu Wed Mar 28 12:15:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05254 for ; Wed, 28 Mar 2001 12:15:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBCFE5DEC2; Wed, 28 Mar 2001 11:09:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BAC6E5DEC0; Wed, 28 Mar 2001 11:09:51 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id F12065DE75 for ; Wed, 28 Mar 2001 11:09:48 -0500 (EST) Received: from gwzpc (sjc-vpn-310.cisco.com [10.21.65.54]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id IAA23147; Wed, 28 Mar 2001 08:09:17 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Fredrik Johansson" , "Patrice Calhoun" Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 08:07:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com] writes: ... > Having a AAA protocol without one of the A's does not make a > lot of sence and probably makes better explanation to why it > should be there > :-) My thought exactly :-) > > I agree that having it as an extension is wrong if it should be mandatory. > > /Fredrik > > > >PatC > > > > > From owner-aaa-bof@merit.edu Wed Mar 28 12:46:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06060 for ; Wed, 28 Mar 2001 12:46:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id C4BA05DD9D; Wed, 28 Mar 2001 10:24:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 93F905DDA1; Wed, 28 Mar 2001 10:24:41 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 88DD15DD9D for ; Wed, 28 Mar 2001 10:24:38 -0500 (EST) Received: from fredrikj (c24.local.ipunplugged.com [192.168.4.223]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA26010; Wed, 28 Mar 2001 17:23:38 +0200 From: "Fredrik Johansson" To: "Patrice Calhoun" , Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 17:25:53 +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) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >> > >> > Well, Mobile IP also needs these, so putting them in NASREQ may >> > not be that >> > wise... >> >> I'm all for reusing code, but reusing AVPs only makes sense to me in an >> (extremely) constrained namespace. Is the test for whether AVPs >should be >> included in the base protocol whether more than one extension needs them? >> If so, then, we can look forward to virtually endless modification of the >> base, since an extension can invent it's own AVPs, which another >extension >> can see and say, "Gosh that looks good, I want that too" and >there we go. A >> more reasonable criterion, IMHO, is whether the AVP is >_necessary_ for the >> operation of the _base_ protocol. > >ok, i'd like to open this one up for discussion. The AVPs in >question are: > Accounting-Input-Octets > Accounting-Input-Packets > Accounting-Output-Octets > Accounting-Output-Packets > Accounting-Session-Time > >To me, these seem generic enough for accounting purposes that they could be >used by *any* extension. However, I'll buy Glen's opposition about >AVP reuse. >What do others think? Sorry, but I've probably missed this earlier, why should accounting be a part of the base protocol. I don't see why it should be mandatory when used with MIP within a corporate environment. /Fredrik > >(of course, my personal preference is to keep them in the base, >which is where >all of the accounting stuff now resides) > >PatC > > From owner-aaa-bof@merit.edu Wed Mar 28 12:53:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06360 for ; Wed, 28 Mar 2001 12:53:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id D633F5DF74; Wed, 28 Mar 2001 12:50:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C49BF5DF73; Wed, 28 Mar 2001 12:50:57 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id 06AF85DF6D for ; Wed, 28 Mar 2001 12:50:55 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2SHf9N12541; Wed, 28 Mar 2001 09:41:09 -0800 From: "Bernard Aboba" To: "Patrice Calhoun" , Cc: "Jari Arkko" , Subject: [AAA-WG]: Extensibility model and IANA considerations Date: Wed, 28 Mar 2001 09:51:48 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > I'm all for reusing code, but reusing AVPs only makes sense to me in an > (extremely) constrained namespace. Is the test for whether AVPs should be > included in the base protocol whether more than one extension needs them? > If so, then, we can look forward to virtually endless modification of the > base, since an extension can invent it's own AVPs, which another extension > can see and say, "Gosh that looks good, I want that too" and there we go. A > more reasonable criterion, IMHO, is whether the AVP is _necessary_ for the > operation of the _base_ protocol. My understanding is that only the AVPs in the base protocol spec, and those defined within the extensions could set the 'M' bit. So there would be no need to modify the base spec in order to accomodate additional (optional) AVPs. If a NAS didn't understand those AVPs, it could ignore them. This provides a means of supporting additional AVPs that does not require modification to the base spec. If someone were to propose a new AVP for an extension or even the base, and a DIAMETER server were to send this AVP to a NAS, no harm would be done -- as long as there was no expectation that the NAS would be *required* to understand it. Thus, as long as the 'M' bit is clear, we have a way to add to the protocol without having to revise the specs. The problem comes from addition of new *mandatory* AVPs, either standardized or vendor-specific. We need to carefully think through the circumstances in which these will be allowed. This is part of the IANA considerations section -- a similar discussion has occurred within DHC WG with respect to handling of new options. If possible, I would try to address the issue of new AVPs without requiring the base protocol to be revved each time a new optional AVP is created. After all, we didn't have to rev RFC 2865 to accomodate RFC 2867-2869 extensions. Those specs stood on their own. Duplicating messages (and AVPs) also doesn't seem like a sensible strategy either. Other posters have noted that there are several DIAMETER messages that have roughly the same usage. It isn't entirely clear to me why those duplicate messages or AVPs need to exist. From owner-aaa-bof@merit.edu Wed Mar 28 12:58:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06462 for ; Wed, 28 Mar 2001 12:58:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 893B75DDB2; Wed, 28 Mar 2001 12:57:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 75A9B5DE29; Wed, 28 Mar 2001 12:57:56 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 4750F5DDB2 for ; Wed, 28 Mar 2001 12:57:53 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SHvsg18207 for ; Wed, 28 Mar 2001 11:57:54 -0600 (CST) Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Mar 2001 11:57:51 -0600 Received: by daebh02nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 11:57:51 -0600 Message-ID: <8572CF1E2A95D211A1190008C7EAA24604623CF8@daeis05nok> From: Sreenivas.Addagatla@nokia.com To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Extension over base api as a separate process Date: Wed, 28 Mar 2001 11:57:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Per the concerned draft (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt), Each DIAMETER implementation is at least one extension (since base protocol is never used by itself, but must be extended for use of some kind). Also, since DIAMETER is a peer to peer protocol (ref. section 1 of the same draft), both the client portion (that initiates authentication and/or authorization requests) and the server portion (that proxies or performs the requested authentication and/or authorization) have to be implemented as the base protocol. The above implication is further consolidated by the DIAMETER API draft's AAAOpen specification (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt, section 4.4.1.1), that after calling AAAOpen, a process is ready to accept requests on a specific port. Also, since the DIAMETER API draft defines command callbacks as local callbacks (objects in Java, functions in C), it is necessary that all extensions deployed on a host have to be part of the same process. A few different scenarios to achieve some kind of distributed processing are outlined below: 1. Within a single address space, the callbacks and/or separate threads related to the extensions handle communication with corresponding "agent" processes (e.g. a QoS agent does a lot of other stuff, using DIAMETER protocol for AA being a small part of its overall functionality). The down-side of this approach is that addition of new extensions is static and tedious (requires modification of existing source base); it is possible to achieve dynamic addition of extensions using demand loading of shared library objects (or Java classes), but still it is a lot of burden on agent processes implementations to incorporate IPC of some kind to the DIAMETER server process. 2. Each extension is a process by itself; but then all of them can not accept requests on the same specific port: thus, this alternative is not really an option 3. The implementation itself involves multiple processes, each linked with the base API; one of the processes performs part of DIAMETER server function (proxying within the host only), while the others perform the other server function (performing authentication and/or authorization per requests routed by the aforementioned proxying server process) and other client functions. Clearly, this involves a lot of complication on routing requests (by the proxying server process) by means of IPC, sharing dictionary and other data, presenting one DIAMETER peer image to other peers, etc. Comments? Regards, Sreenivas -----Original Message----- From: ext Yogesh.Solanki@nokia.com [mailto:Yogesh.Solanki@nokia.com] Sent: Tuesday,March 27,2001 14:22 To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu; diameter@diameter.org Subject: [AAA-WG]: Extension over base api as a separate process Hello, Does anybody have tried to implement extension(s) over base API. I have a question, whether AAA Base protocol implementation and extension(s) have to be in a single process or they can be separate processes. We are planning to implement extensions that will be separate processes from AAA Diameter base implementation. And we would like to have some guidelines from API specification. Yogesh Solanki From owner-aaa-bof@merit.edu Wed Mar 28 13:32:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06919 for ; Wed, 28 Mar 2001 13:32:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id C92AE5DF62; Wed, 28 Mar 2001 13:06:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A63545DF64; Wed, 28 Mar 2001 13:06:40 -0500 (EST) Received: from DTV3.DeltaTel.RU (dtv3.deltatel.ru [194.8.169.65]) by segue.merit.edu (Postfix) with SMTP id 12D9A5DF62 for ; Wed, 28 Mar 2001 13:06:38 -0500 (EST) Received: from SMTP.DeltaTel.RU ([172.16.1.44]) by DTV5.DeltaTel.RU with ESMTP; Wed, 28 Mar 2001 22:06:22 GMT Message-ID: <3AC229B8.F23E3614@SMTP.DeltaTel.RU> Date: Wed, 28 Mar 2001 22:13:12 +0400 From: "Ruslan R. Laishev" Organization: StarLet Group X-Mailer: Mozilla 4.08 [en] (WinNT; U) MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: diameter@diameter.org Subject: Re: [AAA-WG]: Extension over base api as a separate process References: <8572CF1E2A95D211A1190008C7EAA24604623CF8@daeis05nok> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello ! > The above implication is further consolidated by the DIAMETER API draft's > AAAOpen specification > (http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt, section > 4.4.1.1), that after calling AAAOpen, a process is ready to accept requests > on a specific port. It's expected that this API will universal for all platform? Is there a hope to get AST-driven API ? Or it will be a traditional unix-style coded blocking calls? -- Cheers, Ruslan. +---------------pure personal opinion-----------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 From owner-aaa-bof@merit.edu Wed Mar 28 14:38:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09367 for ; Wed, 28 Mar 2001 14:38:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 57A415DEC4; Wed, 28 Mar 2001 14:38:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 45DAA5DE29; Wed, 28 Mar 2001 14:38:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by segue.merit.edu (Postfix) with ESMTP id EE58E5DE24 for ; Wed, 28 Mar 2001 14:38:10 -0500 (EST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id LAA04877; Wed, 28 Mar 2001 11:38:30 -0800 (PST) Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177]) by mira-sjcm-3.cisco.com (Mirapoint) with SMTP id AAV39193; Wed, 28 Mar 2001 11:38:04 -0800 (PST) From: "John Alayari" To: "Patrice Calhoun" , "Fredrik Johansson" Cc: , "Jari Arkko" , Subject: RE: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 11:37:11 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit In 3GPP and similar usage of AAA, there may be multiple clients running for a given session. A AAA client in the SIP server may send an Accounting Request message and record-type AVP=START-RECORD with specific AVPs such as service type or QoS parameters to a AAA server and another AAA client in the SGSN may send the Accounting Request and record-type AVP = INTERIM_RECORD with usage information AVPs for the same accounting session. So my point is that, we need to revisit mandatory AVPs other than those Jeri mentioned (e.g. authentication-type)in the base accounting for these kind of applications. John. >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Patrice Calhoun >Sent: Wednesday, March 28, 2001 7:31 AM >Cc: Patrice Calhoun; gwz@cisco.com; Jari Arkko; aaa-wg@merit.edu >Subject: RE: [AAA-WG]: Two accounting spec nits > > >> > > >> > Well, Mobile IP also needs these, so putting them in NASREQ may > >> > not be that > >> > wise... > >> > >> I'm all for reusing code, but reusing AVPs only makes sense to me in an > >> (extremely) constrained namespace. Is the test for whether AVPs > >should be > >> included in the base protocol whether more than one extension needs them? > >> If so, then, we can look forward to virtually endless modification of the > >> base, since an extension can invent it's own AVPs, which another > >extension > >> can see and say, "Gosh that looks good, I want that too" and > >there we go. A > >> more reasonable criterion, IMHO, is whether the AVP is > >_necessary_ for the > >> operation of the _base_ protocol. > > > >ok, i'd like to open this one up for discussion. The AVPs in > >question are: > > Accounting-Input-Octets > > Accounting-Input-Packets > > Accounting-Output-Octets > > Accounting-Output-Packets > > Accounting-Session-Time > > > >To me, these seem generic enough for accounting purposes that they could be > >used by *any* extension. However, I'll buy Glen's opposition about > >AVP reuse. > >What do others think? > > Sorry, but I've probably missed this earlier, why should accounting be a > part of the base protocol. I don't see why it should be mandatory when used > with MIP within a corporate environment. > From owner-aaa-bof@merit.edu Wed Mar 28 15:10:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10130 for ; Wed, 28 Mar 2001 15:10:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3E8595DF4B; Wed, 28 Mar 2001 15:05:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2B2D05DECF; Wed, 28 Mar 2001 15:05:33 -0500 (EST) Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56]) by segue.merit.edu (Postfix) with ESMTP id 6002C5DE82 for ; Wed, 28 Mar 2001 15:05:06 -0500 (EST) Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com; Wed, 28 Mar 2001 15:04:06 -0500 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zbl6c012.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HSQK4VDD; Wed, 28 Mar 2001 15:04:06 -0500 Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id G0CXT5KA; Wed, 28 Mar 2001 15:04:06 -0500 Message-Id: <4.3.2.7.2.20010328145321.05967630@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Mar 2001 15:05:45 -0500 To: Patrice Calhoun , Paul Funk From: "David Mitton" Subject: Re: [AAA-WG]: Re: Connections that pass in the night Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk Folks, we have to do better than this. Proving all race conditions are handled in running code is extremely difficult, even in the best lab situations. This problem is best solved by some analysis and a tighter state definition. The problem is that we now have a peer-to-peer situation, where either side can simultaneously decide to initiate a request. Any scheme that attempts to ignore or abort the incoming connection while attempting their own connection is subject to lock-out or indefinite retries. Paul has suggested an approach where the connections are accepted, and an election process determines which will be closed. I believe this will work well and deterministicly, but his state tables still have some small problems. I will edit his text and re-post an improved solution soon. Dave. BTW: cross-posting to AAA-WG and Diameter lists is driving me (and my message filters) nuts. Can we use one or restrict topics?? At 3/27/01 12:14 PM -0500, Patrice Calhoun wrote: >Paul, > >I believe that the only way to really figure out whether this will work or >not >is by implementation. Given this is a fairly critical component of the >protocol, I would feel uncomfortable putting it in the draft without a >successful interop. > >So, would anyone out there be game to implement this, and we could run a test >over the net? I'm willing to do it, and could probably have this done by the >end of the day. > >Any other takers? > >PatC > > It has been decided that a pair of Diameter peers may have at > > most one open transport layer connection between them. This > > poses some difficulty when both peers attempt to open > > connections simultaneously. An election process is required to > > allow both peers to come to the same conclusion as to which > > connection will survive. > >... > > Paul Funk > > Funk Software, Inc. > > 617 497-6339 > > paul@funk.com --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Wireless Solutions, IP Mobility Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Wed Mar 28 15:26:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10412 for ; Wed, 28 Mar 2001 15:26:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B3BD5DEAD; Wed, 28 Mar 2001 15:25:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8B09C5DE24; Wed, 28 Mar 2001 15:25:36 -0500 (EST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by segue.merit.edu (Postfix) with ESMTP id EAB4E5DE29 for ; Wed, 28 Mar 2001 15:25:33 -0500 (EST) Received: from jariws1 ([193.229.23.111]) by fep01-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010328202533.PCBB18191.fep01-app.kolumbus.fi@jariws1>; Wed, 28 Mar 2001 23:25:33 +0300 Message-ID: <007e01c0b7c5$3ce2a2e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "John Alayari" Cc: References: Subject: Re: [AAA-WG]: Two accounting spec nits Date: Wed, 28 Mar 2001 23:25:32 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > In 3GPP and similar usage of AAA, there may be multiple clients running for > a given session. A AAA client in the SIP server may send an Accounting I think I understand the general setup you describe, but I would note the following: * In your particular example, I think it is more likely that the existing bearer service AAA schemes will be retained by 3GPP i.e. the SGSN will use a telco protocol in the accounting but the IP multimedia will run with DIAMETER. * One way of handling the accounting from several sources is to do the correlation of records in post-processing stage. In general, this may be the only way of doing this, given that various nodes may not have synchronization protocols in place to exchange e.g. session identities. * Also, various users of DIAMETER are all faced with the question of whether DIAMETER accounting is (a) sufficient as is from the RFC, (b) sufficient but additional attributes need to be defined, or (c) can be reused in part, but a new extension is required. I think most cases would fall on a or b. Jari From owner-aaa-bof@merit.edu Wed Mar 28 16:23:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12089 for ; Wed, 28 Mar 2001 16:23:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA4915DF16; Wed, 28 Mar 2001 16:23:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 97B245DF15; Wed, 28 Mar 2001 16:23:08 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8E3FF5DF12 for ; Wed, 28 Mar 2001 16:23:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22988; Wed, 28 Mar 2001 13:23:02 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00010; Wed, 28 Mar 2001 13:23:00 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA05764; Wed, 28 Mar 2001 13:23:00 -0800 (PST) Message-Id: <200103282123.NAA05764@heliopolis.Eng.Sun.COM> Date: Wed, 28 Mar 2001 13:23:00 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: RE: [AAA-WG]: Extension over base api as a separate process To: Yogesh.Solanki@nokia.com, Sreenivas.Addagatla@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: B68MKJ9LxiZ548XhPYI6dQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Sreenivas, > 1. Within a single address space, the callbacks and/or separate >threads related to the extensions handle communication with corresponding >"agent" processes (e.g. a QoS agent does a lot of other stuff, using >DIAMETER protocol for AA being a small part of its overall functionality). > > The down-side of this approach is that addition of new extensions >is static and tedious (requires modification of existing source base); it is >possible to achieve dynamic addition of extensions using demand loading of >shared library objects (or Java classes), but still it is a lot of burden on >agent processes implementations to incorporate IPC of some kind to the >DIAMETER server process. > With respect to the Java API, the intent was to make the client-side API have RPC semantics so that a client process could easily make calls into the API without having to handle difficult interthread communication. As we have discussed, and as per the note I sent to the list (without so far any response), we are also considering doing a synchronous API for C which would provide the same semantics for the C API. You are correct that the client code would need to be modified, but I have some difficulty seeing how one could enable a client to use Diameter without doing so. Perhaps some event messaging scheme could be used, but that is predicated on the client already using event messaging. Extensions do need to be loaded, but there are plenty of ways to load them via DLLs/shared libraries or, as you indicate in Java, demand loading. Once the client is enabled to use Diameter, there is really little overhead to loading an extension when the Diameter library is loaded. We currently do not define anything in the C API to allow demand loading, as there is no universal DLL/shared library loading standard, but we do use something on our platform. We have a configuration file that contains a list of shared libraries to load when the server starts. These shared libraries are the extensions that the server will deal with. We can put a property into the Java API that has a list of extension libraries to load. The client API currently doesn't need this, the assumption being that the client will allow the classes to be demand loaded, but when the Java server side API is complete, it might need the property. > 2. Each extension is a process by itself; but then all of them can >not accept requests on the same specific port: thus, this alternative is not >really an option > Agreed. > 3. The implementation itself involves multiple processes, each >linked with the base API; one of the processes performs part of DIAMETER >server function (proxying within the host only), while the others perform >the other server function (performing authentication and/or authorization >per requests routed by the aforementioned proxying server process) and other >client functions. > > Clearly, this involves a lot of complication on routing requests >(by the proxying server process) by means of IPC, sharing dictionary and >other data, presenting one DIAMETER peer image to other peers, etc. > I have difficulty seeing what this would by you beyond using a single multithreaded process. The only reason I could see for using multiple processes is if you are on an operating system that doesn't allow multiple threads. It seems to me structurally cleaner to have a base Diameter server that handes the required extensions and allow optional extensions to be dynamically linked as libraries. jak From owner-aaa-bof@merit.edu Wed Mar 28 16:26:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12210 for ; Wed, 28 Mar 2001 16:26:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id E80F85DF33; Wed, 28 Mar 2001 16:25:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D6AE55DF2F; Wed, 28 Mar 2001 16:25:46 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8D6055DF2C for ; Wed, 28 Mar 2001 16:25:44 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24489; Wed, 28 Mar 2001 13:25:42 -0800 (PST) Received: from heliopolis.Eng.Sun.COM (heliopolis.Eng.Sun.COM [152.70.1.39]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA00586; Wed, 28 Mar 2001 13:25:39 -0800 (PST) Received: from srmtv29a (srmtv29a [152.70.1.41]) by heliopolis.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA05838; Wed, 28 Mar 2001 13:25:39 -0800 (PST) Message-Id: <200103282125.NAA05838@heliopolis.Eng.Sun.COM> Date: Wed, 28 Mar 2001 13:25:39 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: [AAA-WG]: Extension over base api as a separate process To: aaa-wg@merit.edu, Laishev@SMTP.DeltaTel.RU Cc: diameter@diameter.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: JCPhUnFHOT1lHMrVsvCMsg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc Sender: owner-aaa-bof@merit.edu Precedence: bulk Ruslan, >> It's expected that this API will universal for all platform? Having a universal API achieves source code portability, which generally tends to accelerate the spread of a technology, but it is not as important as protocol interoperability (without which the implementation is simply broken). There are likely those who will implement the API, those who won't, and those who will extend it. > Is there a hope to get AST-driven API ? Or it will be a traditional unix-style coded >blocking calls? > What do you mean by AST? Currently, the C API is asynchronous, we are considering doing a synchronous API. jak From owner-aaa-bof@merit.edu Wed Mar 28 16:45:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12822 for ; Wed, 28 Mar 2001 16:45:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 110F55DF54; Wed, 28 Mar 2001 16:43:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAF8C5E008; Wed, 28 Mar 2001 16:43:30 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 1EACF5DF54 for ; Wed, 28 Mar 2001 16:43:28 -0500 (EST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2SLhTg20353 for ; Wed, 28 Mar 2001 15:43:30 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 28 Mar 2001 15:43:27 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Mar 2001 15:43:26 -0600 Message-ID: <8572CF1E2A95D211A1190008C7EAA24604623CFC@daeis05nok> From: Sreenivas.Addagatla@nokia.com To: kempf@heliopolis.Eng.Sun.COM, Yogesh.Solanki@nokia.com, Sreenivas.Addagatla@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Extension over base api as a separate process Date: Wed, 28 Mar 2001 15:43:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk James, Thanks for the comments. On item 3 below, the reason to use multiple processes not be solely due to lack of support for multiple threads. A process per an extension allows development and deployment independence from other extension implementations. We face a situation where a Mobile-IP module has a lot of Mobile-IP specific functionality and a very little component uses DIAMETER for AA: clearly, bundling the whole module as "Mobile-IP extension" works, but can affect both the DIAMETER server's and the Mobile-IP module's performance. For this reason, we are considering the Mobile-IP module be its own process, that has part of the DIAMETER server functionality (i.e., responding to AA requests), while the other part of DIAMETER functionality (accepting AA requests and proxying) is implemented as another process. I do agree that having all extensions in a single address space (process) is good enough in many cases; but the above consideration has driven the earlier posting. Regards, Sreenivas -----Original Message----- From: ext James Kempf [mailto:kempf@heliopolis.Eng.Sun.COM] Sent: Wednesday,March 28,2001 15:23 To: Yogesh.Solanki@nokia.com; Sreenivas.Addagatla@nokia.com Cc: aaa-wg@merit.edu; diameter@diameter.org Subject: RE: [AAA-WG]: Extension over base api as a separate process Sreenivas, === snip === > 3. The implementation itself involves multiple processes, each >linked with the base API; one of the processes performs part of DIAMETER >server function (proxying within the host only), while the others perform >the other server function (performing authentication and/or authorization >per requests routed by the aforementioned proxying server process) and other >client functions. > > Clearly, this involves a lot of complication on routing requests >(by the proxying server process) by means of IPC, sharing dictionary and >other data, presenting one DIAMETER peer image to other peers, etc. > I have difficulty seeing what this would by you beyond using a single multithreaded process. The only reason I could see for using multiple processes is if you are on an operating system that doesn't allow multiple threads. It seems to me structurally cleaner to have a base Diameter server that handes the required extensions and allow optional extensions to be dynamically linked as libraries. jak From owner-aaa-bof@merit.edu Wed Mar 28 20:12:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16221 for ; Wed, 28 Mar 2001 20:12:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A763B5DED3; Wed, 28 Mar 2001 20:09:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 90E6F5DF21; Wed, 28 Mar 2001 20:09:49 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C24825DED3 for ; Wed, 28 Mar 2001 20:09:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA13328; Wed, 28 Mar 2001 17:09:13 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29070; Wed, 28 Mar 2001 17:09:11 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA07023; Wed, 28 Mar 2001 17:09:03 -0800 (PST) Date: Wed, 28 Mar 2001 17:09:02 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Re: Connections that pass in the night To: David Mitton Cc: Patrice Calhoun , Paul Funk , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <4.3.2.7.2.20010328145321.05967630@ZBL6C008.corpeast.baynetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Folks, > we have to do better than this. Proving all race conditions are > handled in running code is extremely difficult, even in the best lab > situations. This problem is best solved by some analysis and a tighter > state definition. Right, but basic implementation will at least show whether or not it is even possible toimplement. Having tried, I found out that it isn't that simple. Paul is updating the state machine to something easier to implement. I agree that analysis is required, and I will do so, but there is nothing like actually writing to code to sanity check the basic table. > > The problem is that we now have a peer-to-peer situation, where > either side can simultaneously decide to initiate a request. Any scheme > that attempts to ignore or abort the incoming connection while attempting > their own connection is subject to lock-out or indefinite retries. Right, but to be fair, the old table was not subjected to that. I agree that Paul's table has a much richer set of conditions, but complexity goes along with it (in this case, justifiable). > Paul has suggested an approach where the connections are accepted, > and an election process determines which will be closed. > I believe this will work well and deterministicly, but his state tables > still have some small problems. I will edit his text and re-post an > improved solution soon. I would recommend that you wait until tomorrow. I am waiting for some clarifications on a new proposal, and if it works better, then I would prefer that you comment on the new one. PatC > > Dave. > > > BTW: cross-posting to AAA-WG and Diameter lists is driving me (and my > message filters) nuts. Can we use one or restrict topics?? yes, and I am trying to figure out what to do with the Diameter list. Perhaps turn it into an implementor's list? PatC From owner-aaa-bof@merit.edu Wed Mar 28 21:37:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19113 for ; Wed, 28 Mar 2001 21:37:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69ECE5DDCA; Wed, 28 Mar 2001 21:35:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 560915DDCE; Wed, 28 Mar 2001 21:35:13 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1BD565DDCA for ; Wed, 28 Mar 2001 21:35:12 -0500 (EST) Received: from phoenix (pm451-21.dialip.mich.net [204.39.226.79]) by aaa.interlinknetworks.com (Postfix) with SMTP id CAB0272; Wed, 28 Mar 2001 21:35:26 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / minor corrections Date: Wed, 28 Mar 2001 21:33:41 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Here's some suggested minor corrections. Here's the Legend for the line prefixes: ">" is a existing line from the draft. "-" is a existing line from the draft which should be deleted. "+" is a proposed line to be added. "> [...]" means two or more existing lines "!" is a comment about the preceding line. 3.0 Diameter Header =================== 1. The last sentence of the Hop-by-Hop-Identifier description says: "Diameter servers should consider a message to be unique by examining the source address, source port, Session-Id and Identifier field of the message" I think this sentence should be deleted. The last sentence of the End-to-End-Identifier description is the correct duplicate message check. 2. Grammar: The next-to-last sentence of the Hop-by-Hop-Identifier description begins "For The..." 3. In the descriptions of hop-by-hop and end-to-end identifier, the general term "identifier" is used without the "hop-by-hop" or "end-to-end" qualifier, though I guess by context it is clear which of the two identifiers is being referred to. 3.1 Command Codes ================== > [...] > > qual = [min] "*" [max] > ; See ABNF conventions, RFC 2234 section 6.6. > ; The absence of any qualifiers implies that one > ; and only one such AVP MUST be present. > ; > ; NOTE: "[" and "]" have a different meaning > ; than in ABNF (see the optional rule, above). - ; These braces cannot be used to express an + ; These braces cannot be used to express > ; optional fixed rules (such as an optional > ; ICV at the end.) To do this, the convention > ; is '0*1fixed'. > 4.5 Diameter Base Protocol AVPs ================================= Maybe alphabetize the list of AVPs 6.0 Capabilities Exchange ========================== > [...] > > With the exception of the Device-Reboot-Ind message, a message of > type Request, Query or Indication that includes the Extension-Id AVP, + or a message with an extension-specific command code, - MAY only be forwarded to a host that has explicitely advertised + MAY only be forwarded to a host that has explicitly advertised > support for the extension (or has advertised the Wildcard Extension). > 6.1.1 Vendor-Id AVP ==================== > [...] > > This MAY be used in order to know which vendor specific attributes + and vendor specific commands > may be sent to the peer. It is also envisioned that the combination > of the Vendor-Name and the Firmware-Revision (section 6.1.2) AVPs MAY > provide very useful debugging information. > 9.1 Device-Status-Ind ====================== > [...] > > When a Diameter node issues a DSI message downstream, the target peer > MUST attempt to rectify the problem, or issue a similar message > downstream. The Device-Status-Ind message MUST NOT be proxied, but - MAY be forwarded, as long as the Origin-FQDN AVP is replaced to - include the local node's identity. + MAY be forwarded, as long as the Origin-FQDN and Origin-Realm + AVPs are replaced to include the local node's identity. 10.1.1 Failed-AVP AVP ====================== > A Diameter message MAY contain one or more Failed-AVP AVPs, each > containing a complete AVP that could not be processed successfully. > The possible reasons for this AVP are the presence of an improperly > constructed AVP, an unsupported or unrecognized AVP, an invalid AVP - value; or the omission of a required AVP. + value, the omission of a required AVP, the presence of an + explicitly excluded AVP (see table 14.0), or the presence of two + or more occurances of an AVP which table 14.0 restricts to 0, 1, + or 0-1 occurances.. 11.7.2 Session-Termination-Request =================================== > [...] > > ::= < Diameter Header: 275 > > < Session-Id > > { Origin-FQDN } > { Origin-Realm } > { User-Name } > { Destination-Realm } + { Destination-FQDN } > * [ AVP ] > * [ Proxy-State ] > * [ Route-Record ] > 0*1< Integrity-Check-Value > 15.2 Command Code Values ========================= > As defined in section 3.0, the Command Code field has an associated > value maintained by IANA. Values 0-255 are reserved for backward - RADIUS compatibility, and values 257, 259, 274, 275 and 276 are + RADIUS compatibility, and values 257,259,274,275,276,280,281, and 282 are > defined in this specification. The remaining values are available for > assignment via Designated Expert [12]. 17.0 Diameter protocol related configurable parameters > [...] > > Maximum Age of an outstanding message > Messages older than the maximum age SHOULD be rejected, as > described in section 13.3. The recommended value is 4 seconds. ! Since the Timestamp AVP is part of ICV, and ICV is going away, ! does this configuration parameter go away, along with the references ! to time synchronization? From owner-aaa-bof@merit.edu Wed Mar 28 21:40:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19188 for ; Wed, 28 Mar 2001 21:40:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 635385DE44; Wed, 28 Mar 2001 21:36:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 51C6F5DE06; Wed, 28 Mar 2001 21:36:16 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id DAE825DDA9 for ; Wed, 28 Mar 2001 21:36:14 -0500 (EST) Received: from phoenix (pm451-21.dialip.mich.net [204.39.226.79]) by aaa.interlinknetworks.com (Postfix) with SMTP id EA66772; Wed, 28 Mar 2001 21:36:29 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "Aaa-Wg" Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / 14.0 AVP Table Date: Wed, 28 Mar 2001 21:34:44 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, I'm trying to sort out what validation checks to make when parsing the AVPs in a received Diameter message, in particular when counting the occurrences of certain AVPs in the message. Section 1.0 (Introduction) says that "AVPs may be added arbitrarily to Diameter messages, so long as the required AVPs are included and AVPs which are explicitly excluded are not included." Section 14.0 (AVP Table) specifies a table of AVPs which appear in the various Diameter messages and whether they occur 0, 1, 0-1, or 0+ times. The legend for the table says that "0" and "1" indicate MUSTs, while "0+" and "0-1" indicate MAYs, i.e.: > 0 The AVP MUST NOT be present in the message. > 0+ Zero or more instances of the AVP MAY be present > 0-1 Zero or one instance of the AVP MAY be present > 1 One instance of the AVP MUST be present in the message. Can someone comment on the following more detailed interpretation of what I think the AVP table says and what I think the introduction says? | When parsing a received Diameter message: | | 1. If the message contains an AVP which table indicates MUST | appear "0" times, then this is a "an explicitly excluded AVP is | included" error. [A new DIAMETER_AVP_NOT_ALLOWED code needs to | be defined, to use as the value for the Result-Code AVP in the | resulting error message]. | | 2. If the table indicates a certain AVP MUST appear "1" times, | and the message contains no occurrences of this AVP, then this | is a "required AVP not present" error. The Result-Code AVP | value to use in the resulting error message is | DIAMETER_MISSING_AVP. | | 3. If the table indicates a certain AVP MUST appear "1" times, | and the message contains 2+ occurrences of this AVP, then this is | a "too many occurrences of this AVP" error. [A new | DIAMETER_AVP_OCCURS_TOO_MANY_TIMES code needs to be defined, to | use as the value for the Result-Code AVP in the resulting error | message]. | | 4. If the table indicates a certain AVP MAY appear "0-1" times, | and the message contains 2+ occurrences of this AVP, then it's | unclear how to handle this. There seem to be two choices: | | a. Since the table legend indicates "MAY", it seems like an | implementation should just be friendly and not treat the 2nd | occurrence as an error. But then what's the difference | between "0-1" and "0+", if you're not going to enforce the | upper limit of 1? | | b. Or is the intent of "0-1" that 2+ occurrences of such an | AVP be treated as a "too many occurrences of this AVP" error? | | 5. If the received message contains an AVP that is not listed in | the table, then this is one of those "neither required nor | explicitly excluded AVPs that can be arbitrarily added to a | Diameter message", so is treated like a "0+". So no problem. | | Section 10.0 (End-to-End Error Signaling) describes six | different types of error conditions: Bad Message, Unknown | Command, Unknown AVP, Bad AVP Value, Request/Query Error, and | Answer/Response/Ind Error. | | When an AVP occurrence errors per cases 1-5 above happens, it is | treated as either a Request/Query Error or a Answer/Response/Ind | Error, depending on the command code. Also, two tiny nit-picks: 1. Rename section 14.0 from "AVP Table" to the more descriptive "AVP Occurrence Table". 2. Add a legend entry for "1+", which appears in the table. Bob K. From owner-aaa-bof@merit.edu Wed Mar 28 21:40:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19204 for ; Wed, 28 Mar 2001 21:40:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 79CE35DE68; Wed, 28 Mar 2001 21:36:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 679055DE5B; Wed, 28 Mar 2001 21:36:33 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 24E675DE06 for ; Wed, 28 Mar 2001 21:36:32 -0500 (EST) Received: from phoenix (pm451-21.dialip.mich.net [204.39.226.79]) by aaa.interlinknetworks.com (Postfix) with SMTP id 697E372; Wed, 28 Mar 2001 21:36:47 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / 9.1 Device-Status-Ind Date: Wed, 28 Mar 2001 21:35:02 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Here's some comments on the DSI. 1. The DSI message needs to convey sufficient information so the downstream peer can match it against some particular request/query, for retransmission to an alternate destination. So we might want to add something like the following to the draft, right before the Message Format (this is similar to a paragraph from the MRI description): The Device-Status-Ind message MUST contain the same Hop-by-Hop Identifier value in the header as the message which motivated sending the DSI. If the Session-Id AVP was present in the original message, the same AVP MUST be present in the DSI. 2. It doesn't seem to make sense to send a DSI for a (say, undeliverable) Answer/Response, as the downstream peer couldn't do anything useful with the DSI, and couldn't even match it with anything as it contain someone else's hop-by-hop identifier. Furthermore one wouldn't want to start a DSI-war by sending a DSI in response to an undeliverable DSI or MRI, so (if this makes sense) you might want to add another sentence like: The Device-Status-Ind message is only sent to indicate the status of a *-Request or *-Query message, and is not sent to indicate the status of a *-Answer, *-Response, or *-Ind message. Bob K. From owner-aaa-bof@merit.edu Wed Mar 28 22:45:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24143 for ; Wed, 28 Mar 2001 22:45:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id DF71B5DF7F; Wed, 28 Mar 2001 22:23:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE1AC5DF72; Wed, 28 Mar 2001 22:23:56 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id DE3D95DF1C for ; Wed, 28 Mar 2001 22:23:54 -0500 (EST) Received: from gwzpc (sjc-vpn-35.cisco.com [10.21.64.35]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id TAA00813; Wed, 28 Mar 2001 19:22:02 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Patrice Calhoun" Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Extensibility model and IANA considerations Date: Wed, 28 Mar 2001 19:19:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernad Aboba [mailto:aboba@internaut.com] writes: > > I'm all for reusing code, but reusing AVPs only makes sense to me in an > > (extremely) constrained namespace. Is the test for whether > AVPs should be > > included in the base protocol whether more than one extension > needs them? > > If so, then, we can look forward to virtually endless > modification of the > > base, since an extension can invent it's own AVPs, which > another extension > > can see and say, "Gosh that looks good, I want that too" and > there we go. > A > > more reasonable criterion, IMHO, is whether the AVP is > _necessary_ for the > > operation of the _base_ protocol. > > My understanding is that only the AVPs in the base protocol spec, > and those defined within the extensions could set the 'M' bit. So > there would be no need to modify the base spec in order to > accomodate additional (optional) AVPs. If a NAS didn't > understand those AVPs, it could ignore them. > > This provides a means of supporting additional AVPs that does not > require modification to the base spec. If someone were to propose > a new AVP for an extension or even the base, and a DIAMETER server > were to send this AVP to a NAS, no harm would be done -- as long > as there was no expectation that the NAS would be *required* to > understand it. Thus, as long as the 'M' bit is clear, we have a > way to add to the protocol without having to revise the specs. This discussion, though cogent, seems irrelevant. Pat's assertion was that the AVPs should be included (as optional) in the base because they were needed by >1 extensions. My argument is that they should not, for one reason that they are _not_ optional for either of the extensions in question. It seems to me that the extensions would need to either modify the base to state that the AVPs are mandatory or establish that while they are technically optional, they are (non-explicitly) mandatory in their contexts (wink, wink, nod, nod ;-). > > The problem comes from addition of new *mandatory* AVPs, either > standardized or vendor-specific. We need to carefully think through > the circumstances in which these will be allowed. This is part of > the IANA considerations section -- a similar discussion has occurred > within DHC WG with respect to handling of new options. Yes, but more to the point of this discussion, what about AVPs that are mandatory for some extensions (say, MIP & NASREQ) but optional (or even superfluous) for others? > > If possible, I would try to address the issue of new AVPs without > requiring the base protocol to be revved each time a new > optional AVP is created. After all, we didn't have > to rev RFC 2865 to accomodate RFC 2867-2869 extensions. Those > specs stood on their own. Well, umm, sort of. RFC 2867, in particular, is rife with references to attributes defined in other documents, as well as modifications to the semantics thereof. > > Duplicating messages (and AVPs) also doesn't seem like a sensible > strategy either. Other posters have noted that there are several > DIAMETER messages that have roughly the same usage. It isn't > entirely clear to me why those duplicate messages or AVPs need > to exist. From a protocol POV, I'll admit that there is probably not a great reason. However, fromm a specification POV, independently defined messages increase the cohesion of the documents, while decreasing the coupling between them. To use RFC 2867 as an example, in order to implement it a person needs to understand RFCs 2865-2869, inclusive. I would have _vastly_ preferred to have defined the compulsory tunneling attributes independent of the base RADIUS stuff, but the paucity of the RADIUS namespace prevented that; the same limitations do not exist in Diameter, and I think we should take advantage of it. To put it another way, I would like to be able to take 2 documents and implement both the base protocol and _any_ given Diameter extension, w/o needing to chase through a pile of essentially unrelated stuff searching for the definition of the _one_ AVP I need from it. > > > From owner-aaa-bof@merit.edu Thu Mar 29 03:18:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24421 for ; Thu, 29 Mar 2001 03:18:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id C11825DE0F; Wed, 28 Mar 2001 21:35:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B15D65DE06; Wed, 28 Mar 2001 21:35:42 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 7A2EE5DDCE for ; Wed, 28 Mar 2001 21:35:41 -0500 (EST) Received: from phoenix (pm451-21.dialip.mich.net [204.39.226.79]) by aaa.interlinknetworks.com (Postfix) with SMTP id C015A72; Wed, 28 Mar 2001 21:35:56 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" Cc: "aaa-wg" Subject: [AAA-WG]: draft-ietf-aaa-diameter-01 / Stateless server Date: Wed, 28 Mar 2001 21:34:11 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, One section of the draft indicates that a server can be stateless (i.e. maintaining neither session-state nor transaction-state), while another suggests that servers must maintain at least transaction-state: Section 12.4 states that a server can be completely stateless: > 12.4 Proxy Server > > This section outlines the processing rules for Diameter proxy > servers. A proxy server can either be stateful or stateless. A Proxy > server MAY act in a stateful manner for some requests, and be > stateless for others. There are two types of states that servers MAY > wish to maintain; transaction and session. > > Maintaining transaction state implies that a server keeps a copy of a > request, which is then used when the corresponding response is > received. > > [...] But section 7.3 suggests that it is "necessary" for a [proxy] server to maintain transaction state, for failover purposes. > 7.3 Failover/Failback Procedures > > In the event that a transport failure is detected with a peer, it is > necessary for all pending request, query and indication messages to > be forwarded to an alternate server, if possible. This is commonly > referred to as failover. > > In order for a Diameter node to perform failover procedures, it is > necessary for the node to maintain a pending message queue for a > given peer. When a response is received, the message is removed from > the queue. > > [...] Bob K. From owner-aaa-bof@merit.edu Thu Mar 29 19:37:33 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21230 for ; Thu, 29 Mar 2001 19:37:33 -0500 (EST) Received: by segue.merit.edu (Postfix) id E28DF5DDBD; Thu, 29 Mar 2001 19:34:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CACA65DE6F; Thu, 29 Mar 2001 19:34:21 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9142D5DDBD for ; Thu, 29 Mar 2001 19:34:20 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24187; Thu, 29 Mar 2001 16:34:19 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03578; Thu, 29 Mar 2001 16:34:14 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA20886; Thu, 29 Mar 2001 16:34:12 -0800 (PST) Date: Thu, 29 Mar 2001 16:34:10 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / Stateless server To: Bob Kopacz Cc: Pat Calhoun , aaa-wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Bob, Great catch. In adding the failover text, I completely missed this one. I am proposing the following text to replace the existing section 12.4: 12.4 Proxy Server This section outlines the processing rules for Diameter proxy servers. A proxy server can either be stateful or stateless. A Proxy server MAY act in a stateful manner for some requests, and be stateless for others. There are two types of states that servers MAY wish to maintain; transaction and session. Maintaining transaction state implies that a server keeps a copy of a request, which is then used when the corresponding response is received. This could be done to apply local policies to the message, or simply for auditing purposes. Maintaining session state implies that a server keeps track of all "active" users. An active user is one that has been authorized for a particular service, and the server has not received any indication that the user has relinquished access. A stateless proxy is one that does not maintain session state, but MUST maintain transaction state. Transaction state SHOULD be released after a request's corresponding response has been forwarded towards the recipient, and has been acknowledged by the underlying transport. A stateful proxy is one that maintains session state, by observing request and responses. Session state SHOULD be released once it is informed that a user and/or device has relinquished access. A stateful server MAY provide the following features: - Protocol translation (e.g. RADIUS <-> Diameter) - Limiting resources authorized to a particular user - Per user or transaction auditing Home servers processing requests that include the Route-Record and/or the Proxy-State AVPs MUST return these AVPs in the same order in the corresponding response. From owner-aaa-bof@merit.edu Thu Mar 29 19:43:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21439 for ; Thu, 29 Mar 2001 19:43:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 895CB5DE26; Thu, 29 Mar 2001 19:43:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 786C35DE25; Thu, 29 Mar 2001 19:43:28 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 48A985DE1C for ; Thu, 29 Mar 2001 19:43:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08849; Thu, 29 Mar 2001 16:43:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05199; Thu, 29 Mar 2001 16:43:24 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA21052; Thu, 29 Mar 2001 16:43:22 -0800 (PST) Date: Thu, 29 Mar 2001 16:43:20 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / 9.1 Device-Status-Ind To: Bob Kopacz Cc: Pat Calhoun , aaa-wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > 1. The DSI message needs to convey sufficient information so the > downstream peer can match it against some particular request/query, > for retransmission to an alternate destination. So we might want to > add something like the following to the draft, right before the > Message Format (this is similar to a paragraph from the MRI > description): > > The Device-Status-Ind message MUST contain the same Hop-by-Hop > Identifier value in the header as the message which motivated > sending the DSI. If the Session-Id AVP was present in the > original message, the same AVP MUST be present in the DSI. I completely agree, this text needs to be present. > > 2. It doesn't seem to make sense to send a DSI for a (say, > undeliverable) Answer/Response, as the downstream peer couldn't > do anything useful with the DSI, and couldn't even match it with > anything as it contain someone else's hop-by-hop identifier. > Furthermore one wouldn't want to start a DSI-war by sending a > DSI in response to an undeliverable DSI or MRI, so (if this > makes sense) you might want to add another sentence like: > > The Device-Status-Ind message is only sent to indicate the > status of a *-Request or *-Query message, and is not sent to > indicate the status of a *-Answer, *-Response, or *-Ind message. Two problems here: 1. Let's assume that a Session-Termination-Ind is sent, and it cannot be delivered, your proposal would cause a silent discard, which is bad. BTW, if a DSI is sent in response to an MRI, I don't see why the sender would insist on sending ad nauseum, and create the war you've described above. 2. If an *-Answer of *-Response cannot be delivered, it MAY be useful to know, since you would know that resources hadn't been allocated for the session. However, I agree that such a message cannot really be sent to an alternate peer. I guess what I'm saying is that I am not sure that a blanket statement like this will work, but a blanket statement is MUCH better than a whole bunch of special conditions. PatC From owner-aaa-bof@merit.edu Thu Mar 29 19:55:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21860 for ; Thu, 29 Mar 2001 19:55:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 471225DEFB; Thu, 29 Mar 2001 19:50:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 32EB65DEF9; Thu, 29 Mar 2001 19:50:05 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9BEA25DEF0 for ; Thu, 29 Mar 2001 19:50:03 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04366; Thu, 29 Mar 2001 16:49:57 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06444; Thu, 29 Mar 2001 16:49:57 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA21160; Thu, 29 Mar 2001 16:49:54 -0800 (PST) Date: Thu, 29 Mar 2001 16:49:52 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / 14.0 AVP Table To: Bob Kopacz Cc: Pat Calhoun , Aaa-Wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Can someone comment on the following more detailed > interpretation of what I think the AVP table says > and what I think the introduction says? > > | When parsing a received Diameter message: > | > | 1. If the message contains an AVP which table indicates MUST > | appear "0" times, then this is a "an explicitly excluded AVP is > | included" error. [A new DIAMETER_AVP_NOT_ALLOWED code needs to > | be defined, to use as the value for the Result-Code AVP in the > | resulting error message]. > | > | 2. If the table indicates a certain AVP MUST appear "1" times, > | and the message contains no occurrences of this AVP, then this > | is a "required AVP not present" error. The Result-Code AVP > | value to use in the resulting error message is > | DIAMETER_MISSING_AVP. > | > | 3. If the table indicates a certain AVP MUST appear "1" times, > | and the message contains 2+ occurrences of this AVP, then this is > | a "too many occurrences of this AVP" error. [A new > | DIAMETER_AVP_OCCURS_TOO_MANY_TIMES code needs to be defined, to > | use as the value for the Result-Code AVP in the resulting error > | message]. > | > | 4. If the table indicates a certain AVP MAY appear "0-1" times, > | and the message contains 2+ occurrences of this AVP, then it's > | unclear how to handle this. There seem to be two choices: > | > | a. Since the table legend indicates "MAY", it seems like an > | implementation should just be friendly and not treat the 2nd > | occurrence as an error. But then what's the difference > | between "0-1" and "0+", if you're not going to enforce the > | upper limit of 1? > | > | b. Or is the intent of "0-1" that 2+ occurrences of such an > | AVP be treated as a "too many occurrences of this AVP" error? > | > | 5. If the received message contains an AVP that is not listed in > | the table, then this is one of those "neither required nor > | explicitly excluded AVPs that can be arbitrarily added to a > | Diameter message", so is treated like a "0+". So no problem. > | > | Section 10.0 (End-to-End Error Signaling) describes six > | different types of error conditions: Bad Message, Unknown > | Command, Unknown AVP, Bad AVP Value, Request/Query Error, and > | Answer/Response/Ind Error. > | > | When an AVP occurrence errors per cases 1-5 above happens, it is > | treated as either a Request/Query Error or a Answer/Response/Ind > | Error, depending on the command code. > All of the above assumptions are correct, but not described anywhere in the spec. Are you proposing that such statements be added to the base protocol for clarification (and the missing Result-Codes, of course)? Anyone else? PatC From owner-aaa-bof@merit.edu Thu Mar 29 19:57:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA21969 for ; Thu, 29 Mar 2001 19:57:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id A43535DF2F; Thu, 29 Mar 2001 19:56:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8DE0F5DF3B; Thu, 29 Mar 2001 19:56:23 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4CD795DF2F for ; Thu, 29 Mar 2001 19:56:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08633; Thu, 29 Mar 2001 16:56:11 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07477; Thu, 29 Mar 2001 16:56:10 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA21295; Thu, 29 Mar 2001 16:55:58 -0800 (PST) Date: Thu, 29 Mar 2001 16:55:53 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Extensibility model and IANA considerations To: gwz@cisco.com Cc: Bernard Aboba , Patrice Calhoun , Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I buy some of Glen's comments about having parse through multiple documents to get an extension completed. However, I am looking for concrete examples of what needs to be done. Ideas? (btw, one idea I had was to move the filter definition text into the base, but just leave the AVP definition in the relevant documents. Not sure Glen would like that any better than the original proposal). PatC From owner-aaa-bof@merit.edu Thu Mar 29 23:24:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09647 for ; Thu, 29 Mar 2001 23:24:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id D3E405DF5D; Thu, 29 Mar 2001 23:20:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E10545DFCB; Thu, 29 Mar 2001 23:20:20 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 8E1D65DF5D for ; Thu, 29 Mar 2001 23:19:33 -0500 (EST) Received: from bkopacz98 (nic-131-c68-216.mw.mediaone.net [24.131.68.216]) by aaa.interlinknetworks.com (Postfix) with SMTP id BC10772; Thu, 29 Mar 2001 23:19:49 -0500 (EST) Message-ID: <000e01c0b8d0$96547680$d8448318@mw.mediaone.net> From: "Bob Kopacz" To: "Patrice Calhoun" Cc: "aaa-wg" References: Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / 14.0 AVP Table Date: Thu, 29 Mar 2001 23:19:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Patrice Calhoun To: Bob Kopacz Cc: Pat Calhoun ; Aaa-Wg Sent: Thursday, March 29, 2001 7:49 PM Subject: Re: draft-ietf-aaa-diameter-01 / 14.0 AVP Table > > Can someone comment on the following more detailed > > interpretation of what I think the AVP table says > > and what I think the introduction says? > > > > | When parsing a received Diameter message: > > | > > | 1. If the message contains an AVP which table indicates MUST > > | appear "0" times, then this is a "an explicitly excluded AVP is > > | included" error. [A new DIAMETER_AVP_NOT_ALLOWED code needs to > > | be defined, to use as the value for the Result-Code AVP in the > > | resulting error message]. > > | > > | 2. If the table indicates a certain AVP MUST appear "1" times, > > | and the message contains no occurrences of this AVP, then this > > | is a "required AVP not present" error. The Result-Code AVP > > | value to use in the resulting error message is > > | DIAMETER_MISSING_AVP. > > | > > | 3. If the table indicates a certain AVP MUST appear "1" times, > > | and the message contains 2+ occurrences of this AVP, then this is > > | a "too many occurrences of this AVP" error. [A new > > | DIAMETER_AVP_OCCURS_TOO_MANY_TIMES code needs to be defined, to > > | use as the value for the Result-Code AVP in the resulting error > > | message]. > > | > > | 4. If the table indicates a certain AVP MAY appear "0-1" times, > > | and the message contains 2+ occurrences of this AVP, then it's > > | unclear how to handle this. There seem to be two choices: > > | > > | a. Since the table legend indicates "MAY", it seems like an > > | implementation should just be friendly and not treat the 2nd > > | occurrence as an error. But then what's the difference > > | between "0-1" and "0+", if you're not going to enforce the > > | upper limit of 1? > > | > > | b. Or is the intent of "0-1" that 2+ occurrences of such an > > | AVP be treated as a "too many occurrences of this AVP" error? > > | > > | 5. If the received message contains an AVP that is not listed in > > | the table, then this is one of those "neither required nor > > | explicitly excluded AVPs that can be arbitrarily added to a > > | Diameter message", so is treated like a "0+". So no problem. > > | > > | Section 10.0 (End-to-End Error Signaling) describes six > > | different types of error conditions: Bad Message, Unknown > > | Command, Unknown AVP, Bad AVP Value, Request/Query Error, and > > | Answer/Response/Ind Error. > > | > > | When an AVP occurrence errors per cases 1-5 above happens, it is > > | treated as either a Request/Query Error or a Answer/Response/Ind > > | Error, depending on the command code. > > > > All of the above assumptions are correct, but not described anywhere in the > spec. Are you proposing that such statements be added to the base protocol for > clarification (and the missing Result-Codes, of course)? > > Anyone else? > > PatC I think this would be too much verbage to add to the base. Other than the missing Result-Code, the only real question in all my blathering was case #4 above, whether (a) or (b) is the intended handling of a "0-1" AVP occurring 2+ times. From owner-aaa-bof@merit.edu Fri Mar 30 02:54:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16377 for ; Fri, 30 Mar 2001 02:54:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id E253E5DE43; Fri, 30 Mar 2001 02:54:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D05BF5DE33; Fri, 30 Mar 2001 02:54:11 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.101]) by segue.merit.edu (Postfix) with ESMTP id F0EDB5DDC6 for ; Fri, 30 Mar 2001 02:54:09 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f2U7iDN32277; Thu, 29 Mar 2001 23:44:14 -0800 From: "Bernard Aboba" To: , "Patrice Calhoun" Cc: "Jari Arkko" , Subject: RE: [AAA-WG]: Extensibility model and IANA considerations Date: Thu, 29 Mar 2001 23:55:04 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >This discussion, though cogent, seems irrelevant. Pat's assertion was that >the AVPs should be included (as optional) in the base because they were >needed by >1 extensions. My argument is that they should not, for one >reason that they are _not_ optional for either of the extensions in >question. It seems to me that the extensions would need to either modify >the base to state that the AVPs are mandatory or establish that while they >are technically optional, they are (non-explicitly) mandatory in their >contexts (wink, wink, nod, nod ;-). I think it makes sense to include AVPs in the base protocol that are used in more than one extension. However, as you point out, if they are mandatory in more than one extension, then they cannot be made optional in the base spec. If an AVP does not have the same status for all extensions, it seems to me that the base spec would need to specify the extensions for which the 'M' bit can be set. >Yes, but more to the point of this discussion, what about AVPs that are >mandatory for some extensions (say, MIP & NASREQ) but optional (or even >superfluous) for others? I would propose that the base spec include a table specifying for each AVP and extension whether the 'M' bit may be set or not. Each new extension could also include such a table. >From a protocol POV, I'll admit that there is probably not a great reason. >However, fromm a specification POV, independently defined messages increase >the cohesion of the documents, while decreasing the coupling between them. >To use RFC 2867 as an example, in order to implement it a person needs to >understand RFCs 2865-2869, inclusive. I would have _vastly_ preferred to >have defined the compulsory tunneling attributes independent of the base >RADIUS stuff, but the paucity of the RADIUS namespace prevented that. How did the paucity of attributes influence the design? In order to handle compulsory tunneling accounting, new accounting messages *were* defined, so this had some of the character of an "extension". Can you talk about the advantages and disadvantages of this approach? One thing that has occurred to me about RADIUS is that with new access types like VPN, the combination of NAS-Port-Type and the message in effect define an "extension": the semantics of the AVPs may change as a result. For example, if NAS-Port-Type = 802.11, there is no point sending a number of attributes that might make sense if NAS-Port-Type = Virtual. The nice thing about this is that these "extensions" can in effect be created without the need for any code changes, assuming that the RADIUS implementation has an extensible dictionary and supports conditional behavior. (For an example of conditional behavior in the ISC DHCP server, see Droms & Lemon's "DHCP Handbook"). So if possible, I'd rather not move to a model in which DIAMETER server code updates are needed to support "extensions" that could have been implemented as dictionary additions under RADIUS. This seems like a step backward. >To put it another way, I would like to be able to take 2 >documents and implement both the base protocol and _any_ given Diameter >extension, w/o needing to chase through a pile of essentially unrelated >stuff searching for the definition of the _one_ AVP I need from it. Well, I would say that it is ok to describe an AVP or messages in two places, if that would help, as long as the definition is the same. But creating new messages or AVPs that do the same thing as the old ones seems like a bad idea, because it requires unnecessary code changes. From owner-aaa-bof@merit.edu Fri Mar 30 04:51:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA00735 for ; Fri, 30 Mar 2001 04:51:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id D83145DE47; Fri, 30 Mar 2001 01:26:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BCD905DE43; Fri, 30 Mar 2001 01:26:48 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id E7B5B5DEEE for ; Fri, 30 Mar 2001 01:26:44 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f2U6Qa380260; Fri, 30 Mar 2001 01:26:36 -0500 (EST) (envelope-from barney) Date: Fri, 30 Mar 2001 01:26:36 -0500 From: Barney Wolff To: Patrice Calhoun Cc: Bob Kopacz , Pat Calhoun , aaa-wg Subject: Re: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / Stateless server Message-ID: <20010330012635.A80035@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.Eng.Sun.COM on Thu, Mar 29, 2001 at 04:34:10PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Ok, now I'm really confused. Back when we were debating stateful/ stateless, I could have sworn we were talking about transaction state, not session state. At least I was. Be that as it may, this language is confusing, as it seems to (but cannot really) say that only a (session-)stateless proxy MUST maintain transaction state. Also, what does the statefulness of a proxy or server have to do with its ability to do protocol translation? And the paragraph starts out talking about a stateful proxy but shifts to a server. I have nothing against advice to implementors, but believe we go too far when we use WORDS to express it. Regards, Barney On Thu, Mar 29, 2001 at 04:34:10PM -0800, Patrice Calhoun wrote: > > A stateless proxy is one that does not maintain session state, but > MUST maintain transaction state. Transaction state SHOULD be released > after a request's corresponding response has been forwarded towards > the recipient, and has been acknowledged by the underlying transport. > > A stateful proxy is one that maintains session state, by observing > request and responses. Session state SHOULD be released once it is > informed that a user and/or device has relinquished access. A > stateful server MAY provide the following features: > - Protocol translation (e.g. RADIUS <-> Diameter) From owner-aaa-bof@merit.edu Fri Mar 30 09:57:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18838 for ; Fri, 30 Mar 2001 09:57:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A13D5DFD8; Fri, 30 Mar 2001 09:51:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 648185E017; Fri, 30 Mar 2001 09:51:33 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 6D7555DFD8 for ; Fri, 30 Mar 2001 09:51:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06330; Fri, 30 Mar 2001 06:51:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08455; Fri, 30 Mar 2001 06:51:04 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA26402; Fri, 30 Mar 2001 06:51:01 -0800 (PST) Date: Fri, 30 Mar 2001 06:50:58 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / 14.0 AVP Table To: Bob Kopacz Cc: Patrice Calhoun , aaa-wg In-Reply-To: "Your message with ID" <000e01c0b8d0$96547680$d8448318@mw.mediaone.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I think this would be too much verbage to add to the base. ok, good. > Other than the missing Result-Code, which I agree are missing, and I will add them. > the only real question in all my > blathering was case #4 above, whether (a) or (b) is the intended handling > of a "0-1" AVP occurring 2+ times. If the I-D states that zero or one times, then more than one is an error, and your proposed DIAMETER_AVP_OCCURS_TOO_MANY_TIMES Result-Code would work just fine. I can make sure that this one particular case is clarified. PatC From owner-aaa-bof@merit.edu Fri Mar 30 10:04:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19334 for ; Fri, 30 Mar 2001 10:04:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id CD81B5E18D; Fri, 30 Mar 2001 09:59:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 980AF5E18C; Fri, 30 Mar 2001 09:59:24 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id EA3975E187 for ; Fri, 30 Mar 2001 09:59:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13079; Fri, 30 Mar 2001 06:59:09 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10656; Fri, 30 Mar 2001 06:59:09 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA26505; Fri, 30 Mar 2001 06:59:05 -0800 (PST) Date: Fri, 30 Mar 2001 06:59:00 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Extensibility model and IANA considerations To: Bernard Aboba Cc: gwz@cisco.com, Patrice Calhoun , Jari Arkko , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Yes, but more to the point of this discussion, what about AVPs that are > >mandatory for some extensions (say, MIP & NASREQ) but optional (or even > >superfluous) for others? > > I would propose that the base spec include a table specifying for each > AVP and extension whether the 'M' bit may be set or not. Each new > extension could also include such a table. The table *is* already in the spec, but only includes AVPs defined in the base spec. Are you now proposing that the base include ALL AVPs defined in ALL extensions? (btw, the extension documents also have such a table). PatC From owner-aaa-bof@merit.edu Fri Mar 30 10:30:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20892 for ; Fri, 30 Mar 2001 10:30:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 878D25E051; Fri, 30 Mar 2001 09:58:14 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF8D05E105; Fri, 30 Mar 2001 09:58:04 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 359A55DF61 for ; Fri, 30 Mar 2001 09:55:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA23208; Fri, 30 Mar 2001 06:55:39 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09693; Fri, 30 Mar 2001 06:55:38 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA26472; Fri, 30 Mar 2001 06:55:35 -0800 (PST) Date: Fri, 30 Mar 2001 06:55:33 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Re: draft-ietf-aaa-diameter-01 / Stateless server To: Barney Wolff Cc: Patrice Calhoun , Bob Kopacz , Pat Calhoun , aaa-wg In-Reply-To: "Your message with ID" <20010330012635.A80035@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Ok, now I'm really confused. Back when we were debating stateful/ > stateless, I could have sworn we were talking about transaction > state, not session state. At least I was. Right, but the new failover text *requires* that transaction state be maintained. So I think the problem was that at the time we were discussing state vs. stateless, we didn't have the whole picture. > > Be that as it may, this language is confusing, as it seems to (but > cannot really) say that only a (session-)stateless proxy MUST maintain > transaction state. then I need to re-visit the text again. > > Also, what does the statefulness of a proxy or server have to do > with its ability to do protocol translation? And the paragraph > starts out talking about a stateful proxy but shifts to a server. because the implementor's guidelines discusses some RADIUS attributes (e.g. Class) which must be saved for future sessions. Of course, another alternative is to allow these RADIUS attributes to be encoded in an AVP, and this AVP MUST be present in future messages. This, however, is new protocol work, and we have decided to cut new features. > > > I have nothing against advice to implementors, but believe we go > too far when we use WORDS to express it. Again, read the failover text, and you will quickly see that mainaining transaction state is no longer a MAY :( PatC From owner-aaa-bof@merit.edu Fri Mar 30 10:49:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21824 for ; Fri, 30 Mar 2001 10:49:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 516B65DE32; Fri, 30 Mar 2001 10:45:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 37C915DE48; Fri, 30 Mar 2001 10:45:29 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D013F5DE32 for ; Fri, 30 Mar 2001 10:45:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA13793 for ; Fri, 30 Mar 2001 07:45:24 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27596 for ; Fri, 30 Mar 2001 07:45:22 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA26889 for ; Fri, 30 Mar 2001 07:45:21 -0800 (PST) Date: Fri, 30 Mar 2001 07:45:19 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: To recap the Vendor-ID stuff... To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I just need to make sure that I understand the desire of the WG. I currently have the DRI (in the -02 candidate) as: ::= < Diameter Header: 257 > { Origin-FQDN } { Origin-Realm } 1* { Host-IP-Address } { Vendor-Id } { Product-Name } * { Supported-Vendor-Id } * { Extension-Id } [ Firmware-Revision ] * [ AVP ] I have a couple of questions/comments: 1. What is the purpose of the Firmware-Revision if the Product-Name is there. The Product-Name is a string, and could include the version of the device. Is the Firmeware-Revision of any use? 2. I received plenty of comments that a Vendor-Id would be better than a Vendor-Name, as shown above. The initial objection was that this required that Diameter vendors apply for an SMI, which apparently is a trivial process. So, are there any objections? 3. As concensus shows, the Supported-Vendor-Id will be in the DRI. PatC From owner-aaa-bof@merit.edu Fri Mar 30 12:08:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26380 for ; Fri, 30 Mar 2001 12:08:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7914C5DE6C; Fri, 30 Mar 2001 12:07:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 642F15DE6F; Fri, 30 Mar 2001 12:07:33 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 4E1345DE6C for ; Fri, 30 Mar 2001 12:07:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20672; Fri, 30 Mar 2001 09:07:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05742; Fri, 30 Mar 2001 09:07:25 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA28207; Fri, 30 Mar 2001 09:07:21 -0800 (PST) Date: Fri, 30 Mar 2001 09:07:19 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: [diameter] Extension over base api as a separate process To: Yogesh.Solanki@nokia.com Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Does anybody have tried to implement extension(s) over base API. I have a > question, whether AAA Base protocol implementation and extension(s) have to > be in a single process or they can be separate processes. > > We are planning to implement extensions that will be separate processes from > AAA Diameter base implementation. And we would like to have some guidelines > from API specification. Sorry for the latency in my response... just starting to catch up now. It is possible to do both ways. I could envision a single process, or the following: +-----------------------+ -+ | Mobile IP Extension | | +-----------------------+ | +-----------------------+ +--- Process 1 | Diameter API/library | | +-----------------------+ -+ | | IPC Interface v +-----------------------+ -+ | AAA Daemon | +--- Process 2 +-----------------------+ -+ Again, the library was designed to support pretty much anything underneath, including a full blown Diameter implementation, or an IPC mechanism to the actual daemon. Hope this helps, PatC From owner-aaa-bof@merit.edu Fri Mar 30 12:23:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27110 for ; Fri, 30 Mar 2001 12:23:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67D815E0DE; Fri, 30 Mar 2001 12:18:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 52D465E075; Fri, 30 Mar 2001 12:18:34 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id D88205DFAD for ; Fri, 30 Mar 2001 12:18:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29788; Fri, 30 Mar 2001 09:18:30 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08548; Fri, 30 Mar 2001 09:18:29 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA28478; Fri, 30 Mar 2001 09:18:24 -0800 (PST) Date: Fri, 30 Mar 2001 09:18:21 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Base Session State Machine To: Fredrik Johansson Cc: AAA Listan In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > 1. I guess that this state applies to Session-Timeout Expires on FA as well. > > Open Session-Timeout Expires on send STR Discon > NAS > Suggestion: > Open Session-Timeout Expires on send STR Discon > access device I guess my NAS biases are now coming out :) I have changed NAS to Access Device. > 2. Is there a possible raise condition if the Session-Timeout in the NAS/FA > and the Session-Timeout in the home AAA server expires at the same time? The > AAA server will send a STI and go to disconnected when it receives the STR > from the NAS/FA it will disconnect and go to closed but it will never send a > STA, thus the NAS/FA will never receive a STA and will never go to closed. > Or is the STR only sent in response to a STI? If an STI is received, and STR MUST be sent. Therefore, the race condition here doesn't exist since the STR will be received. Furthermore, an STR MUST generate an STA, so again, no problem. PatC > > /Fredrik > > From owner-aaa-bof@merit.edu Fri Mar 30 12:33:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27818 for ; Fri, 30 Mar 2001 12:33:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 149555DF35; Fri, 30 Mar 2001 12:33:10 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 885615DF3C; Fri, 30 Mar 2001 12:33:03 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 06C095DF35 for ; Fri, 30 Mar 2001 12:32:59 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07678; Fri, 30 Mar 2001 09:32:52 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12023; Fri, 30 Mar 2001 09:32:50 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA28928; Fri, 30 Mar 2001 09:32:46 -0800 (PST) Date: Fri, 30 Mar 2001 09:32:43 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon To: Mark Jones Cc: David Spence , Pat Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <005901c0b18d$ee39e2d0$2096a8c0@mjones.bridgewatersys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Again, sorry for the latency. [command code renaming discussing deleted - I think it's a little late for this now, but I will let the WG decide] > Does the inclusion of an extension id in the DRI imply that the device > supports the functionality described in the extension using only the > commands and attributes defined in the extension, i.e. without addition of > any mandatory vendor-specific commands/attributes? yes > Would it be valid for a > device claiming support for the Mobile-IP extension to discard an AMA > command because it was missing a vendor-specific AVP that the device's > vendor considered mandatory? If a vendor wishes to do the above, then they will not interoperate with anyone, and may see limited market penetration. I don't think that the specs have anything to say about broken implementations. PatC From owner-aaa-bof@merit.edu Fri Mar 30 12:38:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28273 for ; Fri, 30 Mar 2001 12:38:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FDB25DF32; Fri, 30 Mar 2001 12:38:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E60A5DF19; Fri, 30 Mar 2001 12:38:06 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9BDB35DF18 for ; Fri, 30 Mar 2001 12:38:04 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA10097 for ; Fri, 30 Mar 2001 09:38:03 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13407 for ; Fri, 30 Mar 2001 09:38:03 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA29037 for ; Fri, 30 Mar 2001 09:37:59 -0800 (PST) Date: Fri, 30 Mar 2001 09:37:57 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: More on Filter-Rule and Mobile IP To: aaa-wg@merit.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Reading over the thread were we discussed where to put the Filter-Rule AVP, which will be required in the Mobile IP extension, I think that the following two were the most commonly supported approaches: 1. Simply cut and paste the Filter-Rule AVP from the NASREQ document to the Mobile IP, with the SAME AVP value. 2. Have the Mobile IP extension reference the NASREQ extension. Which of the two do people prefer? The former is a bit strange at first, but reduces code, number of AVPs. The latter requires that the developer read more specs to get the Mobile IP extension implemented (not that big of a deal). PatC From owner-aaa-bof@merit.edu Fri Mar 30 12:54:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29666 for ; Fri, 30 Mar 2001 12:54:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 23B685DFCD; Fri, 30 Mar 2001 12:52:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 112715DEA3; Fri, 30 Mar 2001 12:52:42 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 92E095DEEE for ; Fri, 30 Mar 2001 12:52:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18009; Fri, 30 Mar 2001 09:52:35 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16979; Fri, 30 Mar 2001 09:52:34 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA29378; Fri, 30 Mar 2001 09:52:24 -0800 (PST) Date: Fri, 30 Mar 2001 09:52:21 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: RE: [diameter] Diameter Issues found @ Connectathon To: Pat Calhoun Cc: Fredrik Johansson , aaa-wg@merit.edu, diameter@diameter.org, pcalhoun@eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > I beleive that we agreed on having the Home-Agent AVP mandatory in the AMA > > not the HAR (hopefully the HA will know its own address), but the diameter > > client in the FA should not be forced to parse the registration reply but > > should be able to find the HA address in the AMA. > > Agreed about the AMA, but it must also be in the HAR in cases where the HAR > is proxied (say in a visited network). I was trying to make this change, but I am not sure that making the Home-Agent AVP mandatory makes sense, since the AMA may indicate a failure, possibly by the AAAH, in which case there was never a Home Agent involved in the transaction. Therefore, I propose adding the following sentence to the AMA command code text: " A successful AMA message MUST include the MIP-Home-Agent-Address AVP." PatC From owner-aaa-bof@merit.edu Fri Mar 30 14:08:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05938 for ; Fri, 30 Mar 2001 14:08:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0DBD05DFBC; Fri, 30 Mar 2001 14:05:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E876F5DFBB; Fri, 30 Mar 2001 14:05:40 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8116D5DFAD for ; Fri, 30 Mar 2001 14:05:39 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00306; Fri, 30 Mar 2001 11:05:36 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18206; Fri, 30 Mar 2001 11:05:35 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA00704; Fri, 30 Mar 2001 11:05:24 -0800 (PST) Date: Fri, 30 Mar 2001 11:05:22 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEEE@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk First, thansk for the great comments. See my responses below. I will delete the items that were obvious errors, and do not need my response. > 1) I think that page 8 should be a new section about a Mobile Node moving to > a Foreign Network. I *could* but this is just another case of a Home Agent in a visited network, so I find it difficult to find a clean separation point. > > 4) Page 8, par.2, last sentence. I don't really understand what you mean > there. I guess you meant that Home Agent and the requesting Foreign Agent > are in different domain. The thing is that it is likely that the Home Agent > and the MIP-Previous-FA-FQDN were in the same domain at the last > registration, right? Of course, but this paragraph has to do with a third network. Is the scenario what's confusing you, or the text? > 6) Section 1.4, the second paragraph suggests to release the all resources > in the Home Diameter server upon the receipt of the STR from the Home Agent. > I guess it should be clear that the referred Home Agent is the "active" Home > Agent, since there might be 2 Home Agents at the same time while roaming. > During handoffs between different FAs in different domains, and let's say > that the Home Agent in the old Foreign domain can not be maintained there, > then a new Home Agent has to be started in the Home Domain or the new > Foreign domain and the AAAH needs to send a STI to the old Home Agent, which > replies with a STR. In that case, the Home Diameter should not release > resources, right? I think that I view multiple bindings (to home agents) are different Diameter sessions. Each would get their own Session-Id, and have their own separate session state. > > 12) Section 3.1, it it Hop-by-Hop Failures?, or Per-Hop Failures? Should all > those errors be sent through a DSI? > > 13) Section 3.1, just wondering, why error numbers are 6xxx series? Section 4 was introduced to define the DSI-Events. Error class 6 was temporarily added to identify error cases that require hop-by-hop processing, but this was later removed out of the base and replaced with the DSI, hence the new 4.0 section. > > 14) Section 4.6, A reference to Previous Foreign Agent Notification > Extension would be nice. What does this mean? You mean a Mobile IP extension? You have plenty of comments on section 5.1, which was a mess. My proposed cleaned up text is as following If the mobile node does not have a Mobile-Home registration key, then the AAAH is likely to be the only entity trusted that is available to the mobile node. Thus, the AAAH has to generate the Mobile-Home registration key, and encode it for eventual consumption by the mobile node and home agent. If the home agent is in the home domain, then AAAH can directly encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and include that AVP in the HAR message for delivery to the home agent. If, on the other hand, the home agent is to be allocated in the visited domain, the AAAH does not transmit the HAR to the home agent, but instead transmits the HAR to the AAAF. When the AAAF receives the HAR, it first allocates a home agent, and then issues the HAR for that home agent. The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAA server only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IP messages and extensions[4]. For this purpose, AAAH encodes the Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its security association with the mobile node, which is added to the HAR message, and delivered either to a local home agent, or to the AAAF in the case where the home agent is in the visited network. The AAAH has to rely on the home agent (that also understands Diameter) to transfer the key into a Mobile IP Generalized MN-HA Key Reply extension in the Registration Reply message. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the MIP-Reg-Reply AVP and added to the AHA. After the HAA message is parsed by the AAAH, and transformed into an AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually be received by the attendant (i.e., the foreign agent). The foreign agent can then use that AVP to recreate a Registration Reply message, containing the Generalized MN-HA Key Reply extension, for delivery to the mobile node. In summary, the AAAH generates the Mobile-Home registration key and encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. These AVPs are delivered to a home agent by including them in a HAR message sent from either AAAH or AAAF. The home agent decodes the key for its own use. The home agent also copies the encoded registration key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply extension appended to the Mobile IP Registration Reply message. This Registration Reply message MUST also include the Mobile-Home authentication extension, created using the newly allocated Mobile-Home registration key. The home agent then encodes the Registration Reply message and extensions into a MIP-Reg-Reply AVP included as part of the HAA message to be sent back to the AAA server. You also had many comments on section 5.2, which has now been greatly simplified to: The Mobile-Foreign registration key is also generated by AAAH (upon request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, which is added to the HAR, and copied by the home agent into a Generalized MN-FA Key Reply Extension [15] to the Mobile IP Registration Reply message. Most of the considerations for distributing the Mobile-Foreign registration key are similar to the distribution of the Mobile-Home Registration Key. If the MIP-FA-to-MN-Key AVP is present in the HAR, the home agent MUST ensure that the same AVP is present in the AHA. The AAAH MUST ensure that this AVP is present in the AMA, which is sent to the foreign agent. Similarly, section 5.3 was greatly simplified to: If the home agent is in the home domain, then AAAH has to generate the Foreign-Home registration key. Otherwise, it is generated by AAAF. In either case, the AAA server encodes the registration key into a MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message sent to the home agent, and waits for the HAA message to be returned. If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST be present in the corresponding AHA, which is eventually transformed by the AAAH into an AMA message that is transmitted back to the foreign agent. Upon receipt of the AMA, the foreign agent recovers the Foreign-Home registration key, and uses this key to create a Mobile-Foreign authentication extension to the Registration Reply message. > 27) Section 2.1, why is the Session-ID is required with {}, but not with > [], like in other messages? As per the base protocol, the Session-ID is ALWAYS mandatory to be present. > > 28) Section 2.1, why the "Authorization-Lifetime" required? hmmmm.... I suppose it shouldn't really be mandatory, but could be present as a recommendation from the Foreign Agent, or AAAF. > > 29) I am wondering why the Destination-Realm AVP is required in Answer > messages? hmmmm.... noit quite sure, but it doesn't seem to hurt :) > 32) In the case where a mobile node handoffs to a different FA within the > same administrative domain, is it required to reach the Home server with the > AMR?, or can it be handled in the AAAF? It might be interesting to show this > scenario, right? Why would the AAA server even need to be contacted? PatC From owner-aaa-bof@merit.edu Fri Mar 30 14:25:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07401 for ; Fri, 30 Mar 2001 14:25:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E7785DE11; Fri, 30 Mar 2001 14:24:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C8B45DE08; Fri, 30 Mar 2001 14:24:53 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3DB175DE01 for ; Fri, 30 Mar 2001 14:24:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07943; Fri, 30 Mar 2001 11:24:49 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23000; Fri, 30 Mar 2001 11:24:49 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA01214; Fri, 30 Mar 2001 11:24:44 -0800 (PST) Date: Fri, 30 Mar 2001 11:24:42 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt To: Patrice Calhoun Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk one more thing. > > > > 28) Section 2.1, why the "Authorization-Lifetime" required? > > hmmmm.... I suppose it shouldn't really be mandatory, but could be present as > a recommendation from the Foreign Agent, or AAAF. Looking over the connectathon comments, this was an issue and has since been corrected. The AVP is optional in the HAR. PatC From owner-aaa-bof@merit.edu Fri Mar 30 14:26:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07475 for ; Fri, 30 Mar 2001 14:26:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B0D95DE1E; Fri, 30 Mar 2001 14:25:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EDCDA5DE08; Fri, 30 Mar 2001 14:25:51 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D2E845DE01 for ; Fri, 30 Mar 2001 14:25:50 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 26DE972; Fri, 30 Mar 2001 14:26:07 -0500 (EST) Message-ID: <3AC3B997.F3E5093E@Interlinknetworks.com> Date: Thu, 29 Mar 2001 14:39:19 -0800 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mark Jones Cc: IETF AAA WG Subject: Re: [AAA-WG]: Vendor-Name in DRI References: <000d01c0b6d1$b67b2e00$2096a8c0@mjones.bridgewatersys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I agree. Mark Jones wrote: > > I understand that the new DRI format is: > > ::= < Diameter Header: 257 > > { Origin-FQDN } > { Origin-Realm } > 1* { Host-IP-Address } > { Vendor-Name } > * { Extension-Id } > [ Firmware-Revision ] > * { Supported-Vendor-Id } > * [ AVP ] > 0*1< Integrity-Check-Value > > > I am repeating my request to keep the device Vendor-Id in this message > instead of the Vendor-Name AVP. If the DRI is meant to eliminate a > configuration file mapping peer IP Address to Vendor then a well-known > integer is more machine-friendly than the free-format Vendor-Name string > which SHOULD contain the vendor name and/or product name. > > I understand this change was made following objections from Diameter > implementors at Connectathon to having to obtain a Private Enterprise Code > from IANA solely for this purpose. This strikes me as a somewhat lame excuse > given how easy it is to obtain such a code (goto > http://www.iana.org/cgi-bin/enterprise.pl, fill in the form, hit submit, > wait one week). Were there other issues with obtaining a Private Enterprise > Code for this purpose (inappropriate use...)? > > I know that the Vendor-Id with Firmware-Revision does not fully identify the > device so a Product-Id (or Product-Name) is still required in the DRI. And I > have absolutely no objections to vendors issuing this Id/Name rather than > IANA :) > > Regards, > Mark -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Fri Mar 30 14:38:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08364 for ; Fri, 30 Mar 2001 14:38:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id AC7915DE56; Fri, 30 Mar 2001 14:35:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 916B25DEDE; Fri, 30 Mar 2001 14:35:21 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 27D595DEA3 for ; Fri, 30 Mar 2001 14:35:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24618; Fri, 30 Mar 2001 11:35:17 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25391; Fri, 30 Mar 2001 11:35:16 -0800 (PST) Received: from darius (darius [10.6.84.105]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA01609; Fri, 30 Mar 2001 11:35:09 -0800 (PST) Date: Fri, 30 Mar 2001 11:35:02 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: AAA Registration Keys for Mobile IP? To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" , "'pcalhoun@eng.sun.com'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FF0E@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > From reading the "AAA Registration Keys for Mobile IP" document > (draft-ietf-mobileip-aaa-key-04.txt), I was wondering if you could help me > understand the sections 6 and 7? The thing is that I don't see exactly what > they can be used for. For example, is the MN-FA Key Request (section 6) sent > in the MIP Registration Request in order to suggest a SPI between the MN and > the FA? Then, I guess that the FA can suggest it to the AAAH in the AMR > using the MIP-FA-MN-Preferred-SPI AVP, right? Correct, the MN can "suggest" a value, and the FA has the option to overwrite that value. Sure, a possible collision could occur, but that's life :( > I guess the FA can also > suggest a SPI between the FA and the HA using the MIP-FA-HA-Preferred-SPI > AVP, right? Right, if the FA likes the "suggested" value from the MN, then it would set the same value in the AVP. Otherwise, it puts its own preferred value. > However, if the MN sends a MN-HA Key Request (section 7) > including a preferred SPI to be used between the MN and the HA, how can it > be sent to the AAAH? It does not seem to exist any AVP for that in the > Diameter Mobile-IP protocol. Can that subtype be used at all within the AAA > infrastucture meaningfully? hmmmm.... it doesn't appear to be used in Diameter. I am at a bit of a loss. So, we can either create a new AVP, if we believe this is useful, or eliminate the field from the Mobile IP extension. > > Also, note that in section 7, it is referred to the foreign agent instead of > the Home Agent??? yup, just caught that as I was reading over section 7. PatC From owner-aaa-bof@merit.edu Fri Mar 30 16:19:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15104 for ; Fri, 30 Mar 2001 16:19:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id DCB725DDCB; Fri, 30 Mar 2001 16:15:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7765D5DDF5; Fri, 30 Mar 2001 16:15:24 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 8EC005DDCB for ; Fri, 30 Mar 2001 16:15:17 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA07909; Fri, 30 Mar 2001 17:11:35 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA23249; Fri, 30 Mar 2001 16:15:54 -0500 (EST) From: "Mark Jones" To: "Patrice Calhoun" , Subject: RE: [AAA-WG]: To recap the Vendor-ID stuff... Date: Fri, 30 Mar 2001 16:16:47 -0500 Message-ID: <004001c0b95e$ba7184c0$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > 1. What is the purpose of the Firmware-Revision if the > Product-Name is there. > The Product-Name is a string, and could include the version of > the device. Is > the Firmeware-Revision of any use? > Yes, I think the Firmware-Revision should remain a separate AVP. I believe these Vendor/Product/Firmware AVPs will be used by Diameter servers to lookup the vendor-specific capabilities/idiosyncrasies of a peer and so machine-friendly is key here. If the Firmware-Revision is added to the Product-Name, it now has to be parsed by a server that is only interested in the Product-Name. Regards, Mark From owner-aaa-bof@merit.edu Fri Mar 30 17:28:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17849 for ; Fri, 30 Mar 2001 17:28:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEF3C5DE59; Fri, 30 Mar 2001 17:28:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 82CCD5DE54; Fri, 30 Mar 2001 17:28:02 -0500 (EST) Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9]) by segue.merit.edu (Postfix) with ESMTP id 012F25E049 for ; Fri, 30 Mar 2001 17:27:48 -0500 (EST) Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2]) by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id SAA08391; Fri, 30 Mar 2001 18:24:03 -0500 Received: from mjones (mjones.bridgewatersys.com [192.168.150.32]) by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id RAA25013; Fri, 30 Mar 2001 17:28:22 -0500 (EST) From: "Mark Jones" To: "Patrice Calhoun" Cc: "David Spence" , , Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon Date: Fri, 30 Mar 2001 17:29:15 -0500 Message-ID: <004401c0b968$d9f25a90$2096a8c0@mjones.bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > [command code renaming discussing deleted - I think it's a little late for > this now, but I will let the WG decide] > I should have spotted this earlier but I honestly thought the Device-Reboot-Indication was only sent on device reboot until I re-read the description much later. The proposal was to rename the Device-Reboot-Indication command to Device-Capability-Indication since the command is sent on session establishment and not necessarily device reboot. > > Does the inclusion of an extension id in the DRI imply that the device > > supports the functionality described in the extension using only the > > commands and attributes defined in the extension, i.e. without > addition of > > any mandatory vendor-specific commands/attributes? > > yes > It seems obvious to me too but I see a loophole in the current drafts since the command specification in the extension documents contain "* [ AVP ]" to indicate that any other AVP may be present (including a mandatory vendor-specific AVP). I dislike conformance battles with other vendors so how about adding the following text to the Extension-Id AVP description to keep us honest: "A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support the functionality described in the associated extension using only the commands defined in the extension and without the addition of mandatory vendor-specific AVPs." Too severe? This text may ensure that Diameters peers never receive a DRI with an Extension-Id AVP :) Regards, Mark From owner-aaa-bof@merit.edu Sat Mar 31 05:23:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19776 for ; Sat, 31 Mar 2001 05:23:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 016995DDF2; Sat, 31 Mar 2001 05:23:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA3035DDF3; Sat, 31 Mar 2001 05:23:40 -0500 (EST) Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 6D79E5DDF2 for ; Sat, 31 Mar 2001 05:23:38 -0500 (EST) Received: from fredrikj (sparcis.local.ipunplugged.com [192.168.4.51]) by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA01689; Sat, 31 Mar 2001 12:23:12 +0200 From: "Fredrik Johansson" To: "Patrice Calhoun" Cc: , , Subject: [AAA-WG]: RE: [diameter] Diameter Issues found @ Connectathon Date: Sat, 31 Mar 2001 12:25:31 +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 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit That will do, /Fredrik >-----Original Message----- >From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] >Sent: den 30 mars 2001 19:52 >To: Pat Calhoun >Cc: Fredrik Johansson; aaa-wg@merit.edu; diameter@diameter.org; >pcalhoun@eng.sun.com >Subject: RE: [diameter] Diameter Issues found @ Connectathon > > >> > I beleive that we agreed on having the Home-Agent AVP >mandatory in the AMA >> > not the HAR (hopefully the HA will know its own address), but >the diameter >> > client in the FA should not be forced to parse the >registration reply but >> > should be able to find the HA address in the AMA. >> >> Agreed about the AMA, but it must also be in the HAR in cases >where the HAR >> is proxied (say in a visited network). > >I was trying to make this change, but I am not sure that making >the Home-Agent >AVP mandatory makes sense, since the AMA may indicate a failure, >possibly by >the AAAH, in which case there was never a Home Agent involved in the >transaction. > >Therefore, I propose adding the following sentence to the AMA command code >text: > >" A successful AMA message MUST include the MIP-Home-Agent-Address AVP." > >PatC