From owner-aaa-bof@merit.edu Mon Apr 3 14:03:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA17067 for ; Mon, 3 Apr 2000 14:03:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 358B25DDBD; Mon, 3 Apr 2000 14:00:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 244F45DD8F; Mon, 3 Apr 2000 14:00:41 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id ACF2A5DD8E for ; Mon, 3 Apr 2000 14:00:35 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id KAA27452 for ; Mon, 3 Apr 2000 10:48:04 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: Presentations Date: Mon, 3 Apr 2000 11:03:09 -0700 Message-ID: <010601bf9d96$df6cadc0$268939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk If you made a presentation at AAA WG in Adelaide, please mail a copy of it to the chairs. From owner-aaa-bof@merit.edu Mon Apr 3 17:33:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20031 for ; Mon, 3 Apr 2000 17:33:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 935CD5DDA8; Mon, 3 Apr 2000 17:30:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 81FA55DD99; Mon, 3 Apr 2000 17:30:22 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id EC4535DD8E for ; Mon, 3 Apr 2000 17:30:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA04425 for ; Mon, 3 Apr 2000 15:30:16 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.105.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id OAA03831; Mon, 3 Apr 2000 14:30:02 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14311; Mon, 3 Apr 2000 14:28:42 -0700 Date: Mon, 3 Apr 2000 14:28:35 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Question about NA Requirements 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, I have a question about the "Precludes Layer 2 Tunneling" requirement. My dictionary defines precludes as: "To make impossible, as by action taken in advance; prevent." Am I to take this as the AAA protocol CANNOT allow layer 2 tunnels (e.g. L2TP) to be created? I would assume that this directly violates the NASREQ requirement, and I believe that Precludes is simply the wrong term to be used here. Comments? PatC From owner-aaa-bof@merit.edu Mon Apr 3 17:42:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA20095 for ; Mon, 3 Apr 2000 17:42:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6BF1B5DDC9; Mon, 3 Apr 2000 17:42:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5BA1E5DD8E; Mon, 3 Apr 2000 17:42:38 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id 735655DDB4 for ; Mon, 3 Apr 2000 17:42:37 -0400 (EDT) Received: from 192.168.1.17 ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JNT33JK2848ZE1Z0@shoe.reston.mci.net> for aaa-wg@merit.edu; Mon, 3 Apr 2000 17:42:36 EST Date: Tue, 04 Apr 2000 09:42:31 +1200 From: Paul Krumviede Subject: Re: Question about NA Requirements In-reply-to: To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com Message-id: <1358612228.954841351@[192.168.1.17]> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk doesn't the matrix show "N" for this, as in must not preclude layer 2 tunneling? we can debate the merits of double negatives, though... -paul --On Monday, 03 April, 2000 14:28 -0700 "pcalhoun@eng.sun.com" wrote: > All, > > I have a question about the "Precludes Layer 2 Tunneling" requirement. My > dictionary defines precludes as: "To make impossible, as by action taken > in advance; prevent." > > Am I to take this as the AAA protocol CANNOT allow layer 2 tunnels (e.g. > L2TP) to be created? I would assume that this directly violates the > NASREQ requirement, and I believe that Precludes is simply the wrong > term to be used here. > > Comments? > > PatC > > From owner-aaa-bof@merit.edu Mon Apr 3 18:42:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20782 for ; Mon, 3 Apr 2000 18:42:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AC4BF5DDA8; Mon, 3 Apr 2000 18:42:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99D605DDA3; Mon, 3 Apr 2000 18:42:05 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 17FF95DD8E for ; Mon, 3 Apr 2000 18:42:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24974 for ; Mon, 3 Apr 2000 16:42:03 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.93.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id PAA08474; Mon, 3 Apr 2000 15:42:02 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA17204; Mon, 3 Apr 2000 15:42:01 -0700 Date: Mon, 3 Apr 2000 15:42:00 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: State Reconciliation Requirement 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 The current AAA Network Access Requirements defines the following requirement, State Reconciliation, as: "This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling. The design must provide for recovery from data loss during NAS/AAA server communication outages." I would like to raise an objection on this point, and the same objection that I raised in the NASREQ mailing list. The chairs did make it clear that they agreed that this requirement, in a large network, doesn't work well. Further, this requirement conflicts with the "Scaling" requirement also in the document. 4 years (at least) ago, I started working on such a feature in what was then RADIUS v2. The feature in question was Resource Management. This work was implemented in a specific Access Router, and the Merit Server code. We did conduct some tests, and although it did work, it REALLY isn't clear what happens in an inter domain case. Let's take an example, a AAA server crashes. The AAA, upon reboot, has to inform all of it's peers of the reboot, which can be done. The difficult comes with the receivers. They would then have to propagate the reboot info down to all of their peers, until it reaches a NAS. Furthermore, one has to implement a loopback protection, to ensure that a highly resilient network doesn't have these reboot messages going around in circles ad infinitum. This is a REAL hard problem, and one that I am not sure we necessarily want to embark on. Don't get me wrong, this isn't about a protocol that can't do it. I have one that does, the issue comes with complexity, and whether this feature is important enough that the complexity is justified. Now, DIAMETER *does* fulfil part of this requirement, and I will explain how. When a user is authentication/authorized, a session lifetime is returned. The Access Router MUST re-authenticate/authorize the user before the lifetime expires. This ensures that an AAA server that looses state can regain the state after some period. It isn't perfect, but it scales a hell of alot better than the above. If this type of functionality is adequate, I would rephrase the requirement to be: "This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling." What do people think? Should we embark on a dangerous road, or take the simpler approach? If we REALLY want to do the former, I would argue that it requires alot of research and further work, and perhaps this could be included in our charter. PatC From owner-aaa-bof@merit.edu Mon Apr 3 19:33:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA21303 for ; Mon, 3 Apr 2000 19:33:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D8FB05DD8E; Mon, 3 Apr 2000 19:31:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C34865DDB1; Mon, 3 Apr 2000 19:31:02 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id AC5B15DD8E for ; Mon, 3 Apr 2000 19:31:01 -0400 (EDT) Received: from 192.168.1.17 ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JNT6VXT23E8ZE1Z0@shoe.reston.mci.net> for aaa-wg@merit.edu; Mon, 3 Apr 2000 19:31:00 EST Date: Tue, 04 Apr 2000 11:30:56 +1200 From: Paul Krumviede Subject: Re: State Reconciliation Requirement In-reply-to: To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com Message-id: <1365116448.954847856@[192.168.1.17]> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk --On Monday, 03 April, 2000 15:42 -0700 "pcalhoun@eng.sun.com" wrote: > The current AAA Network Access Requirements defines the following > requirement, State Reconciliation, as: > > "This requirement refers to the ability of the NAS to use the AAA server > to manage resource allocation state. This capability can assist with, > but it is not synonymous with, simultaneous user login control, port > usage limitations, or IP address pooling. The design must > provide for recovery from data loss during NAS/AAA server > communication outages." > > I would like to raise an objection on this point, and the same objection > that I raised in the NASREQ mailing list. The chairs did make it clear > that they agreed that this requirement, in a large network, doesn't work > well. Further, this requirement conflicts with the "Scaling" requirement > also in the document. 4 years (at least) ago, I started working on such > a feature in what was then RADIUS v2. The feature in question was > Resource Management. This work was implemented in a specific Access > Router, and the Merit Server code. We did conduct some tests, and > although it did work, it REALLY isn't clear what happens in an inter > domain case. As implemented in one network of which I know, it doesn't work well in at least some intra-domain cases. I should mention that it is questionable whether the problems seen were implementation issues or more fundamental problems. But this may be only one way of approaching the problem. At least in theory, one can view a set of AAA servers as front-ends to a distributed database, and use such a database service to provide some of the glue for state or resource management. This can be viewed as simply moving the scaling problem into a different layer, but it cna avoid some complexity within a AAA protocol (or set of protocols) and keep it out of a AAA server. > Let's take an example, a AAA server crashes. The AAA, upon reboot, has to > inform all of it's peers of the reboot, which can be done. The difficult > comes with the receivers. They would then have to propagate the reboot > info down to all of their peers, until it reaches a NAS. Furthermore, > one has to implement a loopback protection, to ensure that a highly > resilient network doesn't have these reboot messages going around in > circles ad infinitum. This could be viewed as analogous to what routing protocols have to do, and there (apparently) working protocols and implementations to handle flooding in a fashion that terminates. Lets not re-invent things we don't need to. > This is a REAL hard problem, and one that I am not sure we necessarily > want to embark on. Don't get me wrong, this isn't about a protocol that > can't do it. I have one that does, the issue comes with complexity, and > whether this feature is important enough that the complexity is > justified. > > Now, DIAMETER *does* fulfil part of this requirement, and I will explain > how. When a user is authentication/authorized, a session lifetime is > returned. The Access Router MUST re-authenticate/authorize the user > before the lifetime expires. This ensures that an AAA server that looses > state can regain the state after some period. It isn't perfect, but it > scales a hell of alot better than the above. I'm not sure this suffices. Consider the case where there is a network partition such that some AAA servers can't communicate with others. Then servers have to timeout resources/state information maintained by other, now unreachable, servers, but there is a risk of resource depletion in the meantime. I'm not claiming that I know of a good solution to this, and solving the general problem is out of scope for this WG. > If this type of functionality is adequate, I would rephrase the > requirement to be: > > "This requirement refers to the ability of the NAS to use the AAA server > to manage resource allocation state. This capability can assist with, > but it is not synonymous with, simultaneous user login control, port > usage limitations, or IP address pooling." > > What do people think? Should we embark on a dangerous road, or take the > simpler approach? If we REALLY want to do the former, I would argue that > it requires alot of research and further work, and perhaps this could be > included in our charter. I assume that attempting to add research to a new charter will fail. But perhaps the deeper question to be considered is whether or not this is something that should be solved within one or more AAA protocols; a variant of this would be what features can assist implementors to build a system to address this (i.e., not assume that a AAA server implementation has to solve this itself). -paul From owner-aaa-bof@merit.edu Mon Apr 3 20:40:28 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA21977 for ; Mon, 3 Apr 2000 20:40:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A1875DD99; Mon, 3 Apr 2000 20:40:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 559FB5DDA3; Mon, 3 Apr 2000 20:40:07 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 27B185DD99 for ; Mon, 3 Apr 2000 20:40:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA08667 for ; Mon, 3 Apr 2000 18:40:04 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.93.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id RAA03524 for ; Mon, 3 Apr 2000 17:40:03 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA20431; Mon, 3 Apr 2000 17:40:03 -0700 Date: Mon, 3 Apr 2000 17:40:03 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Points raised by Tom Hiller at IETF 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 am trying to figure out what to do with the issues that were raised by Tom Hiller, that had to do with the mis-representation of the TR45.6 requirements in the NA reqs doc. In combining the Mobile IP and the TR45.6 requirements, there were a few mis-matches. In most cases, TR45.6 had a Must 'M', and Mobile IP had a SHOULD. In these cases, either NASREQ or ROAMOPS had a Must 'M', which ensured that the AAA protocol would get this feature. In the cases where TR45.6 had a different requirement than Mobile IP, and no other application had the same level as TR45.6, I have two symbols in the table under Mobile IP. See (shared secret not required) requirement as an example. The question I have for the group is whether we should leave the document as-is, or change them to include both requirement labels under Mobile IP when needed (which I prefer NOT to do). PatC From owner-aaa-bof@merit.edu Mon Apr 3 23:19:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA23706 for ; Mon, 3 Apr 2000 23:19:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 270F65DDBD; Mon, 3 Apr 2000 23:19:03 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 162695DDBC; Mon, 3 Apr 2000 23:19:03 -0400 (EDT) Received: from smtpgw2.sprintspectrum.com (smtpgw2.sprintspectrum.com [208.18.119.43]) by segue.merit.edu (Postfix) with ESMTP id CA3555DDB4 for ; Mon, 3 Apr 2000 23:19:01 -0400 (EDT) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id WAA08348; Mon, 3 Apr 2000 22:18:51 -0500 (CDT) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id <2ADVS8XW>; Mon, 3 Apr 2000 22:19:25 -0500 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88E57B1D@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu Subject: RE: Question about NA Requirements Date: Mon, 3 Apr 2000 22:18:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I don't believe that would be a good thing since there are L2TP services out there now for simple IP and we must continue to support our customers. If this is not a typo then we need to correct it, because it does not represent my needs not those of TR45.6. Thanks -----Original Message----- From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM] Sent: Monday, April 03, 2000 4:29 PM To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com Subject: Question about NA Requirements All, I have a question about the "Precludes Layer 2 Tunneling" requirement. My dictionary defines precludes as: "To make impossible, as by action taken in advance; prevent." Am I to take this as the AAA protocol CANNOT allow layer 2 tunnels (e.g. L2TP) to be created? I would assume that this directly violates the NASREQ requirement, and I believe that Precludes is simply the wrong term to be used here. Comments? PatC From owner-aaa-bof@merit.edu Mon Apr 3 23:32:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA23958 for ; Mon, 3 Apr 2000 23:32:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 267EA5DDB4; Mon, 3 Apr 2000 23:30:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11A765DDBC; Mon, 3 Apr 2000 23:30:22 -0400 (EDT) Received: from smtpgw1.sprintspectrum.com (smtpgw1.sprintspectrum.com [208.18.119.44]) by segue.merit.edu (Postfix) with ESMTP id 159675DDB4 for ; Mon, 3 Apr 2000 23:30:20 -0400 (EDT) Received: from pkcex003.sprintspectrum.com (pkcex003.sprintspectrum.com [208.10.75.138]) by smtpgw1.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id WAA28750; Mon, 3 Apr 2000 22:30:18 -0500 (CDT) Received: by pkcex003.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id <2ADGBXHG>; Mon, 3 Apr 2000 22:29:27 -0500 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC883A134B@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'pcalhoun@eng.sun.com'" , aaa-wg@merit.edu Subject: RE: Points raised by Tom Hiller at IETF Date: Mon, 3 Apr 2000 22:29:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I spoke with Tom after the meeting and I recommend adding a few simply notes on the items in question that TR45.6 has a different position then mobileip. This solves the issue of only noting those changes and we can move it forward quickly. I even thought Tom was going to supply the wording, but I believe he is still on a walk about! -----Original Message----- From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM] Sent: Monday, April 03, 2000 7:40 PM To: aaa-wg@merit.edu Subject: Points raised by Tom Hiller at IETF All, I am trying to figure out what to do with the issues that were raised by Tom Hiller, that had to do with the mis-representation of the TR45.6 requirements in the NA reqs doc. In combining the Mobile IP and the TR45.6 requirements, there were a few mis-matches. In most cases, TR45.6 had a Must 'M', and Mobile IP had a SHOULD. In these cases, either NASREQ or ROAMOPS had a Must 'M', which ensured that the AAA protocol would get this feature. In the cases where TR45.6 had a different requirement than Mobile IP, and no other application had the same level as TR45.6, I have two symbols in the table under Mobile IP. See (shared secret not required) requirement as an example. The question I have for the group is whether we should leave the document as-is, or change them to include both requirement labels under Mobile IP when needed (which I prefer NOT to do). PatC From owner-aaa-bof@merit.edu Tue Apr 4 08:14:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA29745 for ; Tue, 4 Apr 2000 08:14:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 939B55DDE5; Tue, 4 Apr 2000 08:14:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 797095DDE7; Tue, 4 Apr 2000 08:14:04 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 0CE3D5DDE5 for ; Tue, 4 Apr 2000 08:14:00 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id FAA28495; Tue, 4 Apr 2000 05:00:59 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Lipford, Mark'" , "'pcalhoun@eng.sun.com'" , Subject: RE: Question about NA Requirements Date: Tue, 4 Apr 2000 05:16:08 -0700 Message-ID: <012901bf9e2f$8fa94570$268939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2D11BCC7FFD8D3118FD70000D1ECDC88E57B1D@pkcexv018.sprintspectrum.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Actually the requirement was NOT to preclude layer 2 tunneling. -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Lipford, Mark Sent: Monday, April 03, 2000 8:19 PM To: pcalhoun@eng.sun.com; aaa-wg@merit.edu Subject: RE: Question about NA Requirements I don't believe that would be a good thing since there are L2TP services out there now for simple IP and we must continue to support our customers. If this is not a typo then we need to correct it, because it does not represent my needs not those of TR45.6. Thanks -----Original Message----- From: pcalhoun@eng.sun.com [mailto:pcalhoun@ha1mpk-mail.Eng.Sun.COM] Sent: Monday, April 03, 2000 4:29 PM To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com Subject: Question about NA Requirements All, I have a question about the "Precludes Layer 2 Tunneling" requirement. My dictionary defines precludes as: "To make impossible, as by action taken in advance; prevent." Am I to take this as the AAA protocol CANNOT allow layer 2 tunnels (e.g. L2TP) to be created? I would assume that this directly violates the NASREQ requirement, and I believe that Precludes is simply the wrong term to be used here. Comments? PatC From owner-aaa-bof@merit.edu Tue Apr 4 08:52:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id IAA00150 for ; Tue, 4 Apr 2000 08:52:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B3C835DDD7; Tue, 4 Apr 2000 08:51:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 979645DDDD; Tue, 4 Apr 2000 08:51:32 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 414E85DDBC for ; Tue, 4 Apr 2000 08:51:27 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id FAA28525; Tue, 4 Apr 2000 05:38:43 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Paul Krumviede'" , Cc: Subject: RE: State Reconciliation Requirement Date: Tue, 4 Apr 2000 05:53:50 -0700 Message-ID: <012c01bf9e34$d4503ee0$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <1365116448.954847856@[192.168.1.17]> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >As implemented in one network of which I know, it doesn't work >well in at least some intra-domain cases. I should mention that it >is questionable whether the problems seen were implementation >issues or more fundamental problems. I wonder whether we are thinking about the same network :) In my experience the problems resulted from issues relating to accounting transport. Without transport layer reliability it is possible to lose accounting STOP packets. Without app-layer reliability it is possible that accounting STOP packets will be lost as a result of an accounting server failure. Without non-volatile storage it is possible to lose accounting records due to NAS reboots, or network partitions. If these issues are addressed then it is possible to restore state consistency within a minimum period of time after connectivity is restored. In polling systems the time to detect connectivity loss is equal to a multiple of the polling interval; that is, if the NAS did not answer several polls its session state can be timed out. If the problem was due to a network partition then when the partition is cleared the inconsistency can be resolved by the next poll (assuming that the poll provides a complete update on the NASes current state). In event-driven systems the time to failure detection is a multiple of the Interim accounting interval, which is typically much longer. This can create problems. One way to improve the situation in event-driven systems is to impose a minimum "keep-alive" time period, in which an accounting packet of some kind (even if only an empty packet) needs to be sent by the NAS. Since the "keep alive" only needs to be sent if the NAS isn't busy, it doesn't add much overhead but it does allow connectivity loss to be detected quickly. Again, if the connectivity loss was due to network partition rather than a NAS crash then when connectivity is restored, state can be retrieved by completing transmission of the stored but untransmitted accounting records. >But this may be only one way of approaching the problem. At >least in theory, one can view a set of AAA servers as front-ends >to a distributed database, and use such a database service to >provide some of the glue for state or resource management. Indeed this is how resource management is often implemented. > Let's take an example, a AAA server crashes. The AAA, upon reboot, has to > inform all of it's peers of the reboot, which can be done. Question: why is this necessary? Are we assuming that the AAA server does not save its state to stable storage? My understanding of "app layer reliability" is that "taking responsibility" implies that the packet has been processed so that the information will not be lost if the AAA server crashes. >But perhaps the deeper question to be considered is whether or not this is >something that should be solved within one or more AAA protocols; >a variant of this would be what features can assist implementors to >build a system to address this (i.e., not assume that a AAA server >implementation has to solve this itself). Indeed. To look at it from another perspective: some portions of this problem are solved by improved reliability, some need to be addressed by other protocol improvements and some may not need to be addressed by the protocol at all. From owner-aaa-bof@merit.edu Tue Apr 4 10:33:38 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01589 for ; Tue, 4 Apr 2000 10:33:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 269785DE2C; Tue, 4 Apr 2000 10:30:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B92CB5DE24; Tue, 4 Apr 2000 10:30:16 -0400 (EDT) Received: from drawbridge.ascend.com (drawbridge.ascend.com [198.4.92.1]) by segue.merit.edu (Postfix) with ESMTP id 6F4DA5DE14 for ; Tue, 4 Apr 2000 10:30:11 -0400 (EDT) Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id HAA05145; Tue, 4 Apr 2000 07:23:29 -0700 (PDT) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 4 Apr 2000 14:30:06 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id HAA22880; Tue, 4 Apr 2000 07:30:04 -0700 (PDT) Received: from ascend.com by ascend.com Message-Id: <4.2.2.20000404072835.00b6acb0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 04 Apr 2000 07:29:53 -0700 To: "pcalhoun@eng.sun.com" From: Matt Holdrege Subject: Re: State Reconciliation Requirement Cc: aaa-wg@merit.edu In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk At 03:42 PM 4/3/00 -0700, pcalhoun@eng.sun.com wrote: >I would like to raise an objection on this point, and the same objection that >I raised in the NASREQ mailing list. The chairs did make it clear that they >agreed that this requirement, in a large network, doesn't work well. Further, >this requirement conflicts with the "Scaling" requirement also in the >document. > 4 years (at least) ago, I started working on such a feature in what was then >RADIUS v2. The feature in question was Resource Management. This work was >implemented in a specific Access Router, and the Merit Server code. We did >conduct some tests, and although it did work, it REALLY isn't clear what >happens in an inter domain case. Yes there are scenarios where these things don't work just as there are scenarios where they work fine. Since it can work and people use it, it should stay in the requirements. But if you want to put in some qualifiers, that would be helpful. From owner-aaa-bof@merit.edu Tue Apr 4 10:49:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01823 for ; Tue, 4 Apr 2000 10:49:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4CB105DE08; Tue, 4 Apr 2000 10:48:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B5CE5DE03; Tue, 4 Apr 2000 10:48:08 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 59A785DDF4 for ; Tue, 4 Apr 2000 10:48:05 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27577; Tue, 4 Apr 2000 08:46:41 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.61.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA06961; Tue, 4 Apr 2000 07:46:20 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA28360; Tue, 4 Apr 2000 07:46:18 -0700 Date: Tue, 4 Apr 2000 07:46:18 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: State Reconciliation Requirement To: Matt Holdrege Cc: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <4.2.2.20000404072835.00b6acb0@porky> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > At 03:42 PM 4/3/00 -0700, pcalhoun@eng.sun.com wrote: > >I would like to raise an objection on this point, and the same objection > that >I raised in the NASREQ mailing list. The chairs did make it clear that > they >agreed that this requirement, in a large network, doesn't work well. > Further, >this requirement conflicts with the "Scaling" requirement also in > the >document. > > 4 years (at least) ago, I started working on such a feature in what was then > >RADIUS v2. The feature in question was Resource Management. This work was > >implemented in a specific Access Router, and the Merit Server code. We did > >conduct some tests, and although it did work, it REALLY isn't clear what > >happens in an inter domain case. > > Yes there are scenarios where these things don't work just as there are > scenarios where they work fine. Since it can work and people use it, it > should stay in the requirements. But if you want to put in some qualifiers, > that would be helpful. > Exactly, there are some that do work, and we need one of those. So, could we change the requirement to state that we need something that provides: 1. transport level reliability, and 2. a reliable disconnect message, and 3. some periodic update message Do the three above provide what we need? If so, then we can simplify the requirement, since what we currently have does imply some sort of AAA distributed database. PatC From owner-aaa-bof@merit.edu Tue Apr 4 10:52:24 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA01851 for ; Tue, 4 Apr 2000 10:52:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 246A55DDDD; Tue, 4 Apr 2000 10:52:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11EC95DDD7; Tue, 4 Apr 2000 10:52:05 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id F264C5DDBD for ; Tue, 4 Apr 2000 10:52:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA02196; Tue, 4 Apr 2000 08:51:55 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA29597; Tue, 4 Apr 2000 07:42:03 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA25390; Tue, 4 Apr 2000 07:42:00 -0700 Date: Tue, 4 Apr 2000 07:41:59 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: State Reconciliation Requirement To: aboba@internaut.com Cc: "'Paul Krumviede'" , aaa-wg@merit.edu, pcalhoun@Eng.Sun.COM In-Reply-To: "Your message with ID" <012c01bf9e34$d4503ee0$268939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >As implemented in one network of which I know, it doesn't work > >well in at least some intra-domain cases. I should mention that it > >is questionable whether the problems seen were implementation > >issues or more fundamental problems. > > I wonder whether we are thinking about the same network :) > > In my experience the problems resulted from issues relating > to accounting transport. Without transport layer reliability > it is possible to lose accounting STOP packets. Without > app-layer reliability it is possible that accounting STOP > packets will be lost as a result of an accounting server > failure. Without non-volatile storage it is possible to lose > accounting records due to NAS reboots, or network partitions. > If these issues are addressed then it is possible to restore > state consistency within a minimum period of time after > connectivity is restored. Putting aside the fact that relying on accounting records is a gross hack (to say the least), I respectfully disagree. A transport layer reliability unfortunately doesn't solve the problem. Let's take a rather simplistic example, of a NAS, two proxies (or equal weight) and the final auth server. The figure below is provided to support my example: +-------+ +--------+ +--------+ | | | | | | | NAS +-------T------+ PROXY1 +-----T-----+ SERVER | | | | | | | | | +-------+ | +--------+ | +--------+ | | | +--------+ | | | | | +------+ PROXY2 +-----+ | | +--------+ In the above example, there are two completely distinct routing paths from NAS to proxy1 and proxy2. A session is established (let's say PPP for example), and the auth request is sent through PROXY1 to SERVER. An accounting start record follows. Let's suppose that PROXY1 maintains state information, which is would HAVE to in your proposal above. Now, let's assume that the link between NAS and PROXY1 is broken, and routing of IP packets cannot be achieved. PROXY1 will *assume* that NAS is no longer accessible, and will have to issue an accounting stop, on behalf of NAS. However, the routing path between NAS and PROXY2 is *still* alive. When the NAS issues the interim accounting packet, it is sent through PROXY2, to the SERVER. The above example shows that transport layer reliability does not solve the problem we've discussed. Now, perhaps the NAS can issue some sort periodic ping, which isn't unlike an interim accounting message, but what is the granularity? Further, if such a message is to be sent, the granularity should be dictated by the home server (SERVER above). Now, since I, personally, would like to remove resource management from the accounting protocol, I think that a re-authorization is the way to go. In either case, you WANT the ability for the home server to return a "hmm.... well something happened and I've changed my mind, so this user has to go" sort-of error. > > In polling systems the time to detect connectivity loss > is equal to a multiple of the polling interval; that is, if the > NAS did not answer several polls its session state can be > timed out. If the problem was due to a network partition > then when the partition is cleared the inconsistency can > be resolved by the next poll (assuming that the poll > provides a complete update on the NASes current state). But polling in an inter-domain network is a REAL hard think as home servers don't have direct access to NASes, so it comes down to inter domain pings again... routed through intermediate proxies. This is a possible think to do, of course, but let's consider the consequences. > > In event-driven systems the time to failure detection is > a multiple of the Interim accounting interval, which is typically much > longer. This can create problems. One way to improve the > situation in event-driven systems is to impose a minimum > "keep-alive" time period, in which an accounting packet > of some kind (even if only an empty packet) needs to be > sent by the NAS. Since the "keep alive" only needs to be > sent if the NAS isn't busy, it doesn't add much overhead > but it does allow connectivity loss to be detected quickly. > Again, if the connectivity loss was due to network partition > rather than a NAS crash then when connectivity is restored, > state can be retrieved by completing transmission of the > stored but untransmitted accounting records. This, again, can be done, but read my comment above. > > >But this may be only one way of approaching the problem. At > >least in theory, one can view a set of AAA servers as front-ends > >to a distributed database, and use such a database service to > >provide some of the glue for state or resource management. > > Indeed this is how resource management is often implemented. And the protocol simply needs to send a *reliable* disconnect message. The issue is with error cases, that include network partitioning, and device failures. > > > Let's take an example, a AAA server crashes. The AAA, upon reboot, has to > > inform all of it's peers of the reboot, which can be done. > > Question: why is this necessary? Are we assuming that the AAA server does > not save its state to stable storage? My understanding of "app layer > reliability" is that "taking responsibility" implies that the packet > has been processed so that the information will not be lost if the AAA > server crashes. OK. We are in agreement that the server needs to maintain some state information across reboots. That is good. So, if we agree that gathering state information is NOT a requirement, then we can simplify the requirement in the AAA doc to my proposed text that I sent yesterday. > > >But perhaps the deeper question to be considered is whether or not this is > >something that should be solved within one or more AAA protocols; > >a variant of this would be what features can assist implementors to > >build a system to address this (i.e., not assume that a AAA server > >implementation has to solve this itself). > > Indeed. To look at it from another perspective: some portions of this > problem are solved by improved reliability, some need to be addressed > by other protocol improvements and some may not need to be addressed > by the protocol at all. > > OK. I do agree that a subset of resource management is required. And I think that what you described, is pretty much the same as what I had described. What we need to consider are the problems that occur in fringe cases, and how do we recover from them. The ideal case, in theory, has the proxies maintain full state information, but this doesn't scale :(. So, a reliable transport, and a reliable disconnect message is necessary. What we need to worry about is what one does when a NAS goes down and never comes back up. Is the granularity such that the server can recover quickly enough? PatC From owner-aaa-bof@merit.edu Tue Apr 4 12:10:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA02919 for ; Tue, 4 Apr 2000 12:10:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F80E5DD94; Tue, 4 Apr 2000 12:10:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A10C5DDB5; Tue, 4 Apr 2000 12:10:14 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id AE4785DD94 for ; Tue, 4 Apr 2000 12:10:12 -0400 (EDT) Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Tue, 4 Apr 2000 11:39:34 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <2BXF766W>; Tue, 4 Apr 2000 11:39:35 -0400 Message-ID: <63E0DAD7784FD21188310000F80824B301658027@zmpkdx02.us.nortel.com> From: "Mo Zonoun" To: aaa-wg@merit.edu Subject: RE: Date: Tue, 4 Apr 2000 11:39:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9E4B.F8B99B34" 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_01BF9E4B.F8B99B34 Content-Type: text/plain; charset="iso-8859-1" unsubscribe ------_=_NextPart_001_01BF9E4B.F8B99B34 Content-Type: text/html; charset="iso-8859-1" RE:

unsubscribe

------_=_NextPart_001_01BF9E4B.F8B99B34-- From owner-aaa-bof@merit.edu Tue Apr 4 23:34:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA11427 for ; Tue, 4 Apr 2000 23:34:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D35A95DDED; Tue, 4 Apr 2000 23:31:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B09D85DDFD; Tue, 4 Apr 2000 23:31:47 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 5D84D5DDED for ; Tue, 4 Apr 2000 23:31:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA20845; Tue, 4 Apr 2000 21:31:45 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.55.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id UAA19386; Tue, 4 Apr 2000 20:31:44 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA08289; Tue, 4 Apr 2000 20:31:42 -0700 Date: Tue, 4 Apr 2000 20:31:42 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: The *new* DIAMETER Mailing List To: aaa-wg@merit.edu, ietf-radius@livingston.com, roamops@tdmx.rutgers.edu, nasreq@tdmx.rutgers.edu Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I appologize if this seems innapropriate, but the DIAMETER list owner seems to have turned the mailing list off, and I cannot for the life of me get the list of who was subscribed at the time they turned it off. So, I setup a new DIAMETER mailing list, and everyone will have to re-subscribe. To subscribe, send an e-mail to majordomo@diameter.org with "subscribe diameter " (no quotes) in the body of the message. Again, I appologize for the inconvenience. PatC From owner-aaa-bof@merit.edu Wed Apr 5 01:10:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA12427 for ; Wed, 5 Apr 2000 01:10:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CE935DD95; Wed, 5 Apr 2000 01:09:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5BE205DD99; Wed, 5 Apr 2000 01:09:43 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 30A1B5DD95 for ; Wed, 5 Apr 2000 01:09:33 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id VAA29296; Tue, 4 Apr 2000 21:56:45 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'pcalhoun@eng.sun.com'" , Subject: RE: State Reconciliation Requirement Date: Tue, 4 Apr 2000 22:11:53 -0700 Message-ID: <013c01bf9ebd$76bc4240$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >OK. I do agree that a subset of resource management is required. And I think >that what you described, is pretty much the same as what I had described. Great. Can we agree on the text that needs to go in the draft to express exactly what is required? I think we are getting closer to agreement on this... >What we need to consider are the problems that occur in fringe cases, and how do we >recover from them. The ideal case, in theory, has the proxies maintain full >state information, but this doesn't scale :(. I would like to avoid proxies maintaining full state if at all possible. I'd also like to maintain the "pass through" nature of proxies which I think is encapsulated in the definition of Proxy in the terminology section. >So, a reliable transport, and a reliable disconnect message is necessary. Agree on transport reliability as well as app layer ACKs. Those are both in the requirements already. Not sure what you mean by "reliable disconnect message." I think you are referring to the ability to re-synchronize between the NAS and AAA server on NAS reboot. Below I will make an argument that this can be achieved by transmitting the saved interim state (translating interim records to accounting STOPs) upon NAS reboot. Is your definition of "reliable disconnect" equivalent to a reboot message? >What we need to worry about is what one does when a NAS goes down and >never comes back up. Is the granularity such that the server can recover >quickly enough? If the NAS doesn't come back up, resynchronization facilities are not very useful :) Note that it may still be possible to extract information from the non-volatile storage on the NAS, e.g. a 64 MB PCMCIA card. I'm not clear that this particular failure condition yields much in the way of requirements. >I think that a re-authorization is the way to go. This is already a requirement so I think we've established that re-authorization is needed. The question is whether this covers the resource management requirement too. I think that the answer is that it doesn't cover it completely. >In either case, you WANT the ability for the home server to return >a "hmm.... well something happened and I've changed my mind, so this user has >to go" sort-of error. Does this fit under the rubric of re-authorization or is something else implied here? >Now, since I, personally, would like to remove resource >management from the accounting protocol The key point for us to clarify is when resource management functions are necessary, and what useful functionality is provided. This is not a small point since the functionality if provided in the protocol will introduce substantial complexity. So if we can eliminate or limit the required functionality this is desirable. >From your arguments, I would agree that resource management functionality is inherently unscalable for inter-domain use. So the functionality provided is inherently of limited use. The question on the table is whether it is needed at all, and if so, in what cases. The argument I'd like to make is that it is useful to provide a re-synchronization mechanism in cases where failures in the AAA server, NAS, or network could result in loss of accounting packets. I think that AAA server failures are covered by app layer ACKs; that packet loss is covered by network layer ACKs; and that network partition or NAS reboot can be covered by non-volatile storage on the NAS. However, if non-volatile storage can't be assumed in all cases then a re-synchronization mechanism is still needed. If this characterization is correct, then re-synchronization may be something that we only need do "good enough" but not spend an enormous amount of effort on. I'm interested to hear whether there is a case for more than the basic functionality that Pat has outlined. In any case, proposals for clarifying language would be welcome. ========== Assumptions ================== In analyzing the two proxy case with failure below, I am assuming that proxies function to pass-through accounting requests and responses, but do not act as store and forward devices. We didn't address this in the definition in the requirements document; perhaps we should. The idea is that a proxy does not take responsibility for retransmission and failover itself, but leaves this with the NAS. Thus the NAS owns retransmission and failover and proxies do not originate accounting packets on their own. I am assuming that the NAS supports sufficient non-volatile storage and internal interim accounting so that on a reboot only an interim interval's worth of data is lost and interim data never flows over the wire. On reboot, the NAS will flush the non-volatile storage by converting interim records to Accounting STOPs, thereby re-synchronizing with the AAA server. Similar action will be taken on healing of a network partition. ========== Detailed Response to Scenario ================== >Let's suppose that PROXY1 maintains state information, which is >would HAVE to in your proposal above. If the assumptions above can be made then I do not believe that proxy1 needs to maintain state information. I would agree that this is a bad idea. >PROXY1 will *assume* that NAS is no longer accessible, and will >have to issue an accounting stop, on behalf of NAS. My understanding is that proxies never issue accounting packets on their own, but only act as passthroughs, so this should not happen, correct? Or do we need to amend the proxy definition to allow this? Assuming that the NAS owns the retransmission and failover decision, then it would seem that the NAS could decide to failover to Proxy 2 if the link to Proxy 1 dies. Thus, the accounting stop when issued by the NAS goes to the AAA server via proxy 2. >When the NAS issues the interim accounting packet If we can assume non-volatile storage then interim packets can be stored internally and never need to flow over the wire, they are just replaced in-situ until the STOP record is available. This means that if the NAS crashes, it will have stored the previous state accurately to within the internal interim interval, and can re-synchronize with the AAA server (through proxy 1 or proxy 2 as needed) by flushing the untransmitted stored accounting packets. In this process interim records are replaced by accounting STOPs. >The above example shows that transport layer reliability does not solve the >problem we've discussed. Actually, I believe that with the above assumption, that transport and app layer reliability do provide a solution to your example case. >Now, perhaps the NAS can issue some sort periodic ping This isn't necessary if the NAS can store internal interim records in non-volatile storage, so as to provide immunity against NAS crashes or network partitions. >But polling in an inter-domain network is a REAL hard Agreed. Event-driven accounting is needed for inter-domain. >And the protocol simply needs to send a *reliable* disconnect message. >The issue is with error cases, that include network partitioning, and >device failures. There is not really any such thing as a reliable disconnect message because where the network is partitioned, in the immortal words of Marshall Rose "you don't need re-transmission, you need a LOT more voltage." So the best you can do is detect the loss of connectivity and wait until it is re-established to re-synchronize state. >OK. We are in agreement that the server needs to maintain some state >information across reboots. That is good. Yes. That is the implication of the app layer ACK requirement, I think. From owner-aaa-bof@merit.edu Wed Apr 5 02:26:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id CAA13066 for ; Wed, 5 Apr 2000 02:26:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACDEC5DED4; Wed, 5 Apr 2000 02:05:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE0015DECB; Wed, 5 Apr 2000 02:05:21 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id EE1A95DE65 for ; Wed, 5 Apr 2000 02:02:55 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id JAA37296; Wed, 5 Apr 2000 09:02:55 +0300 (EEST) Message-ID: <38EAD734.74F4B12C@cc.hut.fi> Date: Wed, 05 Apr 2000 09:03:32 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: IETF AAA WG Subject: AAA WG decisions from Adelaide? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello! Could someone briefly describe what kind of decisions were made in Adelaide last week? I'm also waiting for the meeting minutes eagerly! Kindly, please hurry.:-) Regards, Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Wed Apr 5 05:52:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id FAA14546 for ; Wed, 5 Apr 2000 05:52:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AAB1D5E347; Wed, 5 Apr 2000 05:48:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C1B8D5F638; Wed, 5 Apr 2000 05:33:57 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id F26FC5EB85 for ; Wed, 5 Apr 2000 05:26:24 -0400 (EDT) Received: from SKOLEM2 ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JNV5YGEKZA8Y4YLN@shoe.reston.mci.net> for aaa-wg@merit.edu; Wed, 5 Apr 2000 05:26:23 EST Date: Wed, 05 Apr 2000 21:26:17 +1200 From: Paul Krumviede Subject: Re: AAA WG decisions from Adelaide? In-reply-to: <38EAD734.74F4B12C@cc.hut.fi> To: =?ISO-8859-1?Q?Tom_K=2E_Weckstr=F6m?= , IETF AAA WG Message-id: <1487237578.954969977@SKOLEM2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=iso-8859-1 Content-disposition: inline Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id FAA14546 --On Wednesday, 05 April, 2000 09:03 +0300 "Tom K. Weckström" wrote: > > Hello! > > Could someone briefly describe what kind of decisions were made in > Adelaide last week? There seemed to be no seriously substantive issues with the network access requirements draft. Tom Hiller had some comments, and mail from Pat has already alluded to question of how they should be handled. Pat had some comments on the accounting attributes draft, which he will be posting to the list; there were no comments on the accounting management draft. There was a discussion of the revised charter, much of which focused on procedural questions (how will we do the evaluation?), but no apparent dissension, so it was forwarded to the ADs for IESG consideration. We all seem to agree that we want to avoid a lengthy cycle of updating the requirements draft and that we want to get candidates for evaluation Real Soon. There has been some discussion with some of the IESG members about the desired/required format for submissions of candidate protocols, mostly concerned with things that aren't already in I-D form (the concern is RFC 2026 section 10; things that aren't already in I-D form will probably require a statement of compliance, or maybe intent to comply). > I'm also waiting for the meeting minutes eagerly! > Kindly, please hurry.:-) Once we get them, we will pass them on. -paul From owner-aaa-bof@merit.edu Wed Apr 5 12:24:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19756 for ; Wed, 5 Apr 2000 12:24:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 43A4B5DE1A; Wed, 5 Apr 2000 12:24:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 280675DE23; Wed, 5 Apr 2000 12:24:27 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id 2DEC35DE1A for ; Wed, 5 Apr 2000 12:24:25 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id TAA58768; Wed, 5 Apr 2000 19:24:21 +0300 (EEST) Message-ID: <38EB68E5.FF400D39@cc.hut.fi> Date: Wed, 05 Apr 2000 19:25:09 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: Paul Krumviede Cc: IETF AAA WG Subject: Re: AAA WG decisions from Adelaide? References: <1487237578.954969977@SKOLEM2> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks Paul! Your report helped a lot. I was eager to know whether the protocol candidate discussion proceeded or even if some primary candidate was chosen. Seems, that the progress is somewhat slower... :) BTW, no one has answered to my questoin about using micropayments with AAA protocol. Has this been studied? This might be a very potential alternative for wireless roaming environments, like Mobile IP environments. Best regards, Tom Paul Krumviede wrote: > > --On Wednesday, 05 April, 2000 09:03 +0300 "Tom K. Weckström" > wrote: > > > > > Hello! > > > > Could someone briefly describe what kind of decisions were made in > > Adelaide last week? > > There seemed to be no seriously substantive issues with the network > access requirements draft. Tom Hiller had some comments, and mail > from Pat has already alluded to question of how they should be handled. > Pat had some comments on the accounting attributes draft, which he > will be posting to the list; there were no comments on the accounting > management draft. There was a discussion of the revised charter, much > of which focused on procedural questions (how will we do the evaluation?), > but no apparent dissension, so it was forwarded to the ADs for IESG > consideration. We all seem to agree that we want to avoid a lengthy > cycle of updating the requirements draft and that we want to get > candidates for evaluation Real Soon. > > There has been some discussion with some of the IESG members about > the desired/required format for submissions of candidate protocols, mostly > concerned with things that aren't already in I-D form (the concern is RFC > 2026 section 10; things that aren't already in I-D form will probably > require > a statement of compliance, or maybe intent to comply). > > > I'm also waiting for the meeting minutes eagerly! > > Kindly, please hurry.:-) > > Once we get them, we will pass them on. > > -paul -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Wed Apr 5 12:47:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA20162 for ; Wed, 5 Apr 2000 12:47:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 486FD5DDB5; Wed, 5 Apr 2000 12:45:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2E7D75DE15; Wed, 5 Apr 2000 12:45:12 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 7FF6F5DDB5 for ; Wed, 5 Apr 2000 12:45:07 -0400 (EDT) Received: from vaiobean ([204.57.137.66]) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA30013; Wed, 5 Apr 2000 09:32:13 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "=?iso-8859-1?Q?'Tom_K._Weckstr=F6m'?=" , "'Paul Krumviede'" Cc: "'IETF AAA WG'" Subject: RE: AAA WG decisions from Adelaide? Date: Wed, 5 Apr 2000 09:47:25 -0700 Message-ID: <000701bf9f1e$a03beba0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: <38EB68E5.FF400D39@cc.hut.fi> Sender: owner-aaa-bof@merit.edu Precedence: bulk The Accounting protocol is typically used to communicate resource usage. What happens after that (such as rating and settlement) isn't part of the accounting function per se. So the accounting info could be used to produce invoices that could be paid in a myriad of ways. This would include credit cards, micro-payments, barter, or even cash in a brown paper bag :) -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tom K. Weckström Sent: Wednesday, April 05, 2000 9:25 AM To: Paul Krumviede Cc: IETF AAA WG Subject: Re: AAA WG decisions from Adelaide? Thanks Paul! Your report helped a lot. I was eager to know whether the protocol candidate discussion proceeded or even if some primary candidate was chosen. Seems, that the progress is somewhat slower... :) BTW, no one has answered to my questoin about using micropayments with AAA protocol. Has this been studied? This might be a very potential alternative for wireless roaming environments, like Mobile IP environments. Best regards, Tom Paul Krumviede wrote: > > --On Wednesday, 05 April, 2000 09:03 +0300 "Tom K. Weckström" > wrote: > > > > > Hello! > > > > Could someone briefly describe what kind of decisions were made in > > Adelaide last week? > > There seemed to be no seriously substantive issues with the network > access requirements draft. Tom Hiller had some comments, and mail > from Pat has already alluded to question of how they should be handled. > Pat had some comments on the accounting attributes draft, which he > will be posting to the list; there were no comments on the accounting > management draft. There was a discussion of the revised charter, much > of which focused on procedural questions (how will we do the evaluation?), > but no apparent dissension, so it was forwarded to the ADs for IESG > consideration. We all seem to agree that we want to avoid a lengthy > cycle of updating the requirements draft and that we want to get > candidates for evaluation Real Soon. > > There has been some discussion with some of the IESG members about > the desired/required format for submissions of candidate protocols, mostly > concerned with things that aren't already in I-D form (the concern is RFC > 2026 section 10; things that aren't already in I-D form will probably > require > a statement of compliance, or maybe intent to comply). > > > I'm also waiting for the meeting minutes eagerly! > > Kindly, please hurry.:-) > > Once we get them, we will pass them on. > > -paul -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Wed Apr 5 13:00:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20370 for ; Wed, 5 Apr 2000 13:00:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 588F75DE46; Wed, 5 Apr 2000 12:59:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 44EDC5DE44; Wed, 5 Apr 2000 12:59:49 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by segue.merit.edu (Postfix) with ESMTP id B0C7A5DE40 for ; Wed, 5 Apr 2000 12:59:47 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA08290 for ; Wed, 5 Apr 2000 12:59:47 -0400 (EDT) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA08270 for ; Wed, 5 Apr 2000 12:59:46 -0400 (EDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2448.0) id <2C38M431>; Wed, 5 Apr 2000 17:59:46 +0100 Message-ID: <976F7C55E3B2D111A0720008C728549C04876AFE@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: =?iso-8859-1?Q?=27Tom_K=2E_Weckstr=F6m=27?= , "'Paul Krumviede'" , "'aboba@internaut.com'" Cc: "'IETF AAA WG'" Subject: RE: AAA WG decisions from Adelaide? Date: Wed, 5 Apr 2000 17:59:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id NAA20370 I believe Tom was alluding to the fact that the authentication and authorization services offered by AAA may be reused to support a micropayment infrastructure. Having said this, looks like this is out of the charter of this WG. alessio > ---------- > From: Bernard Aboba[SMTP:aboba@internaut.com] > Reply To: aboba@internaut.com > Sent: 05 April 2000 17:47 > To: 'Tom K. Weckström'; 'Paul Krumviede' > Cc: 'IETF AAA WG' > Subject: RE: AAA WG decisions from Adelaide? > > The Accounting protocol is typically used to communicate resource > usage. What happens after that (such as rating and settlement) isn't > part of the accounting function per se. So the accounting info could be > used to produce invoices that could be paid in a myriad of ways. > This would include credit cards, micro-payments, barter, or even > cash in a brown paper bag :) > > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Tom K. Weckström > Sent: Wednesday, April 05, 2000 9:25 AM > To: Paul Krumviede > Cc: IETF AAA WG > Subject: Re: AAA WG decisions from Adelaide? > > > > Thanks Paul! > > Your report helped a lot. > I was eager to know whether the protocol candidate discussion proceeded > or even if some primary candidate was chosen. Seems, that the progress > is somewhat slower... :) > > BTW, no one has answered to my questoin about using micropayments with > AAA protocol. Has this been studied? This might be a very potential > alternative for wireless roaming environments, like Mobile IP > environments. > > Best regards, > Tom > > Paul Krumviede wrote: > > > > --On Wednesday, 05 April, 2000 09:03 +0300 "Tom K. Weckström" > > wrote: > > > > > > > > Hello! > > > > > > Could someone briefly describe what kind of decisions were made in > > > Adelaide last week? > > > > There seemed to be no seriously substantive issues with the network > > access requirements draft. Tom Hiller had some comments, and mail > > from Pat has already alluded to question of how they should be handled. > > Pat had some comments on the accounting attributes draft, which he > > will be posting to the list; there were no comments on the accounting > > management draft. There was a discussion of the revised charter, much > > of which focused on procedural questions (how will we do the > evaluation?), > > but no apparent dissension, so it was forwarded to the ADs for IESG > > consideration. We all seem to agree that we want to avoid a lengthy > > cycle of updating the requirements draft and that we want to get > > candidates for evaluation Real Soon. > > > > There has been some discussion with some of the IESG members about > > the desired/required format for submissions of candidate protocols, > mostly > > concerned with things that aren't already in I-D form (the concern is > RFC > > 2026 section 10; things that aren't already in I-D form will probably > > require > > a statement of compliance, or maybe intent to comply). > > > > > I'm also waiting for the meeting minutes eagerly! > > > Kindly, please hurry.:-) > > > > Once we get them, we will pass them on. > > > > -paul > > -- > Tom Weckström tweckstr@cc.hut.fi > > > From owner-aaa-bof@merit.edu Wed Apr 5 13:25:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA20674 for ; Wed, 5 Apr 2000 13:25:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B86E25DDB7; Wed, 5 Apr 2000 13:24:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A75B95DD9E; Wed, 5 Apr 2000 13:24:55 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id 0D0F75DD91 for ; Wed, 5 Apr 2000 13:24:54 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id UAA59683; Wed, 5 Apr 2000 20:24:51 +0300 (EEST) Message-ID: <38EB7712.C488F4CC@cc.hut.fi> Date: Wed, 05 Apr 2000 20:25:38 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "Casati, Alessio (Alessio)" Cc: "'IETF AAA WG'" Subject: Re: AAA WG decisions from Adelaide? References: <976F7C55E3B2D111A0720008C728549C04876AFE@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello! >From Alessio's and Bernard's comments I understood that the AAA protocol really doesn't care how the bills are generated and charged, etc. Its main task has been to collect the information after the Authentication and Authorization phases. With micropayments (when considered an external protocol), the payments would happen instantaneously, which would make the role of the Accounting part of a AAA protocol just a information collector for other means than billing (trend analysis, etc.). A AAA server even log would then be needed for charging purposes only in the case of for example billing repudiation. Alessio's guess was quite near - I meant that the authentication and authorization mechanisms of the AAA protocol could be used for micropayments *and* that a micropayemnt protocol could be integrated to the AAA protocol. This would most probably save some bandwidth and remove the needs for separate (duplicate!) authenticaiton and authorization functionality from the micropayment protocol. Now, everything else but the integration part may be out of the scope of this WG... ;) "Casati, Alessio (Alessio)" wrote: > > I believe Tom was alluding to the fact that the authentication and > authorization services offered by AAA may be reused to support a > micropayment infrastructure. > > Having said this, looks like this is out of the charter of this WG. > > alessio > > > ---------- > > From: Bernard Aboba[SMTP:aboba@internaut.com] > > Reply To: aboba@internaut.com > > Sent: 05 April 2000 17:47 > > To: 'Tom K. Weckström'; 'Paul Krumviede' > > Cc: 'IETF AAA WG' > > Subject: RE: AAA WG decisions from Adelaide? > > > > The Accounting protocol is typically used to communicate resource > > usage. What happens after that (such as rating and settlement) isn't > > part of the accounting function per se. So the accounting info could be > > used to produce invoices that could be paid in a myriad of ways. > > This would include credit cards, micro-payments, barter, or even > > cash in a brown paper bag :) Regards, Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Sat Apr 8 20:56:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA20617 for ; Sat, 8 Apr 2000 20:56:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 357C45DDA0; Sat, 8 Apr 2000 20:55:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1E2315DDAC; Sat, 8 Apr 2000 20:55:41 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 8A0B15DDA0 for ; Sat, 8 Apr 2000 20:55:35 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA39921 for ; Sat, 8 Apr 2000 17:42:38 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: FW: Recharter: Authentication, Authorization, and Accounting (AAA) Date: Sat, 8 Apr 2000 17:58:04 -0700 Message-ID: <005301bfa1be$a9eccd70$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk For those not on the IETF-Announce list... -----Original Message----- From: mbeaulie@cnri.reston.va.us [mailto:mbeaulie@cnri.reston.va.us]On Behalf Of iesg@ietf.org Sent: Friday, April 07, 2000 4:53 AM To: IETF-Announce:; Cc: new-work@ietf.org Subject: Recharter: Authentication, Authorization, and Accounting (AAA) The IESG is considering rechartering the AAA working group, below is the proposed revised charter. Please send any comments to iesg@ietf.org Authentication, Authorization, and Accounting (AAA) Description of Working Group: The Authentication, Authorization and Accounting Working Group focused on the development of requirements for Authentication, Authorization and Accounting as applied to network access. Requirements were gathered from NASREQ, MOBILE IP, and ROAMOPS Working Groups as well as TIA 45.6. This incarnation of the AAA Working Group will focus on selection of a AAA protocol to be developed. We will solicit submission of protocols and compliance descriptions, will evaluate them against the requirements and will decide whether one of them meets the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design one from scratch. In this process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development. Authors of candidate protocols must be willing to give up change control to the IETF, so as to allow modification of the candidate protocols to AAA WG needs. The immediate goals of the AAA working group are to: - Request submission of candidate protocols and compliance descriptions. - Publish a draft comparing candidate protocols against the requirements. - Decide whether any of the candidate protocols meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a new protocol. From owner-aaa-bof@merit.edu Sat Apr 8 21:08:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA20795 for ; Sat, 8 Apr 2000 21:08:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E95C5DDAC; Sat, 8 Apr 2000 21:08:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3FEC55DDB3; Sat, 8 Apr 2000 21:08:17 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id D9FDD5DDAC for ; Sat, 8 Apr 2000 21:08:12 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA39935; Sat, 8 Apr 2000 17:55:01 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'pcalhoun@eng.sun.com'" , "'Matt Holdrege'" Cc: Subject: RE: State Reconciliation Requirement Date: Sat, 8 Apr 2000 18:10:27 -0700 Message-ID: <005401bfa1c0$64d27490$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >Exactly, there are some that do work, and we need one of those. So, could we >change the requirement to state that we need something that provides: 1. >transport level reliability, and 2. a reliable disconnect message, and >3. some periodic update message >Do the three above provide what we need? If so, then we can simplify the >requirement, since what we currently have does imply some sort of AAA >distributed database. Is a "periodic update message" the same as interim accounting, or is this a message providing the complete NAS state that is only required after a reboot or network partition? Can you define what you mean by a "reliable disconnect" message? Is the same as a reboot message? Or is it a more reliable accounting STOP? If the latter, then I think that this is already encapsulated in the transport and app level reliability requirements. BTW, I believe that if you have non-volatile storage, as well as transport and app layer reliability, then a periodic update message or interim accounting is NOT required. The former isn't needed because when the NAS reboots it will be send the uncompleted interim records and perhaps a reboot indication, indicating that no further interim records will be forthcoming. This should be sufficient to resynchronize state. The latter isn't needed because interim updates can be stored on non-volatile storage and therefore only need to be sent over the wire after a NAS reboot. If you don't have non-volatile storage, I believe you need the ability to retrieve the current NAS state. It is best to do this only when necessary rather than putting this in some kind of interim message. From owner-aaa-bof@merit.edu Sun Apr 9 10:44:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA29632 for ; Sun, 9 Apr 2000 10:44:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 342BE5DDA4; Sun, 9 Apr 2000 10:44:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 126555DDA1; Sun, 9 Apr 2000 10:44:31 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id CC16B5DD8D for ; Sun, 9 Apr 2000 10:44:29 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28764; Sun, 9 Apr 2000 08:44:20 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.53.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA03716; Sun, 9 Apr 2000 07:43:35 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07902; Sun, 9 Apr 2000 07:43:28 -0700 Date: Sun, 9 Apr 2000 07:43:27 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: State Reconciliation Requirement To: aboba@internaut.com Cc: "'pcalhoun@eng.sun.com'" , "'Matt Holdrege'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <005401bfa1c0$64d27490$428939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Exactly, there are some that do work, and we need one of those. So, could > we > >change the requirement to state that we need something that provides: 1. > >transport level reliability, and 2. a reliable disconnect message, and > >3. some periodic update message > > >Do the three above provide what we need? If so, then we can simplify the > >requirement, since what we currently have does imply some sort of AAA > >distributed database. > > Is a "periodic update message" the same as interim accounting, or is > this a message providing the complete NAS state that is only required > after a reboot or network partition > > Can you define what you mean by a "reliable disconnect" message? Is the > same as a reboot message? Or is it a more reliable accounting STOP? If > the latter, then I think that this is already encapsulated in the > transport and app level reliability requirements. I *really* hate to tie accounting into this, as we've done with RADIUS. I would prefer a re-authorization message (which is already a requirement), and a message that is sent when a session is terminated (let's call it an end of authorized resource usage, for lack of better words). > > BTW, I believe that if you have non-volatile storage, as well > as transport and app layer reliability, then a periodic > update message or interim accounting is NOT required. The former > isn't needed because when the NAS reboots it will be send > the uncompleted interim records and perhaps a reboot indication, > indicating that no further interim records will be forthcoming. > This should be sufficient to resynchronize state. The latter > isn't needed because interim updates can be stored on non-volatile > storage and therefore only need to be sent over the wire after > a NAS reboot. They provide an additional level of reliability in the event of network partition, and/or hard device failure. The former ensures that the resources tied to a session have a lifetime, and then will become free. > > If you don't have non-volatile storage, I believe you need the > ability to retrieve the current NAS state. It is best to do this > only when necessary rather than putting this in some kind of interim > message. Dangerous waters, if you ask me. PatC From owner-aaa-bof@merit.edu Sun Apr 9 20:41:10 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA06321 for ; Sun, 9 Apr 2000 20:41:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED6A85DD94; Sun, 9 Apr 2000 20:40:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D71735DDA2; Sun, 9 Apr 2000 20:40:48 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 53FED5DD94 for ; Sun, 9 Apr 2000 20:40:45 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA41179; Sun, 9 Apr 2000 17:27:31 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'pcalhoun@eng.sun.com'" Cc: "'Matt Holdrege'" , Subject: RE: State Reconciliation Requirement Date: Sun, 9 Apr 2000 17:43:01 -0700 Message-ID: <006201bfa285$ba5584a0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk >I would prefer a re-authorization message (which is already a requirement), and >a message that is sent when a session is terminated (let's call it an end of >authorized resource usage, for lack of better words). OK. Is a "session termination" message what is required? Is it correct to say that such a message would need both transport and application layer reliability? Are there any other requirements relating to this message? >Dangerous waters, if you ask me. So you are saying that an explicit "state reconciliation" message is not required? Do you have a draft of the language that you'd like to insert in the draft? From owner-aaa-bof@merit.edu Mon Apr 10 10:15:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20031 for ; Mon, 10 Apr 2000 10:15:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F39125DDC9; Mon, 10 Apr 2000 10:15:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E1CDD5DDC6; Mon, 10 Apr 2000 10:15:06 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 1D1665DDB4 for ; Mon, 10 Apr 2000 10:15:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10545; Mon, 10 Apr 2000 08:14:53 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA22173; Mon, 10 Apr 2000 07:14:52 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA16897; Mon, 10 Apr 2000 07:14:51 -0700 Date: Mon, 10 Apr 2000 07:14:50 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: State Reconciliation Requirement To: aboba@internaut.com Cc: "'pcalhoun@eng.sun.com'" , "'Matt Holdrege'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <006201bfa285$ba5584a0$428939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >I would prefer a re-authorization message (which is already a requirement), > and > >a message that is sent when a session is terminated (let's call it an end > of > >authorized resource usage, for lack of better words). > > OK. Is a "session termination" message what is required? Is it correct to > say that such a message would need both transport and application layer > reliability? Are there any other requirements relating > to this message? Well, as we already stated: 1. Re-authorization capabilities (already in reqs) 2. disconnect capabilities (already in reqs) 3. reliable transport (already in reqs) 4. non-volatile memory (implementation detail) > > >Dangerous waters, if you ask me. > > So you are saying that an explicit "state reconciliation" message is > not required? > > Do you have a draft of the language that you'd like to insert in the draft? How about: "This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling. The design must provide for recovery from data loss during NAS/AAA server communication outages, without requiring an Internet-wide replicated database. The granularity of the recovery of state information is not expected to be in the seconds." PatC From owner-aaa-bof@merit.edu Mon Apr 10 10:40:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA20454 for ; Mon, 10 Apr 2000 10:40:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5A1555DDBE; Mon, 10 Apr 2000 10:40:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49C975DDB3; Mon, 10 Apr 2000 10:40:32 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 13DC55DD99 for ; Mon, 10 Apr 2000 10:40:31 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA06585 for ; Mon, 10 Apr 2000 07:40:30 -0700 (MST)] Received: [from il93exb01.css.mot.com (il93exb01.css.mot.com [144.188.38.171]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA12732 for ; Mon, 10 Apr 2000 07:40:29 -0700 (MST)] Received: by il93exb01.css.mot.com with Internet Mail Service (5.5.2650.21) id <2PFBMS7B>; Mon, 10 Apr 2000 09:40:28 -0500 Message-ID: <1B429440C296D311A4C00008C7913F8DBE300F@il93exm09.css.mot.com> From: Patzer Robert-RPATZER1 To: aaa-wg@merit.edu Cc: "'Matt Holdrege'" , "pcalhoun@eng.sun.com" Subject: IPSec Date: Mon, 10 Apr 2000 09:40:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat/Matt, Is there any work going on to study the overhead added by IPSec to IP? Robert A. Patzer Motorola - PCS Stds. Admin. (847)523-5228 (800)SKYTEL2 PIN 1634493 Mobile (847) 721-3671 From owner-aaa-bof@merit.edu Mon Apr 10 11:36:44 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA21376 for ; Mon, 10 Apr 2000 11:36:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 916B05DDC2; Mon, 10 Apr 2000 11:36:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 81B325DDB4; Mon, 10 Apr 2000 11:36:23 -0400 (EDT) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id 538C15DDB3 for ; Mon, 10 Apr 2000 11:36:21 -0400 (EDT) Received: from [63.193.24.36] (rick.perlman.com [63.193.24.36]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id IAA22472; Mon, 10 Apr 2000 08:35:46 -0700 (PDT) (envelope-from perl@lucent.com) Mime-Version: 1.0 X-Sender: rdp@mail.yikes.com (Unverified) Message-Id: In-Reply-To: <005401bfa1c0$64d27490$428939cc@ntdev.microsoft.com> References: <005401bfa1c0$64d27490$428939cc@ntdev.microsoft.com> Date: Mon, 10 Apr 2000 08:35:45 -0700 To: From: Richard Perlman Subject: RE: State Reconciliation Requirement Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard: If the only reason for "Interim" records was to assure state maintenance, then you would be correct. However, there are other uses for sending periodic accounting updates during a session. Many RAS providers offer resource limited services (typically octet limitations). Some type of accounting check-pointing is required to keep an accurate running resource usage total. This total may be used to cause a disconnect or limit additional logins that take place while the first session is still active. Summary: Some type of "Interim" accounting transmission is required. Richard As Bernard Aboba wrote (4/8/00 6:10 PM -0700): >BTW, I believe that if you have non-volatile storage, as well >as transport and app layer reliability, then a periodic >update message or interim accounting is NOT required. The former >isn't needed because when the NAS reboots it will be send >the uncompleted interim records and perhaps a reboot indication, >indicating that no further interim records will be forthcoming. >This should be sufficient to resynchronize state. The latter >isn't needed because interim updates can be stored on non-volatile >storage and therefore only need to be sent over the wire after >a NAS reboot. From owner-aaa-bof@merit.edu Mon Apr 10 11:40:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA21589 for ; Mon, 10 Apr 2000 11:40:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 22D835DDB4; Mon, 10 Apr 2000 11:40:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 126775DDB3; Mon, 10 Apr 2000 11:40:22 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id B17D45DDC5 for ; Mon, 10 Apr 2000 11:40:20 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05211; Mon, 10 Apr 2000 09:40:05 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.61.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id IAA29301; Mon, 10 Apr 2000 08:39:59 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA16381; Mon, 10 Apr 2000 08:39:57 -0700 Date: Mon, 10 Apr 2000 08:39:56 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: State Reconciliation Requirement To: Richard Perlman Cc: aboba@internaut.com, 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: > > If the only reason for "Interim" records was to assure state > maintenance, then you would be correct. However, there are other > uses for sending periodic accounting updates during a session. Many > RAS providers offer resource limited services (typically octet > limitations). Some type of accounting check-pointing is required to > keep an accurate running resource usage total. This total may be > used to cause a disconnect or limit additional logins that take place > while the first session is still active. > > Summary: Some type of "Interim" accounting transmission is required. Interim accounting is already covered by the existing requirements document. PatC From owner-aaa-bof@merit.edu Mon Apr 10 11:53:00 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA21960 for ; Mon, 10 Apr 2000 11:53:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8813E5DDA4; Mon, 10 Apr 2000 11:52:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 76BC05DDA0; Mon, 10 Apr 2000 11:52:39 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id 9FBBE5DD94 for ; Mon, 10 Apr 2000 11:52:38 -0400 (EDT) Received: from p154.tnt1.chc1.voyager.co.nz ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JO2IX0R8VA8WW0K8@shoe.reston.mci.net> for aaa-wg@merit.edu; Mon, 10 Apr 2000 11:52:37 EST Date: Tue, 11 Apr 2000 03:52:31 +1200 From: Paul Krumviede Subject: Re: IPSec In-reply-to: <1B429440C296D311A4C00008C7913F8DBE300F@il93exm09.css.mot.com> To: Patzer Robert-RPATZER1 , aaa-wg@merit.edu Message-id: <1942412178.955425151@p154.tnt1.chc1.voyager.co.nz> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk --On Monday, 10 April, 2000 09:40 -0500 Patzer Robert-RPATZER1 wrote: > Pat/Matt, > > Is there any work going on to study the overhead added by IPSec to IP? Which types of overhead to you mean? Packet size increase? Latency if one has to set up an SA? Steve Bellovin did some quick calculations some time ago, using a packet size distribution that may not be very representative, to gauge the packet size increase, and found it to be not all that large (on the order of 10%?). I don't recall what the configuration was, and he mentioned that he didn't remember many of the details (all this from a message on the IPsec mailing list some time ago, which I could probably exhume). There has also been some discussion on throughput of various MAC and encryption algorithms, with or without hardware assist, on the IPsec mailing list. -paul From owner-aaa-bof@merit.edu Mon Apr 10 14:09:09 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA25244 for ; Mon, 10 Apr 2000 14:09:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E6825DDA0; Mon, 10 Apr 2000 14:08:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 775E85DD95; Mon, 10 Apr 2000 14:08:47 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 3B8975DD94 for ; Mon, 10 Apr 2000 14:08:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01958 for ; Mon, 10 Apr 2000 12:08:44 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.53.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id LAA22988 for ; Mon, 10 Apr 2000 11:08:43 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA18274; Mon, 10 Apr 2000 11:08:42 -0700 Date: Mon, 10 Apr 2000 11:08:42 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: candidate protocol submission dates 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 have we come up with actual dates (beginning and end) of the protocol submission phase? PatC From owner-aaa-bof@merit.edu Mon Apr 10 18:11:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA28744 for ; Mon, 10 Apr 2000 18:11:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AE26B5DD91; Mon, 10 Apr 2000 18:11:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9B0AF5DD95; Mon, 10 Apr 2000 18:11:18 -0400 (EDT) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 988E85DD91 for ; Mon, 10 Apr 2000 18:11:17 -0400 (EDT) Received: by backin5.merit.edu (Postfix) id 7F72CA9506; Mon, 10 Apr 2000 18:11:17 -0400 (EDT) Received: from Merit.edu (dwspencepc.merit.edu [198.108.62.224]) by backin5.merit.edu (Postfix) with ESMTP id 6100AA9501 for ; Mon, 10 Apr 2000 18:11:17 -0400 (EDT) Message-ID: <38F25185.A4DA5E05@Merit.edu> Date: Mon, 10 Apr 2000 18:11:17 -0400 From: "David W. Spence" Organization: Merit Network, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: Re: State Reconciliation Requirement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk After reflecting a while on the ideas discussed in this thread, I'd like to offer three general thoughts on state reconciliation. 1. Session state synchronization is vital for a number of purposes -- not just reliable accounting. 2. Reauthentication is not the same thing as session state synchronization. 3. Maybe session state synchronization can scale in the interdomain case. While these may seem to run counter to some of the discussion in this thread, I want to emphasize that I am not opposed either to reliable accounting or reauthentication, for which we have documented requirements. I just think that the problem of state synchronization broader than that and that it deserves consideration by this working group. I will try to expand on each of the thoughts stated above. 1. Session state synchronization is vital for a number of purposes -- not just reliable accounting. I believe that the maintenance of session state information is necessary for purposes other than simply to support reliable accounting. Among these are authorization and policy enforcement and real-time auditing and security management. a. Authorization and Policy Enforcement A very widely implemented authorization policy is a limit on the number of simultaneous sessions a user may have. There are many variations on this kind of policy, for instance, the number of simultaneous ports that a group of users can use at any one time. b. Real-Time Auditing and Security Management Another vital use for session state information is to support real-time auditing and security management. Administrations want to know what their users are doing in real time. They want to know what domains are billing sessions to them in real time. They use this information for business auditing, and they also use it for security auditing. They want to be able to detect and investigate unusual usage patterns as they occur. 2. Reauthentication is not the same thing as session state synchronization. Reauthentication has been proposed as an alternative to session state tracking. The idea is that if you have not received a session stop message, you should assume that the session is still in progress until the reauthentication timeout. Then if the session does not reauthenticate, you should presume it has terminated. However, I believe that using reauthentication as a substitute for session state tracking is problematic. a. The primary purpose of reauthentication was not to solve the state synchronization problem. As I understand it, reauthentication was proposed in the roamops discussions as a solution to interdomain fraud. The fraud potential was that an unscrupulous foreign network could attempt to overcharge a home network by reporting a longer session time than in fact occurred. This kind of fraud can be detected in other ways, for example, by standard auditing techniques. In fact, auditing techniques will almost certainly be used in any event because auditing techniques defend against software and operations errors which robust protocol design does not. So all organizations can be expected to implement auditing techniques. Some organizations may also wish to invoke protocol *options* such as reauthentication. But I would expect many interdomain operations not to use the option. b. Reauthentication is expensive. Session synchronization checkpointing techniques can be implemented to be fairly efficient. Authentication is much more expensive. Calculating MD5 hashes as with CHAP, for example, requires more compute cycles. Large-scale operations may be forced not to implement this option for performance reasons, or may choose to require reauthentication too infrequently to be useful for the kinds of purposes discussed under point 1, above. c. Reauthentication doesn't always work very well. The problem with reauthentication, as a general tool, is that it will have to work in the face of many different authentication types. Does it work with PAP (the majority of today's installed user base)? Can a NAS trigger PAP in mid-session? Do current PPP clients support this? Might the user have to retype the password every time? Some kinds of authentication authenticate the user rather than the machine. Then reauthentication becomes obnoxious. If authentication is by smart card or biometric data (such as a retina scan), then reauthentication, if needed for *security* purposes, might be tolerated. But frequent reauthentication for the purpose of session state tracking may become intolerable. 3. Maybe session state synchronization can scale in the interdomain case. Scaling arguments at the requirements stage are very difficult to make. On the one hand it is rather difficult to argue convincingly that a certain requirement cannot be met in a large, multi-domain network by any conceivable technique. On the other hand, it is difficult in the midst a mailing list thread to propose a comprehensive solution. Certainly I believe that there are bad ways to design session state tracking that would fail miserably in a multidomain environment. But I'm thinking that some of the techniques that we use in Michnet could be generalized and adapted to support multi-domain roaming. First, I will describe some of how we do state management in Michnet. Then I will propose a couple of additional capabilities I think would be useful but are currently hard to implement due to protocol limitations. Finally, I will argue that the mechanisms used do not have to be perfect to be useful. a. Session State Synchronization in Michnet Michnet is the regional backbone and dialin network that Merit operates on behalf of our member and affiliate institutions. For a brief description of Michnet, the reader is referred to section 8 of RFC 2194, "Review of Roaming Implementations". Some of the software that we run in Michnet including most of what I will describe in this section is not included in the AAA server that Merit licenses commercially. In some cases this is due to lack of standards and in others to the idiosyncrasies of Michnet. Anyway, this is certainly not a plug for the Merit AAA server. The following description has been somewhat simplified and is not intended to be a totally accurate implementation specification. In Michnet, some of the dialin ports are owned by Merit and some by our member institutions. Each group of NAS ports is managed by a AAA server called a hunt group server. Each of our member institutions and affiliates manage one or more realms with AAA servers I will call home servers. In Michnet, the policies by which users of one member institution are permitted to use another member institution's ports are labyrinthine and arcane. The mechanisms by which they are enforced are quite beyond the scope of this memo. The important thing to note here is that everything relies on state synchronization. The hunt group servers need state. The home servers need state. One more general comment, and then I'll describe how the state synchronization works. Our state synchronization mechanisms are all concerned with supporting authorization decisions, not maintaining accurate accounting data. We use RADIUS accounting messages to maintain state. But other than that, the accounting logic is separate from the session state logic. Bernard Aboba did a pretty thorough job in this thread of describing techniques that can be used to minimize loss of accounting data. I will not be addressing that problem. And now for the state synchronization logic. Each hunt group server contains a module called a NAS manager. The NAS manager module periodically polls the NASes managed by the hunt group server to refresh the information in its local session table. Session records are normally created and closed by accounting starts and stops. The NAS manager merely supplements this information. NAS manager polls are currently Merit proprietary. But they could be implemented using SNMP or the future AAA protocol. Hunt group servers periodically sort their local session table by realm and generate a series of checkpoint messages each of which aggregates information on sessions for a particular realm. The checkpoint messages are Merit proprietary. They are sent to the home servers. In Michnet, they are sent directly from hunt group server to home server, but in a very large roaming consortium, they could be sent to a broker and forwarded based on realm. The home servers normally close their session records based on accounting stops, but also time them out. If a configurable number of checkpoint intervals goes by without receiving a checkpoint message, a session record is closed. By closed, I mean for state synchronization purposes -- accounting is done independently through accounting interim and stop messages. Currently, the hunt group server session tables are stored in volatile memory. (Usage records, audit logs, and various other data are written to disk, but not the current session records.) If a hunt group server crashes and reboots, its NAS manager module retrieves state information from the NASes it manages directly and rebuilds its session table. The home servers are not notified of a hunt group server reboot. Rather the rebooted hunt group server sends out a batch of checkpoint messages which keep the home servers refreshed. Any sessions that terminated during the hunt group server downtime time out in the home server. What if a hunt group server crashes hard and doesn't reboot? Then the NASes that it managed will start using a backup server. So then the backup server has to regenerate state and somehow coordinate with the primary server when the primary server finally *does* reboot? That would be a good idea, but actually, no. The backup server is stateless. How can that be, since now, session state information will then be lost? The answer to that question is discussed in point c, below. Now home servers do write their session tables out to disk periodically, so if they crash and reboot, they can recover state information from disk. In addition, rebooted home servers can rebuild their session tables based on information they receive in checkpoint messages. (Their are some security considerations here which I will omit in the interest of brevity.) b. Some Good Stuff We Wish We Could Do 1) Provide better backup for proxies. It would be great to be able to provide full backup for proxy servers (such as the hunt group servers in Michnet). There are various ways this could be done. Primary and backup servers could periodically synchronize state information. Or perhaps primary and backup servers could use fault tolerant data base servers to store session tables. 2) Home servers should be able to kill sessions. Home servers should have more control over user sessions than RADIUS allows. In particular, home servers should be able to send messages back down the proxy chain to terminate sessions. c. State synchronization doesn't have to be perfect to be useful. There is a tendency to avoid the state synchronization problem on the grounds that one can always imagine some scenario that the protocol just can't handle. I think this is a mistake. In our experience, state synchronization doesn't have to be perfect in order to be useful. In general, state-based policies prohibit at certain times what would be allowed at other times. These are not security policies. For network access purposes (though perhaps not for all purposes), one generally wants to err on the side of permissiveness. Suppose a user is allowed one simultaneous login. If you think he is already logged in somewhere but he is not, then you have one unhappy user. But if you think he is not logged in and he actually is, then he won't be unhappy. But he also can't exploit your mistake in any systematic way, because you don't make it very often and he doesn't know when you are going to make it. What this means is that session records that persist when the session has terminated are a problem. They should be timed out and destroyed. But lost session records are not such a problem, as long as you don't lose them often or predictably, because they cause you to err on the side of permissiveness. Of course, the authors of state-based policies need to understand that state-tracking isn't perfect and that the consequence of tracking errors is likely to be over-permissiveness. -- David W. Spence email: DWSpence@Merit.edu Senior Systems Research Programmer phone: (734) 615-2630 Merit Network, Inc. fax: (734) 647-3745 4151 Plymouth Road, Suite C Ann Arbor MI 48105-2785 U.S.A. From owner-aaa-bof@merit.edu Mon Apr 10 18:48:40 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA29148 for ; Mon, 10 Apr 2000 18:48:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB6205DE1E; Mon, 10 Apr 2000 18:47:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 935C45DE1D; Mon, 10 Apr 2000 18:47:22 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 5C5DC5DDFF; Mon, 10 Apr 2000 18:47:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA16497; Mon, 10 Apr 2000 16:47:18 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.103.34]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id PAA20978; Mon, 10 Apr 2000 15:47:17 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA04706; Mon, 10 Apr 2000 15:47:14 -0700 Date: Mon, 10 Apr 2000 15:47:13 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: State Reconciliation Requirement To: "David W. Spence" Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" <38F25185.A4DA5E05@Merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Dave, An excellent tutorial on MichNet's NAS manager. I would not, however, that there is code that *can* be found in the Merit AAA Server that provides state re-synchronization. This is the basis for the DIAMETER Resource Management Internet-Draft. I will expand a little here to help (at a 50K foot view) ... The draft contains three features: 1. Session-Free-Request/Answer - Sent when a session is terminated 2. Session-Resource-Query/Response - Query a peer to get a snapshot of a peer's current state 3. Resource-Reclaim-Request - Sent to request that a NAS terminate a session (not relevant for the purposes of this discussion). So, the basic idea is that when a user is auth*, the home server generates a token. This token MAY be signed to eliminate forgery. When a user terminates his/her session, a Session-Free-Request is sent by the NAS to the home server (through a proxy chain). Now, it is assumed that each first hop server maintains state information of what sessions are currently active on the respective NASes. The home servers ALSO maintain state information for all active users. When a local proxy crashes, it issues a Session-Resource-Query message to all of its NASes, and receives the state information. The Home Server can do the same by querying all first hop servers. So, the above appears to provide a similar amount of granularity as the MichNet implementation, but using the AAA protocol instead of some out-of-band protocol. If the above is deemed necessary, then we (as a WG) need to agree. I will not be running the actual networks, so I'm not sure that my opinion really matters. If we need it, it certainly is simple for me. PatC From owner-aaa-bof@merit.edu Mon Apr 10 20:55:20 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id UAA00496 for ; Mon, 10 Apr 2000 20:55:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 725EB5DDB4; Mon, 10 Apr 2000 20:54:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 610065DDAC; Mon, 10 Apr 2000 20:54:59 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id D79AA5DDA4 for ; Mon, 10 Apr 2000 20:54:54 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id RAA42513; Mon, 10 Apr 2000 17:41:32 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Aydin Edguer'" , "'Pat Calhoun'" , Cc: "'Matt Holdrege'" Subject: RE: State Reconciliation Requirement Date: Mon, 10 Apr 2000 17:57:06 -0700 Message-ID: <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200004101826.OAA19698@picu.cmh.ascend.com> Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk How about this: "This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling. The design must provide for recovery from data loss due to a variety of faults, including NAS and AAA server reboots, and NAS/AAA server communication outages. The granularity of the recovery of state information after an outage may be on the order of a fraction of a minute. In order to provide for state recovery, the following capabilities are required: a. Re-authorization capabilities (described in []) b. Session disconnect message (described in []) c. Transport and application-layer reliability (described in []) d. An interim message (described in []). e. A mechanism for the AAA server to retrieve state information from the NAS. This mechanism will provide timely information though a complete state dump may not be immediately available. f. A NAS reboot message. If non-volatile memory is present, it is believed that only elements a - c are needed. However, since this will not always be true, other mechanisms are also needed. Mechanism d provides recovery time on the order of the interim interval, and so may be too slow in many cases. Mechanisms e and f can be useful but are not imlementable at Internet scale for use in applications such as roaming." -----Original Message----- From: Aydin Edguer [mailto:edguer@cmh.ascend.Com] Sent: Monday, April 10, 2000 11:27 AM To: Pat Calhoun Cc: Matt Holdrege; Bernard Aboba Subject: Re: State Reconciliation Requirement > The design must provide for recovery from data loss during NAS/AAA server > communication outages, without requiring an Internet-wide replicated > database. The granularity of the recovery of state information is not > expected to be in the seconds." Hmm... I think that some applications will require recovery of [some] state information in seconds. The example of a per-user login limit is one where the delay may be a second or two but cannot be ten or twenty seconds without causing customer frustration. In the per-user login example I think the important pieces (from a AAA server point of view) are: (a) that a mechanism is provided by which a AAA server can query a NAS or the AAA-GW for a NAS (which does not talk AAA) to obtain accurate state information, (b) that the mechanism provides timely information, with the understanding that a full state dump may not be immediately or quickly available, and (c) that state information be available to Authorization applications in addition to Accounting applications of AAA servers. Note that (a) also implies a need for the AAA server to determine the NAS or AAA-GW location (address) and a common session identifier. Just a personal opinion. From owner-aaa-bof@merit.edu Mon Apr 10 21:52:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA01194 for ; Mon, 10 Apr 2000 21:52:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF7E45DDBE; Mon, 10 Apr 2000 21:51:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D36C15DD9E; Mon, 10 Apr 2000 21:51:37 -0400 (EDT) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id 7DFB55DDA4 for ; Mon, 10 Apr 2000 21:51:36 -0400 (EDT) Received: from [63.193.24.36] (rick.perlman.com [63.193.24.36]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id SAA29203; Mon, 10 Apr 2000 18:50:47 -0700 (PDT) (envelope-from perl@lucent.com) Mime-Version: 1.0 X-Sender: rdp@mail.yikes.com (Unverified) Message-Id: In-Reply-To: <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> References: <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> Date: Mon, 10 Apr 2000 18:50:47 -0700 To: , "'Aydin Edguer'" , "'Pat Calhoun'" , From: Richard Perlman Subject: RE: State Reconciliation Requirement Cc: "'Matt Holdrege'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard: There may be cases when a NAS remains "booted" but accounting may stop temporarily. For these cases I think there should also be accounting ON and OFF messages as in RADIUS. Richard As Bernard Aboba wrote (4/10/00 5:57 PM -0700): >f. A NAS reboot message. From owner-aaa-bof@merit.edu Mon Apr 10 23:13:46 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id XAA02434 for ; Mon, 10 Apr 2000 23:13:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9007E5DE08; Mon, 10 Apr 2000 23:13:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 805B95DE0A; Mon, 10 Apr 2000 23:13:23 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 571395DE08; Mon, 10 Apr 2000 23:13:18 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id UAA42645; Mon, 10 Apr 2000 20:00:10 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'David W. Spence'" , Subject: RE: State Reconciliation Requirement Date: Mon, 10 Apr 2000 20:15:45 -0700 Message-ID: <010a01bfa364$3a973b70$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <38F25185.A4DA5E05@Merit.edu> Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks for the summary -- great posting. Based on your experience, can we boil the requirements for state reconcilation down to a paragraph or two that we can insert in the NA requirements draft, so that we can bring it to WG last call again? From owner-aaa-bof@merit.edu Tue Apr 11 10:12:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA12017 for ; Tue, 11 Apr 2000 10:12:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACCC15DDA0; Tue, 11 Apr 2000 10:11:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 99E215DDB3; Tue, 11 Apr 2000 10:11:50 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 09A065DDA0 for ; Tue, 11 Apr 2000 10:11:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA14360; Tue, 11 Apr 2000 08:11:27 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.93.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id HAA24111; Tue, 11 Apr 2000 07:11:26 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26097; Tue, 11 Apr 2000 07:11:17 -0700 Date: Tue, 11 Apr 2000 07:11:17 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: State Reconciliation Requirement To: aboba@internaut.com Cc: "'Aydin Edguer'" , "'Pat Calhoun'" , aaa-wg@merit.edu, "'Matt Holdrege'" In-Reply-To: "Your message with ID" <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk OK, this seems to be in line with rough concensus. Go ahead and update the draft with the text below. At a minimum, it at least now describes exactly what we want. Now on to updating my Resource-Management draft... PatC > How about this: > > "This requirement refers to the ability of the NAS to use > the AAA server to manage resource allocation state. This > capability can assist with, but it is not synonymous with, > simultaneous user login control, port usage limitations, > or IP address pooling. The design must provide for recovery > from data loss due to a variety of faults, > including NAS and AAA server reboots, and NAS/AAA server > communication outages. The granularity of the recovery of state > information after an outage may be on the order of a fraction > of a minute. In order to provide for state recovery, > the following capabilities are required: > > a. Re-authorization capabilities (described in []) > b. Session disconnect message (described in []) > c. Transport and application-layer reliability (described in []) > d. An interim message (described in []). > e. A mechanism for the AAA server to retrieve state information from > the NAS. This mechanism will provide timely information though > a complete state dump may not be immediately available. > f. A NAS reboot message. > > If non-volatile memory is present, it is believed that only elements > a - c are needed. However, since this will not always be true, > other mechanisms are also needed. Mechanism d provides > recovery time on the order of the interim interval, and so may be > too slow in many cases. Mechanisms e and f can be useful but are > not imlementable at Internet scale for use in applications such > as roaming." > > > -----Original Message----- > From: Aydin Edguer [mailto:edguer@cmh.ascend.Com] > Sent: Monday, April 10, 2000 11:27 AM > To: Pat Calhoun > Cc: Matt Holdrege; Bernard Aboba > Subject: Re: State Reconciliation Requirement > > > > The design must provide for recovery from data loss during NAS/AAA server > > communication outages, without requiring an Internet-wide replicated > > database. The granularity of the recovery of state information is not > > expected to be in the seconds." > > Hmm... I think that some applications will require recovery of [some] > state information in seconds. > > The example of a per-user login limit is one where the delay may be a > second or two but cannot be ten or twenty seconds without causing customer > frustration. > > In the per-user login example I think the important pieces (from a AAA > server point of view) are: > (a) that a mechanism is provided by which a AAA server can query a NAS > or the AAA-GW for a NAS (which does not talk AAA) to obtain accurate > state information, > (b) that the mechanism provides timely information, with the understanding > that a full state dump may not be immediately or quickly available, > and > (c) that state information be available to Authorization applications > in addition to Accounting applications of AAA servers. > > Note that (a) also implies a need for the AAA server to determine the > NAS or AAA-GW location (address) and a common session identifier. > > Just a personal opinion. > From owner-aaa-bof@merit.edu Tue Apr 11 12:57:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA14632 for ; Tue, 11 Apr 2000 12:57:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6278F5DDB3; Tue, 11 Apr 2000 12:57:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4F78D5DDC4; Tue, 11 Apr 2000 12:57:27 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id CBC745DDB3 for ; Tue, 11 Apr 2000 12:57:25 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Tue, 11 Apr 2000 11:42:59 -0400 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2VXRJRBD; Tue, 11 Apr 2000 11:43:00 -0400 Received: from mitton (mitton.corpeast.baynetworks.com [132.245.145.106]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2SS0Y993; Tue, 11 Apr 2000 11:42:56 -0400 Message-Id: <4.2.2.20000411113709.00df65e0@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 11 Apr 2000 11:44:37 -0400 To: aboba , aaa-wg From: "David Mitton" Subject: RE: State Reconciliation Requirement Cc: "'Matt Holdrege'" In-Reply-To: <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> References: <200004101826.OAA19698@picu.cmh.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Looks good! - Dave. At 05:57 PM 4/10/00 -0700, Bernard Aboba wrote: >How about this: > >"This requirement refers to the ability of the NAS to use >the AAA server to manage resource allocation state. This >capability can assist with, but it is not synonymous with, >simultaneous user login control, port usage limitations, >or IP address pooling. The design must provide for recovery >from data loss due to a variety of faults, >including NAS and AAA server reboots, and NAS/AAA server >communication outages. The granularity of the recovery of state >information after an outage may be on the order of a fraction >of a minute. In order to provide for state recovery, >the following capabilities are required: > >a. Re-authorization capabilities (described in []) >b. Session disconnect message (described in []) >c. Transport and application-layer reliability (described in []) >d. An interim message (described in []). >e. A mechanism for the AAA server to retrieve state information from > the NAS. This mechanism will provide timely information though > a complete state dump may not be immediately available. >f. A NAS reboot message. > >If non-volatile memory is present, it is believed that only elements >a - c are needed. However, since this will not always be true, >other mechanisms are also needed. Mechanism d provides >recovery time on the order of the interim interval, and so may be >too slow in many cases. Mechanisms e and f can be useful but are >not imlementable at Internet scale for use in applications such >as roaming." > > >-----Original Message----- >From: Aydin Edguer [mailto:edguer@cmh.ascend.Com] >Sent: Monday, April 10, 2000 11:27 AM >To: Pat Calhoun >Cc: Matt Holdrege; Bernard Aboba >Subject: Re: State Reconciliation Requirement > > > > The design must provide for recovery from data loss during NAS/AAA server > > communication outages, without requiring an Internet-wide replicated > > database. The granularity of the recovery of state information is not > > expected to be in the seconds." > >Hmm... I think that some applications will require recovery of [some] >state information in seconds. > >The example of a per-user login limit is one where the delay may be a >second or two but cannot be ten or twenty seconds without causing customer >frustration. > >In the per-user login example I think the important pieces (from a AAA >server point of view) are: > (a) that a mechanism is provided by which a AAA server can query a NAS > or the AAA-GW for a NAS (which does not talk AAA) to obtain accurate > state information, > (b) that the mechanism provides timely information, with the understanding > that a full state dump may not be immediately or quickly available, > and > (c) that state information be available to Authorization applications > in addition to Accounting applications of AAA servers. > >Note that (a) also implies a need for the AAA server to determine the >NAS or AAA-GW location (address) and a common session identifier. > >Just a personal opinion. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Tue Apr 11 14:42:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA15970 for ; Tue, 11 Apr 2000 14:42:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B44E5DDCF; Tue, 11 Apr 2000 14:42:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7F3A05DDC9; Tue, 11 Apr 2000 14:42:32 -0400 (EDT) Received: from NOD.RESTON.MCI.NET (nod.Reston.mci.net [166.45.6.38]) by segue.merit.edu (Postfix) with ESMTP id 99BD25DDC4 for ; Tue, 11 Apr 2000 14:42:31 -0400 (EDT) Received: from 10.0.1.42 ([166.45.6.251]) by shoe.reston.mci.net (PMDF V5.2-32 #40475) with ESMTP id <01JO434R64A88WW0NP@shoe.reston.mci.net> for aaa-wg@merit.edu; Tue, 11 Apr 2000 14:42:30 EST Date: Tue, 11 Apr 2000 16:04:31 +1200 From: Paul Krumviede Subject: Re: candidate protocol submission dates In-reply-to: To: "pcalhoun@eng.sun.com" , aaa-wg@merit.edu Message-id: <1986331538.955469071@localhost> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-aaa-bof@merit.edu Precedence: bulk --On Monday, 10 April, 2000 11:08 -0700 "pcalhoun@eng.sun.com" wrote: > have we come up with actual dates (beginning and end) of the protocol > submission phase? Not really. In some sense we are restricted to an informal solication until the IESG responds. My take on it is the sooner the better; certainly an indication of intent to submit something, with pointers to documentation, would be much appreciated, if only to allow some more parallelsim in with the re-chartering process. -paul From owner-aaa-bof@merit.edu Tue Apr 11 16:03:41 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA17709 for ; Tue, 11 Apr 2000 16:03:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C0C15DDC6; Tue, 11 Apr 2000 16:00:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 193015DDB3; Tue, 11 Apr 2000 16:00:57 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 4C4E55DDC9 for ; Tue, 11 Apr 2000 16:00:51 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25297 for ; Tue, 11 Apr 2000 14:00:41 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.103.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id MAA09957 for ; Tue, 11 Apr 2000 12:54:47 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA06555; Tue, 11 Apr 2000 12:54:39 -0700 Date: Tue, 11 Apr 2000 12:54:31 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Comments on draft-ietf-aaa-acct-01.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 As promised in Adeliade, I was to provide my comments on the above document. First off, I wish to state that the document is very well written, and I wish to thank the authors for their hard work. II really didn't have too many comments on this document, since it doesn't mention protocols that do not have deployment. The only comment I have is below: 1. Intro/Abstract There is a reference to a document, but the version is set to *-0x.txt. It would be preferable for the abstract to not have to mention any such document, and use a reference [x] in the intro. I will be sending my comments on the companion document today. Expect many more comments on that one given that it covers DIAMETER. Sorry for the delay in sending this e-mail. PatC From owner-aaa-bof@merit.edu Tue Apr 11 16:23:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA18090 for ; Tue, 11 Apr 2000 16:23:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 715BE5DDC4; Tue, 11 Apr 2000 16:23:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 60AF15DDBA; Tue, 11 Apr 2000 16:23:35 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 2F8925DDB3 for ; Tue, 11 Apr 2000 16:23:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16109 for ; Tue, 11 Apr 2000 14:23:23 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.95.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id NAA17241 for ; Tue, 11 Apr 2000 13:23:22 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA29451; Tue, 11 Apr 2000 13:23:21 -0700 Date: Tue, 11 Apr 2000 13:23:21 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Comments on draft-eitf-aaa-accounting-attributes-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 As promised in Adelaide, here are my comments on the above mentioned document: 1. Section 4.2 The text reads: "The DIAMETER Policy and Accounting Extension for SIP (Session Initia- tion Protocol) document [DIAM-SIP] extends DIAMETER by adding a pol- icy and accounting information exchange mechanism between a DIAMETER policy server and a SIP proxy server." I am not sure what the benefit of the above paragraph really is. This is a draft that must have expired at least a year ago, and was the first attempt at getting SIP as a supported extension. The DIAMETER protocol has changed considerably since then, and the accounting extension specifies that any accounting records be carries within an ADIF-Record AVP. Supporting an ADIF-Record is much more flexible than the previous approach, which was similar to RADIUS, of including any and all AVPs that may be of use in an accounting record. The support for the ADIF-Record AVP now allows for multiple accounting records to be transfered in a single DIAMETER transaction, possibly all with a different final destination. If you prefer to use an application that is currently well defined, and supported, I would propose Mobile IP. However, since it uses the ADIF-Record, I'm not sure what the benefit of adding more detail would be. So, the following paragraph is also obsoleted: "A DIAMETER server is responsible for maintaining a user policy and accounting database and a means to update it. A SIP proxy server needs to contact a DIAMETER server during multimedia session setup and teardown time to perform admission control and accounting tasks. The exchange mechanism protocol does not make any assumption about policy and billing algorithms at DIAMETER servers." 2. Section 7.2.2. The header format is incorrect (I suspect the header was pulled from the SIP draft, which was REALLY old). Here is the format from the latest draft: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AVP Length | Reserved |P|T|V|R|M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor ID (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+-+-+-+-+ AVP Flags: P - Protected bit T - Tag bit V - Vendor-ID bit R - Reserved (MUST be set to zero) M - Mandatory bit 3. Section 9.2.1. This section lists the data types supported by DIAMETER, but fails to list the Complex type, which may be used to encode structures. That's all folks! PatC From owner-aaa-bof@merit.edu Tue Apr 11 17:34:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA19092 for ; Tue, 11 Apr 2000 17:34:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B9F75DDB3; Tue, 11 Apr 2000 17:34:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 461425DDBA; Tue, 11 Apr 2000 17:34:32 -0400 (EDT) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id DB7385DDB3 for ; Tue, 11 Apr 2000 17:34:30 -0400 (EDT) Received: from pcperlman.lucentradius.com (IDENT:root@nerf.yikes.com [209.228.7.149]) by nerf.yikes.com (8.9.3/8.9.3) with ESMTP id OAA37727; Tue, 11 Apr 2000 14:33:35 -0700 (PDT) (envelope-from perl@lucent.com) Message-Id: <4.3.1.2.20000412202938.00aad5c0@mail.yikes.com> X-Sender: rdp@mail.yikes.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 12 Apr 2000 20:34:40 +0100 To: "pcalhoun@eng.sun.com" , aboba@internaut.com From: Richard Perlman Subject: NAS Reboot messages Cc: aaa-wg@merit.edu In-Reply-To: References: <"Your message with ID" <010501bfa350$dc01f450$428939cc@ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat: I had sent an earlier message to the list regarding the possible need for the equivalent of the RADIUS Accounting On/Off messages. I did not see any discussion so there may be good reasons not to do it. But, barring any good reason not to, I think On/Off messages are probably necessary for times when accounting may be suspended but the NAS does not actually re-boot. Technically, an Accounting Off message is not needed since an Accounting On message implies that it had been off. However, the time interval may be great and it is probably best to notify the AAA server(s) as soon as possible. Richard At 03:11 PM 04/11/2000, pcalhoun@eng.sun.com wrote: >OK, this seems to be in line with rough concensus. Go ahead and update the >draft with the text below. At a minimum, it at least now describes exactly >what we want. > >Now on to updating my Resource-Management draft... > >PatC > > > How about this: > > f. A NAS reboot message. From owner-aaa-bof@merit.edu Tue Apr 11 18:57:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA20259 for ; Tue, 11 Apr 2000 18:57:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40CA25DDDB; Tue, 11 Apr 2000 18:56:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2E6045DDDD; Tue, 11 Apr 2000 18:56:54 -0400 (EDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by segue.merit.edu (Postfix) with ESMTP id 460C65DDDB for ; Tue, 11 Apr 2000 18:56:53 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-blue.research.att.com (Postfix) with ESMTP id F30444CE1B; Tue, 11 Apr 2000 18:56:47 -0400 (EDT) Received: from smb.research.att.com (sigaba.research.att.com [135.207.23.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id SAA10632; Tue, 11 Apr 2000 18:56:46 -0400 (EDT) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 0A1D035DC2; Tue, 11 Apr 2000 09:49:41 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Krumviede Cc: Patzer Robert-RPATZER1 , aaa-wg@merit.edu Subject: Re: IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 09:49:41 -0400 Message-Id: <20000411134942.0A1D035DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk In message <1942412178.955425151@p154.tnt1.chc1.voyager.co.nz>, Paul Krumviede writes: >--On Monday, 10 April, 2000 09:40 -0500 Patzer Robert-RPATZER1 > wrote: > >> Pat/Matt, >> >> Is there any work going on to study the overhead added by IPSec to IP? > >Which types of overhead to you mean? Packet size increase? Latency if one >has to set up an SA? > >Steve Bellovin did some quick calculations some time ago, using a packet >size distribution that may not be very representative, to gauge the packet >size increase, and found it to be not all that large (on the order of >10%?). The number is probably a bit higher, but a lot depends on your application mix. ESP with a 12-byte authentication code adds 22 bytes plus enough more to bring the total of the ESP stuff plus the packet to a multiple of 8 bytes today; 16 bytes in a year or two when we switch to AES from DES and 3DES. I then took that figure and applied it to some of the backbone traffic mix data that kc supplied me with. If you're sending mostly very short packets, the overhead is considerable. On the backbone, though ~40% of all packets are about 40 bytes long, most of the byte count is carried by MTU-sized packets. That drove the percentage overhead down. --Steve Bellovin From owner-aaa-bof@merit.edu Tue Apr 11 21:56:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA22786 for ; Tue, 11 Apr 2000 21:56:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 589255DDE0; Tue, 11 Apr 2000 21:56:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 390B25DDA7; Tue, 11 Apr 2000 21:56:15 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 961B75DD95 for ; Tue, 11 Apr 2000 21:56:04 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id SAA43877; Tue, 11 Apr 2000 18:42:13 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Richard Perlman'" , "'pcalhoun@eng.sun.com'" Cc: Subject: RE: NAS Reboot messages Date: Tue, 11 Apr 2000 18:57:47 -0700 Message-ID: <007f01bfa422$80e248e0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.3.1.2.20000412202938.00aad5c0@mail.yikes.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk OK. I'll add that to the list: "This requirement refers to the ability of the NAS to use the AAA server to manage resource allocation state. This capability can assist with, but it is not synonymous with, simultaneous user login control, port usage limitations, or IP address pooling. The design must provide for recovery from data loss due to a variety of faults, including NAS and AAA server reboots, and NAS/AAA server communication outages. The granularity of the recovery of state information after an outage may be on the order of a fraction of a minute. In order to provide for state recovery, the following capabilities are required: a. Re-authorization capabilities (described in []) b. Session disconnect message (described in []) c. Transport and application-layer reliability (described in []) d. An interim message (described in []). e. A mechanism for the AAA server to retrieve state information from the NAS. This mechanism will provide timely information though a complete state dump may not be immediately available. f. A NAS reboot message. g. Accounting On/Off messages. If non-volatile memory is present, it is believed that only elements a - c are needed. However, since this will not always be true, other mechanisms are also needed. Mechanism d provides recovery time on the order of the interim interval, and so may be too slow in many cases. Mechanisms e, f and g can be useful but are not implementable at Internet scale for use in applications such as roaming." -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Richard Perlman Sent: Wednesday, April 12, 2000 12:35 PM To: pcalhoun@eng.sun.com; aboba@internaut.com Cc: aaa-wg@merit.edu Subject: NAS Reboot messages Pat: I had sent an earlier message to the list regarding the possible need for the equivalent of the RADIUS Accounting On/Off messages. I did not see any discussion so there may be good reasons not to do it. But, barring any good reason not to, I think On/Off messages are probably necessary for times when accounting may be suspended but the NAS does not actually re-boot. Technically, an Accounting Off message is not needed since an Accounting On message implies that it had been off. However, the time interval may be great and it is probably best to notify the AAA server(s) as soon as possible. Richard At 03:11 PM 04/11/2000, pcalhoun@eng.sun.com wrote: >OK, this seems to be in line with rough concensus. Go ahead and update the >draft with the text below. At a minimum, it at least now describes exactly >what we want. > >Now on to updating my Resource-Management draft... > >PatC > > > How about this: > > f. A NAS reboot message. From owner-aaa-bof@merit.edu Tue Apr 11 22:54:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA23526 for ; Tue, 11 Apr 2000 22:54:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F2F375DDB3; Tue, 11 Apr 2000 22:54:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E227F5DDAA; Tue, 11 Apr 2000 22:54:02 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 9FE165DDA7 for ; Tue, 11 Apr 2000 22:53:57 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id TAA44024 for ; Tue, 11 Apr 2000 19:40:42 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: -03 version of NA reqts Date: Tue, 11 Apr 2000 19:56:20 -0700 Message-ID: <008601bfa42a$af2914b0$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk The -03 version of the network reqts. doc is available for your inspection. This fixes some spelling mistakes and adds the language on state reconciliation. There were no changes for Mobile IP/TIA reconciliation. If you feel there is something missing or that needs changing, please speak up NOW. http://www.drizzle.com/~aboba/AAA/REQTS/draft-ietf-aaa-na-reqts-03.txt From owner-aaa-bof@merit.edu Wed Apr 12 10:51:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03873 for ; Wed, 12 Apr 2000 10:51:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A65865DDA5; Wed, 12 Apr 2000 10:50:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8EFFA5DDB5; Wed, 12 Apr 2000 10:50:41 -0400 (EDT) Received: from firewall.metratech.com (firewall.metratech.com [199.171.52.2]) by segue.merit.edu (Postfix) with SMTP id A97225DDA5 for ; Wed, 12 Apr 2000 10:50:38 -0400 (EDT) Received: from CHARLES by firewall.metratech.com via smtpd (for segue.merit.edu [198.108.1.41]) with SMTP; 12 Apr 2000 14:52:30 UT Received: by charles.metratech.com with Internet Mail Service (5.5.2650.21) id ; Wed, 12 Apr 2000 10:54:43 -0400 Message-ID: <2F618EE0FED7D31198B2009027DE338B02C3D5@charles.metratech.com> From: Alan Blount To: "'pcalhoun@eng.sun.com'" , aaa-wg@merit.edu Subject: RE: Comments on draft-eitf-aaa-accounting-attributes-02.txt Date: Wed, 12 Apr 2000 10:54:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks for the edits Pat. > 1. Section 4.2 > > The text reads: > "The DIAMETER Policy and Accounting Extension for SIP (Session Initia- > tion Protocol) document [DIAM-SIP] extends DIAMETER by adding a pol- > icy and accounting information exchange mechanism between a DIAMETER > policy server and a SIP proxy server." > I am not sure what the benefit of the above paragraph really is. This is a > draft that must have expired at least a year ago, and was the first attempt at > getting SIP as a supported extension. The DIAMETER protocol has changed > considerably since then, and the accounting extension specifies that any > accounting records be carries within an ADIF-Record AVP. Agreed. ... > If you prefer to use an application that is currently well defined, and > supported, I would propose Mobile IP. However, since it uses the ADIF-Record, > I'm not sure what the benefit of adding more detail would be. I'll defer to Nevil on what, if anything, we want to add as a replacement. > So, the following paragraph is also obsoleted: > "A DIAMETER server is responsible for maintaining a user policy and > accounting database and a means to update it. A SIP proxy server > needs to contact a DIAMETER server during multimedia session setup > and teardown time to perform admission control and accounting tasks. > The exchange mechanism protocol does not make any assumption about > policy and billing algorithms at DIAMETER servers." Agreed. > 2. Section 7.2.2. > The header format is incorrect (I suspect the header was pulled from the SIP > draft, which was REALLY old). Here is the format from the latest draft: Looks like a serious case of draft rot had set in. I incorporated the new header and description. > 3. Section 9.2.1. > > This section lists the data types supported by DIAMETER, but fails to list the > Complex type, which may be used to encode structures. Actually, as written, it lists the *primitive* types supported by DIAMETER. I suppose it's a matter of definition whether Complex is considered primitive. Nevertheless, I'll put it in. Looks like something that was added between the -08 and -13 DIAMETER Base Protocol draft. I know that this is the right venue for the discussion, but did you consider using ISO8601 timestamps rather than unixtime? I know the world runs on unixtime, but the ISO8601's built-in timezone facility and rollover immunity does make it appealing. Thanks again Pat. Alan From owner-aaa-bof@merit.edu Thu Apr 13 06:52:48 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA22871 for ; Thu, 13 Apr 2000 06:52:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCA8B5DD96; Thu, 13 Apr 2000 06:52:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A20C15DDB5; Thu, 13 Apr 2000 06:52:27 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 71D785DD96 for ; Thu, 13 Apr 2000 06:52:26 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26157; Thu, 13 Apr 2000 06:52:25 -0400 (EDT) Message-Id: <200004131052.GAA26157@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-na-reqts-03.txt Date: Thu, 13 Apr 2000 06:52:25 -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart 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 : Criteria for Evaluating AAA Protocols for Network Access Author(s) : B. Aboba et al. Filename : draft-ietf-aaa-na-reqts-03.txt Pages : 27 Date : 12-Apr-00 This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ, ROAMOPS, and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.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-na-reqts-03.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-na-reqts-03.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" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000412124642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-na-reqts-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-na-reqts-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000412124642.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Thu Apr 13 21:18:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA06606 for ; Thu, 13 Apr 2000 21:18:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B8B35DDAB; Thu, 13 Apr 2000 21:15:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5B6B05DD9D; Thu, 13 Apr 2000 21:15:30 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 0CCC05DD96 for ; Thu, 13 Apr 2000 21:15:26 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id SAA46651 for ; Thu, 13 Apr 2000 18:02:02 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-na-reqts-03.txt Date: Thu, 13 Apr 2000 18:17:46 -0700 Message-ID: <015501bfa5af$3e95fca0$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is the AAA Working Group last call on draft-ietf-aaa-na-reqts-03.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 April 28. http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt From owner-aaa-bof@merit.edu Fri Apr 14 00:05:30 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id AAA08793 for ; Fri, 14 Apr 2000 00:05:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CA825DE15; Fri, 14 Apr 2000 00:05:07 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2BB505DDED; Fri, 14 Apr 2000 00:05:07 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 038E65DDED for ; Fri, 14 Apr 2000 00:04:58 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id UAA46858 for ; Thu, 13 Apr 2000 20:51:29 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP Date: Thu, 13 Apr 2000 21:07:14 -0700 Message-ID: <016101bfa5c6$eb77ae20$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP The Authentication, Authorization and Accounting (AAA) Working Group of the Internet Engineering Task Force is currently soliciting submission of protocols for authentication, authorization and accounting as applied to network access. Submissions are being solicited effective immediately. Authors of candidate protocols are required to notify the AAA WG chairs, Bernard Aboba and Paul Krumviede of their intent to submit a candidate protocol. It is desirable that this notification be sent by May 1, 2000. Protocol submissions and compliance description documents are to be submitted in Internet Draft format by email to internet-drafts@ietf.org. The deadline for submissions is June 1, 2000. To be considered as a candidate, submissions must include an unqualified RFC 2026 statement, as described at: http://www.ietf.org/Sec10.txt Information on the Internet Draft format is available at: http://www.ietf.org/ietf/1id-guidelines.txt The compliance description document must explain on a detailed requirement-by-requirement basis how the submitted protocol satisfies the AAA network access requirements. The requirements are available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt (or later version). The protocol submission and compliance description documents will then be used as the basis for an independent evaluation. Based on the results of the independent evaluation, the working group will decide whether one or more submissions meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a protocol from scratch. In the protocol development process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development. Authors of candidate protocols must be willing to give up change control to the IETF, so as to allow modification of the candidate protocols to AAA WG needs. For further information on the IETF AAA WG, including working group drafts and milestones, please consult the working group web page at: http://www.ietf.org/html.charters/aaa-charter.html From owner-aaa-bof@merit.edu Fri Apr 14 09:40:14 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA16755 for ; Fri, 14 Apr 2000 09:40:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D847F5DE0C; Fri, 14 Apr 2000 09:39:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C33B65DE0D; Fri, 14 Apr 2000 09:39:49 -0400 (EDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by segue.merit.edu (Postfix) with ESMTP id DC9C25DE0C for ; Fri, 14 Apr 2000 09:39:48 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id 58E7C1E02E; Fri, 14 Apr 2000 09:39:48 -0400 (EDT) Received: from smb.research.att.com (secure.research.att.com [135.207.25.14]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id JAA03354; Fri, 14 Apr 2000 09:39:36 -0400 (EDT) Received: from smb.research.att.com (localhost.research.att.com [127.0.0.1]) by smb.research.att.com (Postfix) with ESMTP id 7F65835DC2; Fri, 14 Apr 2000 09:39:26 -0400 (EDT) X-Mailer: exmh version 2.1.1 10/15/1999 From: "Steven M. Bellovin" To: Paul Krumviede , Patzer Robert-RPATZER1 , aaa-wg@merit.edu Subject: Re: IPSec Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 14 Apr 2000 09:38:57 -0400 Message-Id: <20000414133926.7F65835DC2@smb.research.att.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk I realized that I missed some overhead -- there's another ciphertext block (i.e., 8 bytes today; 16 bytes with AES) of overhead as well. > >The number is probably a bit higher, but a lot depends on your application mix >. > >ESP with a 12-byte authentication code adds 22 bytes plus enough more to bring > >the total of the ESP stuff plus the packet to a multiple of 8 bytes today; 16 >bytes in a year or two when we switch to AES from DES and 3DES. I then took >that figure and applied it to some of the backbone traffic mix data that kc >supplied me with. > >If you're sending mostly very short packets, the overhead is considerable. On > >the backbone, though ~40% of all packets are about 40 bytes long, most of the >byte count is carried by MTU-sized packets. That drove the percentage >overhead down. > > --Steve Bellovin > > --Steve Bellovin From owner-aaa-bof@merit.edu Fri Apr 14 11:33:43 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id LAA18631 for ; Fri, 14 Apr 2000 11:33:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3D725DE0E; Fri, 14 Apr 2000 11:32:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E28D85DE0D; Fri, 14 Apr 2000 11:32:00 -0400 (EDT) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id A73C55DE05 for ; Fri, 14 Apr 2000 11:31:59 -0400 (EDT) Received: by backin5.merit.edu (Postfix) id ADDDAA9503; Fri, 14 Apr 2000 11:31:59 -0400 (EDT) Received: from Merit.edu (dwspencelaptop.merit.edu [198.108.62.148]) by backin5.merit.edu (Postfix) with ESMTP id 7D232A9501; Fri, 14 Apr 2000 11:31:59 -0400 (EDT) Message-ID: <38F739EE.9B8B6961@Merit.edu> Date: Fri, 14 Apr 2000 11:31:59 -0400 From: "David W. Spence" Organization: Merit Network, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" Cc: aaa-wg@merit.edu Subject: Re: State Reconciliation Requirement References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, I remember studying the "Resource Management Extensions" draft a while ago when it was more current. As I recall, there were a lot of unanswered questions regarding how to use the extension in a multi-domain environment. I began thinking at that time about what rules would need to be added to generalize to the multi-domain case, and I believe I concluded that it really could be made to work. I think there are some differences between the Diameter resource management approach and the Michnet approach, advantages and disadvantages on either side. This isn't the time to work it all out. The point I want to make here is simply that different mechanisms have different advantages and therefore we should consider the merits of different approaches before spending too much time on the details. Then, whatever protocol we use as a starting point, I think we can gain most of the features we really want in the end. To illustrate what I mean by different approaches having different advantages, here are some thoughts on the advantages and disadvantages of the Diameter Resource Management Extensions approach. Disclaimer: I am really not pushing the Merit approach, based as it is on ad hoc mechanisms that we resorted to because of difficiencies in the base AAA protocol! I merely use it to illustrate certain things. Advantages of the Diameter Resource Management Extensions: 1. Each AAA server can determine the exact content of the state information it needs to save regarding the sessions it is tracking. An AAA server sends a state object to another AAA server for storage, but the object need not be (and is not) meaningful to the AAA server receiving and storing it. 2. By sending the state information down toward the resource itself, ultimately all state information required by any AAA entity can be stored in the equipment that directly manages the resource. The advantage here is that anything that can cause loss of the state information will, in all probability disrupt the use of the resource itself. For instance, if the NAS crashes, the stored state information may be lost, but that doesn't matter because the session will be terminated as well. Disadvantages of the Diameter Resource Management Extensions: 1. It is possible that the state objects that AAA servers will need to store will be too large to conveniently transmit through multiple domains all the way down to the poor service equipment. It may be necessary to store most state information locally and for the AAA protocol merely to exchange a small amount of keepalive information in order to maintain state synchronization. 2. The Diameter Resource Management model requires a server to know all possible entities which may be holding state information for it. A rebooted server may need to send Session-Resource-Query messages to a very large number of entities, most of which will not have any current state information for it. In the Merit approach, keepalives are sent in the other direction. You always know who you have information for. If you've lost state, you may not know who has information for you. It's a scalability issue. I think no matter what protocol we use as a starting point, we should be prepared to consider every part of it and make changes as desirable. Dave S. "pcalhoun@eng.sun.com" wrote: > > Dave, > > An excellent tutorial on MichNet's NAS manager. I would not, however, that > there is code that *can* be found in the Merit AAA Server that provides state > re-synchronization. This is the basis for the DIAMETER Resource Management > Internet-Draft. I will expand a little here to help (at a 50K foot view) ... > > The draft contains three features: > > 1. Session-Free-Request/Answer - Sent when a session is terminated > > 2. Session-Resource-Query/Response - Query a peer to get a snapshot of a > peer's > current state > > 3. Resource-Reclaim-Request - Sent to request that a NAS terminate a session > (not relevant for the purposes of this discussion). > > So, the basic idea is that when a user is auth*, the home server generates a > token. This token MAY be signed to eliminate forgery. When a user terminates > his/her session, a Session-Free-Request is sent by the NAS to the home server > (through a proxy chain). > > Now, it is assumed that each first hop server maintains state information of > what sessions are currently active on the respective NASes. The home servers > ALSO maintain state information for all active users. When a local proxy > crashes, it issues a Session-Resource-Query message to all of its NASes, and > receives the state information. The Home Server can do the same by querying > all first hop servers. > > So, the above appears to provide a similar amount of granularity as the > MichNet implementation, but using the AAA protocol instead of some out-of-band > protocol. > > If the above is deemed necessary, then we (as a WG) need to agree. I will not > be running the actual networks, so I'm not sure that my opinion really > matters. If we need it, it certainly is simple for me. > > PatC -- David W. Spence email: DWSpence@Merit.edu Senior Systems Research Programmer phone: (734) 615-2630 Merit Network, Inc. fax: (734) 647-3745 4151 Plymouth Road, Suite C Ann Arbor MI 48105-2785 U.S.A. From owner-aaa-bof@merit.edu Fri Apr 14 12:33:39 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA19426 for ; Fri, 14 Apr 2000 12:33:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 203AE5DDFF; Fri, 14 Apr 2000 12:31:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 070F75DE01; Fri, 14 Apr 2000 12:31:10 -0400 (EDT) Received: from backin5.merit.edu (backin5.merit.edu [198.108.60.28]) by segue.merit.edu (Postfix) with ESMTP id 275645DDFF for ; Fri, 14 Apr 2000 12:31:09 -0400 (EDT) Received: by backin5.merit.edu (Postfix) id 1D8BBA9503; Fri, 14 Apr 2000 12:31:09 -0400 (EDT) Received: from Merit.edu (dwspencelaptop.merit.edu [198.108.62.148]) by backin5.merit.edu (Postfix) with ESMTP id DADEEA9501; Fri, 14 Apr 2000 12:31:08 -0400 (EDT) Message-ID: <38F747CC.44F8F2BB@Merit.edu> Date: Fri, 14 Apr 2000 12:31:08 -0400 From: "David W. Spence" Organization: Merit Network, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: aboba@internaut.com Cc: aaa-wg@merit.edu Subject: Re: State Reconciliation Requirement References: <010a01bfa364$3a973b70$428939cc@ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Bernard Aboba wrote: > > Thanks for the summary -- great posting. Based on your > experience, can we boil the requirements for state > reconcilation down to a paragraph or two that we > can insert in the NA requirements draft, so that we > can bring it to WG last call again? Bernard, I think the requirement wording in your previous memo pretty well covers my concerns. I think it possible that for point d, "An interim message", one may want to consider two interim messages: 1) an interim accounting message, and 2) and interim state synchronization message. The second might contain less information per session and be sent on a more frequent interval. But on thinking about it some more, I believe it really gets down to questions of protocol design that are best left out of the requirements document. If we can agree to interpret "an interim message" somewhat broadly, then I really believe your text covers what we want. -- David W. Spence email: DWSpence@Merit.edu Senior Systems Research Programmer phone: (734) 615-2630 Merit Network, Inc. fax: (734) 647-3745 4251 Plymouth Road, Suite 2000 Ann Arbor MI 48105-2785 U.S.A. From owner-aaa-bof@merit.edu Fri Apr 14 14:06:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA21241 for ; Fri, 14 Apr 2000 14:06:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C60285DDD6; Fri, 14 Apr 2000 14:06:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B64E55DDA7; Fri, 14 Apr 2000 14:06:01 -0400 (EDT) Received: from caida.org (ipn.caida.org [192.172.226.30]) by segue.merit.edu (Postfix) with ESMTP id 5BDDD5DDA3 for ; Fri, 14 Apr 2000 14:06:00 -0400 (EDT) Received: from localhost (nevil@localhost) by caida.org (8.8.8/8.7.3) with ESMTP id LAA21264; Fri, 14 Apr 2000 11:05:52 -0700 (PDT) Date: Fri, 14 Apr 2000 11:05:52 -0700 (PDT) From: Nevil Brownlee To: Alan Blount , "'pcalhoun@eng.sun.com'" Cc: aaa-wg@merit.edu Subject: RE: Comments on draft-eitf-aaa-accounting-attributes-02.txt In-Reply-To: <2F618EE0FED7D31198B2009027DE338B02C3D5@charles.metratech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello Alan and Pat: Thanks for your comments on the Accounting Attributes I-D. Pat's comments about the [DIAM-SIP] paragraphs are correct, we should delete both of them, *** and delete [DIAM-SIP] from the list of references ***. I agree with Pat that there's no point in trying to add more detail in that section. Thanks also for the updated DIAMETER header format (7.2.2), and the suggestion about complex type (9.2.1). Looking back, I see that I wrote the original text of 'Accounting Attributes' back in May 99, then failed to keep checking the I-Ds it referenced when doing updates. As Alan said, it's a clear case of acute draft rot (what a beautiful description!). It just reinforces the need for I-D authors to be careful when editing, and for effective feedback from the mailing list(s) :-) Cheers, Nevil ------------------------------------------------------------- Nevil Brownlee Visiting Researcher Phone: (858) 822 0893 CAIDA, San Diego From owner-aaa-bof@merit.edu Fri Apr 14 17:37:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id RAA24314 for ; Fri, 14 Apr 2000 17:37:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D12575DDFB; Fri, 14 Apr 2000 17:36:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B31EF5DDFA; Fri, 14 Apr 2000 17:36:40 -0400 (EDT) Received: from castor.ntd.comsat.com (castor.ntd.comsat.com [134.133.80.100]) by segue.merit.edu (Postfix) with ESMTP id A8C565DDA3 for ; Fri, 14 Apr 2000 17:36:39 -0400 (EDT) Received: from alexar (ALEXAR.stg.comsat.com [134.133.52.97]) by castor.ntd.comsat.com (8.9.1/8.9.1) with SMTP id RAA25865 for ; Fri, 14 Apr 2000 17:36:33 -0400 (EDT) From: "Roger K. Alexander" To: Subject: FW: DIAMETER Related PPP Changes Date: Fri, 14 Apr 2000 17:37:04 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01BFA638.0C3061E0" 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.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_001C_01BFA638.0C3061E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Dear All, In reviewing the DIAMETER Framework Document it is noted in section 2.11 (on page 12) that within the current RADIUS model a potential weakness is introduced in the CHAP authentication process in an inter-domain environment in which the Network Access Server (NAS) performs the Challenge that is then validated at a remote ‘home’ server. “[T]he fact that the non-trusted NAS generates a challenge provides the ability for authentication replay attacks.” This is indeed correct. To overcome this problem the authentication Challenge needs to originate at ‘home’ DIAMETER server. Considering the requirement for a ‘home’ DIAMETER server Challenge within the context of the PPP protocol configured for CHAP authentication, the following problem emerges. Prior to the initial PPP Authentication Phase no user identification information is exchanged between the remote host (user) and the network access server. Thus the NAS CHAP Challenge is initiated in the ‘blind’ (without knowledge of the user ID), which does not create a problem at this initial stage of link establishment. User identification is first provided within the “Name” field of the Response message sent in response to the Challenge. Within the current PPP implementation therefore it is only after the Challenge has been responded to that the NAS has the identity of the user. In the event that the DIAMETER protocol wishes to support a ‘home’ server initiated Challenge, the NAS will need to know the identity of the remote (host) user before the Authentication Phase can be entered (so that a Challenge can be obtained). While EAP makes provisions for such a specific Identity Request, CHAP does not. A possible solution would be to issue a blind Challenge as is currently done (potentially with a specifically chosen Challenge Value such as ‘all zeros’), ignore the content of the Value field (if necessary) within the Response message, and use the Name field information provided to derive the ‘home’ DIAMETER server. While this can be made to work it also introduces additional delays in the PPP link establishment process that is compounded by the additional delay to signal to the ‘home’ server which may reside across the Internet. A preferred approach would be to specify UserID (such as NAI) as a configuration option within the PPP Configure Request message so that user information is obtained earlier and without additional signaling exchanges. Early user identification could also have other potential system benefits such as early screening of user access. I would be interested in getting some feedback as to whether this issue has been raised and how it might be addressed. My concern stems from a desire to incorporate the DIAMETER protocol and infrastructure into the design of a future global mobile satellite system. I would also appreciate any pointers to other working groups where such an issue might be addressed. Thanks. Roger ------=_NextPart_000_001C_01BFA638.0C3061E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear All,

 

In reviewing the DIAMETER Framework Document it is noted in section 2.11 = (on page 12) that within the current RADIUS model a potential weakness is = introduced in the CHAP authentication process in an inter-domain environment in which = the Network Access Server (NAS) performs the Challenge that is then = validated at a remote ‘home’ server. “[T]he fact that the non-trusted = NAS generates a challenge provides the ability for authentication replay attacks.” = This is indeed correct. To overcome this problem the authentication Challenge = needs to originate at ‘home’ DIAMETER server. =

 

Considering the requirement for a ‘home’ DIAMETER server Challenge = within the context of the PPP protocol configured for CHAP authentication, the following = problem emerges. Prior to the initial PPP Authentication Phase no user = identification information is exchanged between the remote host (user) and the network = access server. Thus the NAS CHAP Challenge is initiated in the = ‘blind’ (without knowledge of the user ID), which does not create a problem at this = initial stage of link establishment. User identification is first provided = within the “Name” field of the Response message sent in response to the = Challenge. Within the current PPP implementation therefore it is only after the Challenge = has been responded to that the NAS has the identity of the = user.

 

In the event that the DIAMETER protocol wishes to support a = ‘home’ server initiated Challenge, the NAS will need to know the identity of the = remote (host) user before the Authentication Phase can be entered (so that a = Challenge can be obtained). While EAP makes provisions for such a specific = Identity Request, CHAP does not. A possible solution would be to issue a blind = Challenge as is currently done (potentially with a specifically chosen Challenge = Value such as ‘all zeros’), ignore the content of the Value field = (if necessary) within the Response message, and use the Name field information provided = to derive the ‘home’ DIAMETER server. While this can be made to = work it also introduces additional delays in the PPP link establishment process that = is compounded by the additional delay to signal to the ‘home’ = server which may reside across the Internet. A preferred approach would be to specify = UserID (such as NAI) as a configuration option within the PPP Configure Request message so that user information is obtained earlier and without = additional signaling exchanges. Early user identification could also have other = potential system benefits such as early screening of user access. =

 

I would be interested in getting some feedback as to whether this issue = has been raised and how it might be addressed. My concern stems from a desire to incorporate the DIAMETER protocol and infrastructure into the design of = a future global mobile satellite system. I would also appreciate any = pointers to other working groups where such an issue might be = addressed.

 

Thanks.

 

Roger=

------=_NextPart_000_001C_01BFA638.0C3061E0-- From owner-aaa-bof@merit.edu Fri Apr 14 19:18:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id TAA25435 for ; Fri, 14 Apr 2000 19:18:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 55F455DDA7; Fri, 14 Apr 2000 19:16:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 434345DDA6; Fri, 14 Apr 2000 19:16:01 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by segue.merit.edu (Postfix) with ESMTP id CA1705DDA7 for ; Fri, 14 Apr 2000 19:15:59 -0400 (EDT) Received: from auemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA00840 for ; Fri, 14 Apr 2000 19:15:59 -0400 (EDT) Received: from ihgp24.ih.lucent.com (h135-1-53-29.lucent.com [135.1.53.29]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA00833 for ; Fri, 14 Apr 2000 19:15:58 -0400 (EDT) Received: by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA18836; Fri, 14 Apr 2000 18:15:58 -0500 (CDT) Cc: aaa-wg@merit.edu Received: from lucent.com by ihgp24.ih.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id SAA18831; Fri, 14 Apr 2000 18:15:55 -0500 (CDT) Message-ID: <38F7A6AA.50BA75C7@lucent.com> Date: Fri, 14 Apr 2000 18:15:54 -0500 From: Tom Hiller Organization: Lucent Technologies X-Mailer: Mozilla 4.6 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Original-CC: aaa-wg@merit.edu Subject: Re: Points raised by Tom Hiller at IETF References: Content-Type: multipart/mixed; boundary="------------F3D426EC3DB94DAD835642D9" Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. --------------F3D426EC3DB94DAD835642D9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, At the AAA meeting I summarized TR456 issues with the "Criteria for Evaluating AAA Protocols for Network Access" draft. The issues had to do with a few "shoulds" we considered as "musts". We agreed minor differences would be captured in footnotes for completeness. In all cases there were already "musts" in these rows in the other columns, so these are minor issues. The items are: Section 5.1 Data object confidentiality (e): M Certificate Transport (g): M Section 5.2 NAI Support (a): M Section 5.3 RADIUS Gateway (b): M Section 5.4 Accounting Time Stamps (e): M Thanks, Tom "pcalhoun@eng.sun.com" wrote: > > All, > > I am trying to figure out what to do with the issues that were raised by Tom > Hiller, that had to do with the mis-representation of the TR45.6 requirements > in the NA reqs doc. > > In combining the Mobile IP and the TR45.6 requirements, there were a few > mis-matches. In most cases, TR45.6 had a Must 'M', and Mobile IP had a SHOULD. > In these cases, either NASREQ or ROAMOPS had a Must 'M', which ensured that > the AAA protocol would get this feature. > > In the cases where TR45.6 had a different requirement than Mobile IP, and no > other application had the same level as TR45.6, I have two symbols in the > table under Mobile IP. See (shared secret not required) requirement as an > example. > > The question I have for the group is whether we should leave the document > as-is, or change them to include both requirement labels under Mobile IP when > needed (which I prefer NOT to do). > > PatC --------------F3D426EC3DB94DAD835642D9 Content-Type: text/x-vcard; charset=us-ascii; name="tom.hiller.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Tom Hiller Content-Disposition: attachment; filename="tom.hiller.vcf" begin:vcard n:Hiller;Tom tel;work:630-979-7673 x-mozilla-html:FALSE org:Lucent Technologies version:2.1 email;internet:tom.hiller@lucent.com title:3G Wireless Data Standards and Architecture adr;quoted-printable:;;263 Shuman Dr=0D=0ARm 2F-218;Naperville;IL;60566; fn:Tom Hiller end:vcard --------------F3D426EC3DB94DAD835642D9-- From owner-aaa-bof@merit.edu Sat Apr 15 15:22:25 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09569 for ; Sat, 15 Apr 2000 15:22:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08A3F5DDB6; Sat, 15 Apr 2000 15:22:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DF2CC5DDBB; Sat, 15 Apr 2000 15:22:05 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 4778C5DDB6 for ; Sat, 15 Apr 2000 15:22:01 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id MAA54495; Sat, 15 Apr 2000 12:08:22 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Tom Hiller'" Cc: Subject: RE: Points raised by Tom Hiller at IETF Date: Sat, 15 Apr 2000 12:26:39 -0700 Message-ID: <001501bfa710$871f8b50$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38F7A6AA.50BA75C7@lucent.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Can you provide specific text that you would like inserted in the footnotes? -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of Tom Hiller Sent: Friday, April 14, 2000 4:16 PM Cc: aaa-wg@merit.edu Subject: Re: Points raised by Tom Hiller at IETF Hi, At the AAA meeting I summarized TR456 issues with the "Criteria for Evaluating AAA Protocols for Network Access" draft. The issues had to do with a few "shoulds" we considered as "musts". We agreed minor differences would be captured in footnotes for completeness. In all cases there were already "musts" in these rows in the other columns, so these are minor issues. The items are: Section 5.1 Data object confidentiality (e): M Certificate Transport (g): M Section 5.2 NAI Support (a): M Section 5.3 RADIUS Gateway (b): M Section 5.4 Accounting Time Stamps (e): M Thanks, Tom "pcalhoun@eng.sun.com" wrote: > > All, > > I am trying to figure out what to do with the issues that were raised by Tom > Hiller, that had to do with the mis-representation of the TR45.6 requirements > in the NA reqs doc. > > In combining the Mobile IP and the TR45.6 requirements, there were a few > mis-matches. In most cases, TR45.6 had a Must 'M', and Mobile IP had a SHOULD. > In these cases, either NASREQ or ROAMOPS had a Must 'M', which ensured that > the AAA protocol would get this feature. > > In the cases where TR45.6 had a different requirement than Mobile IP, and no > other application had the same level as TR45.6, I have two symbols in the > table under Mobile IP. See (shared secret not required) requirement as an > example. > > The question I have for the group is whether we should leave the document > as-is, or change them to include both requirement labels under Mobile IP when > needed (which I prefer NOT to do). > > PatC From owner-aaa-bof@merit.edu Sat Apr 15 15:33:45 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA09702 for ; Sat, 15 Apr 2000 15:33:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A77375DDBB; Sat, 15 Apr 2000 15:32:14 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 943805DDFB; Sat, 15 Apr 2000 15:32:14 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id B0FA55DDBB for ; Sat, 15 Apr 2000 15:32:08 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id MAA54505; Sat, 15 Apr 2000 12:18:28 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Roger K. Alexander'" , Subject: RE: DIAMETER Related PPP Changes Date: Sat, 15 Apr 2000 12:36:45 -0700 Message-ID: <001601bfa711$f0049ce0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0017_01BFA6D7.43A8D220" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0017_01BFA6D7.43A8D220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The place to take this discussion is the PPPEXT WG. The AAA WG does not own the PPP specifications. Our only concern is whether AAA can support the relevant PPP authentication methods. I believe that this is adequately reflected in the requirements document. For example, via EAP-MD5 it is possible today for a AAA server to initiate the challenge if desired. Also, there is nothing in PPP that prevents a NAS from acquiring a challenge value from a AAA server to use in PPP. The DNIS information can be used to route the request. ------=_NextPart_000_0017_01BFA6D7.43A8D220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 place to take this discussion is the PPPEXT WG. The AAA WG does not own = the PPP=20 specifications. Our only
concern is whether AAA can support the = relevant PPP=20 authentication methods. I believe that this is = adequately
reflected in the requirements document.=20
 
For=20 example, via EAP-MD5 it is possible today for a AAA server to = initiate the=20 challenge if desired. Also, there is nothing in PPP that prevents a NAS = from=20 acquiring a challenge value from a AAA server to use in PPP.  The = DNIS=20 information can be used to route the request.
------=_NextPart_000_0017_01BFA6D7.43A8D220-- From owner-aaa-bof@merit.edu Sun Apr 16 18:48:37 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA26489 for ; Sun, 16 Apr 2000 18:48:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 461105DDB4; Sun, 16 Apr 2000 18:46:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 297D95DDB0; Sun, 16 Apr 2000 18:46:17 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 9E29C5DD98 for ; Sun, 16 Apr 2000 18:46:11 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id PAA55943 for ; Sun, 16 Apr 2000 15:32:29 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: Dates of interest Date: Sun, 16 Apr 2000 15:51:06 -0700 Message-ID: <000101bfa7f6$41b3f790$428939cc@ntdev.microsoft.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 CWS, 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 The Solicitation of Protocol Submissions has been sent out and so over the next few weeks it is important that we wrap up loose ends on our existing drafts to that we can move on to the next phase of our work. Now is the time to read the drafts and comment on them to the list. If you are an author, now is the time to incorporate those comments and reissue the drafts. Find below a list of some of the important dates that are coming up in the months ahead. Date Explanation ================ ======================================= April 28, 2000: Expiration of WG last call on: http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt May 1, 2000: Notification of intent to submit a AAA protocol draft May 15, 2000: Target for completion of WG last call on current AAA WG drafts. June 1, 2000: Deadline for submission of AAA protocol drafts and Compliance Descriptions July 4, 2000: Holiday (USA) July 14, 2000: Submission deadline for IETF 48 July 30 - August 4, 2000: IETF 48, Pittsburgh, see: http://www.ietf.org/meetings/meetings.html From owner-aaa-bof@merit.edu Sun Apr 16 18:49:57 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id SAA26544 for ; Sun, 16 Apr 2000 18:49:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E8BF5DDB0; Sun, 16 Apr 2000 18:49:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0D9385DD9E; Sun, 16 Apr 2000 18:49:24 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 7FF9C5DD98 for ; Sun, 16 Apr 2000 18:49:19 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id PAA55952 for ; Sun, 16 Apr 2000 15:35:41 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: AAA WG Last Call on draft-ietf-aaa-accounting-attributes-03.txt Date: Sun, 16 Apr 2000 15:54:19 -0700 Message-ID: <000201bfa7f6$b3b32a00$428939cc@ntdev.microsoft.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 CWS, 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 This is the AAA Working Group last call on draft-ietf-aaa-accounting-attributes-03.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 May 2, 2000. http://www.ietf.org/internet-drafts/draft-ietf-aaa-accounting-attributes-03. txt From owner-aaa-bof@merit.edu Mon Apr 17 06:48:49 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id GAA05253 for ; Mon, 17 Apr 2000 06:48:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEF835DDAC; Mon, 17 Apr 2000 06:47:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC1805DDC0; Mon, 17 Apr 2000 06:47:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 7A5CB5DDAC for ; Mon, 17 Apr 2000 06:47:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28493; Mon, 17 Apr 2000 06:47:26 -0400 (EDT) Message-Id: <200004171047.GAA28493@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: aaa-wg@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-aaa-accounting-attributes-03.txt Date: Mon, 17 Apr 2000 06:47:26 -0400 Sender: owner-aaa-bof@merit.edu Precedence: bulk --NextPart 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 : Accounting Attributes and Record Formats Author(s) : N. Brownlee, A. Blount Filename : draft-ietf-aaa-accounting-attributes-03.txt Pages : 30 Date : 14-Apr-00 This draft summarises IETF and ITU-T documents related to Accounting. A classification scheme for the Accounting Attributes in the summarised documents is presented. Exchange formats for Accounting data records are discussed, as are advantages and disadvantages of integrated versus separate record formats and transport protocols. This draft discusses service definition independence, extensibility, and versioning. Compound service definition capabilities are described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-aaa-accounting-attributes-03.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-accounting-attributes-03.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-accounting-attributes-03.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" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000414144414.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-aaa-accounting-attributes-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-aaa-accounting-attributes-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000414144414.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-aaa-bof@merit.edu Mon Apr 17 09:03:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA07095 for ; Mon, 17 Apr 2000 09:03:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7C4655DDBB; Mon, 17 Apr 2000 09:00:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 659225DDC2; Mon, 17 Apr 2000 09:00:57 -0400 (EDT) Received: from smtpgw2.sprintspectrum.com (smtpgw2.sprintspectrum.com [208.18.119.43]) by segue.merit.edu (Postfix) with ESMTP id B81A45DDBB for ; Mon, 17 Apr 2000 09:00:55 -0400 (EDT) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw2.sprintspectrum.com (8.9.3/8.9.3) with ESMTP id IAA08270; Mon, 17 Apr 2000 08:00:53 -0500 (CDT) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2650.21) id <2V94HC23>; Mon, 17 Apr 2000 08:00:53 -0500 Message-ID: <2D11BCC7FFD8D3118FD70000D1ECDC88011D5A25@pkcexv018.sprintspectrum.com> From: "Lipford, Mark" To: "'Tom Hiller'" Cc: aaa-wg@merit.edu Subject: RE: Points raised by Tom Hiller at IETF Date: Mon, 17 Apr 2000 08:00:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk As a member of TR45.6 I concur with Tom's statement -----Original Message----- From: Tom Hiller [mailto:tom.hiller@lucent.com] Sent: Friday, April 14, 2000 6:16 PM Cc: aaa-wg@merit.edu Subject: Re: Points raised by Tom Hiller at IETF << File: Card for Tom Hiller >> Hi, At the AAA meeting I summarized TR456 issues with the "Criteria for Evaluating AAA Protocols for Network Access" draft. The issues had to do with a few "shoulds" we considered as "musts". We agreed minor differences would be captured in footnotes for completeness. In all cases there were already "musts" in these rows in the other columns, so these are minor issues. The items are: Section 5.1 Data object confidentiality (e): M Certificate Transport (g): M Section 5.2 NAI Support (a): M Section 5.3 RADIUS Gateway (b): M Section 5.4 Accounting Time Stamps (e): M Thanks, Tom "pcalhoun@eng.sun.com" wrote: > > All, > > I am trying to figure out what to do with the issues that were raised by Tom > Hiller, that had to do with the mis-representation of the TR45.6 requirements > in the NA reqs doc. > > In combining the Mobile IP and the TR45.6 requirements, there were a few > mis-matches. In most cases, TR45.6 had a Must 'M', and Mobile IP had a SHOULD. > In these cases, either NASREQ or ROAMOPS had a Must 'M', which ensured that > the AAA protocol would get this feature. > > In the cases where TR45.6 had a different requirement than Mobile IP, and no > other application had the same level as TR45.6, I have two symbols in the > table under Mobile IP. See (shared secret not required) requirement as an > example. > > The question I have for the group is whether we should leave the document > as-is, or change them to include both requirement labels under Mobile IP when > needed (which I prefer NOT to do). > > PatC From owner-aaa-bof@merit.edu Tue Apr 18 09:52:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA25859 for ; Tue, 18 Apr 2000 09:52:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 688C65DDD5; Tue, 18 Apr 2000 09:52:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57E0E5DDD2; Tue, 18 Apr 2000 09:52:12 -0400 (EDT) Received: from it-mail.com (it-mail.com [196.25.125.3]) by segue.merit.edu (Postfix) with ESMTP id EE6045DDC8 for ; Tue, 18 Apr 2000 09:50:56 -0400 (EDT) Received: by it-mail.com from localhost (router,SLMail V2.7); Tue, 18 Apr 2000 15:11:04 +0200 Received: by it-mail.com from chris (196.25.125.16::mail daemon; unverified,SLMail V2.7); Tue, 18 Apr 2000 15:09:33 +0200 From: "Dave Peters" To: Received: from SMTP.XServer (Smail4.1.19.1 #20) id m0wBzN7-009vdR; Tuesday, April 18th, 2000 Received: from mail.apache.net(really [164/187]) by relay.comanche.com Sunday, April 16th, 2000 Received: from 32776.21445(really [80110/80111]) by relay.denmark.nl Friday, April 14th, 2000 Received: from local.nethost.org(really [24553/24554]) by relay.SS621.net Thursday, April 13th, 2000 Message-Id: <19943672.886214@relay.comanche.denmark.eu> Wednesday, April 19th, 2000 Reply-To: "Acc" Subject: Microsoft Office Accounting Program Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Apr 2000 15:11:04 +0200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id JAA25859 Whilst browsing the internet, we were pleased to find your website http://www.ietf.org/html.charters/aaa-charter.html and believed that you may well be interested in the following. In today’s proliferation of so-called ‘unique’ and ‘value-added’ product offerings, one has to be discerning in choice of selection. One such product, namely the very popular and user-friendly ACCMATRIX ACCOUNTING software program, can indeed claim to offer unique value-added solutions in the accounting and knowledge management fields, significantly enhancing the financial control of any business, both small and large. The bottom line to any business-related purchase must always address cost savings and improved financial efficiency ACCMATRIX ACCOUNTING does just that! ACCMATRIX ACCOUNTING is a fully integrated, multi user client/server accounting software program developed with the power and flexibility of Microsoft technology. ACCMATRIX ACCOUNTING has been developed using Microsoft Excel as a front-end to Microsoft Access, Microsoft SQL and/or the Internet. Should you be interested in sourcing more information about Accmatrix Accounting, then please refer to our website http://www.it-key.com/accmatrix Thanking you in anticipation for your interest. Should you wish to be removed from the Accmatrix Accounting data base, then please type ‘remove’ in the subject, and return to sender. Yours truly Accmatrix Accounting From owner-aaa-bof@merit.edu Tue Apr 18 13:01:42 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28463 for ; Tue, 18 Apr 2000 13:01:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7A4155DEA0; Tue, 18 Apr 2000 12:59:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2CEE15DEE3; Tue, 18 Apr 2000 12:59:33 -0400 (EDT) Received: from monitor.internaut.com (mg-206253202-59.ricochet.net [206.253.202.59]) by segue.merit.edu (Postfix) with ESMTP id 8F1CD5DEA0 for ; Tue, 18 Apr 2000 12:59:17 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA58331; Tue, 18 Apr 2000 09:41:31 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: "'Lipford, Mark'" , "'Tom Hiller'" Cc: Subject: RE: Points raised by Tom Hiller at IETF Date: Tue, 18 Apr 2000 10:00:43 -0700 Message-ID: <006101bfa957$a35a0d60$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <2D11BCC7FFD8D3118FD70000D1ECDC88011D5A25@pkcexv018.sprintspectrum.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-aaa-bof@merit.edu Precedence: bulk Find enclosed a version of the draft which I think incorporates your desired edits. Please look it over carefully, checking that I have cited the relevant sections of the CDMA 2000 draft. http://www.drizzle.com/~aboba/AAA/REQTS/draft-ietf-aaa-na-reqts-04.txt Some issues: Section 5.1 Data object confidentiality (e): M Certificate Transport (g): M I am not clear about the appropriate references for these items. From owner-aaa-bof@merit.edu Tue Apr 18 13:15:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA28623 for ; Tue, 18 Apr 2000 13:15:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFD145DFDF; Tue, 18 Apr 2000 13:12:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8E7A55DE7D; Tue, 18 Apr 2000 13:12:25 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id A4F075DEE8 for ; Tue, 18 Apr 2000 13:12:09 -0400 (EDT) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21463; Tue, 18 Apr 2000 11:11:37 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.51.34]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA24958; Tue, 18 Apr 2000 10:09:50 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA27321; Tue, 18 Apr 2000 10:09:48 -0700 Date: Tue, 18 Apr 2000 10:09:48 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: RE: Points raised by Tom Hiller at IETF To: aboba@internaut.com Cc: "'Lipford, Mark'" , "'Tom Hiller'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <006101bfa957$a35a0d60$428939cc@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk It wasn't clear to me that Tom required any changes to the document. That was my question, and it wasn't really answered. Tom, do you want the -03 to change? PatC From owner-aaa-bof@merit.edu Thu Apr 20 01:25:32 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id BAA26252 for ; Thu, 20 Apr 2000 01:25:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8B5275DD8E; Thu, 20 Apr 2000 01:25:09 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 75F7B5DD8F; Thu, 20 Apr 2000 01:25:09 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id C9CAB5DD8E for ; Thu, 20 Apr 2000 01:25:07 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id IAA32115; Thu, 20 Apr 2000 08:25:06 +0300 (EEST) Message-ID: <38FE9507.51623A73@cc.hut.fi> Date: Thu, 20 Apr 2000 08:26:31 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: IETF AAA WG Subject: re-auth vs flexible auth? Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello! I was wondering whether the re-auhtenticatoin and re-authorization requirements should be modified in draft-ietf-aaa-na-reqts-04.txt. What is the difference between re-authentication and authentication, except that when re-authenticating, there may be a AAA session going on for the user already? I would rephrase the 're-' parts to be a part of general authentication and authorization requirements by satating something like: ----------------------------------------------------------- [e] The AAA protocol MUST allow for a protocol participant ^^^^^^^^^^^^^^^^^^^^^^^ to be authenticated at any time. ^^^^^^^^^^^^^^^^^^^^^^^^^^ The protocol MUST allow for this event to be triggered by either the user, access device (AAA client), or the home or visited AAA server. ----------------------------------------------------------- The 'user' in the original text (below) should be changed to something like 'protocol participant' or 'communicating party'. The current 'user' is not enough since the user may also want to authenticate the AAA server it is communicating with... The 'protocol participant' should be then defined somewhere to mean "the user, AAA Broker, access device (AAA client), or the home or visited AAA server." Alternatively this long list of elements could replace the term 'protocol participants'. A single term would be easier. When elements were added, only the definition should be changed instead of all the lists meaning the same thing... The same change from "re-doing" something should be changed in the authorization requirements. It MUST be possible to make the authorization any time, and that's it. The original text: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Re-authentication | M | | S | | on demand | 17 | | 30 33 | | e | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [e] The AAA protocol MUST allow for a user to be re-authenticated on- demand. The protocol MUST allow for this event to be triggered by either the user, access device (AAA client), or the home or visited AAA server. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | Re-Authorization on | M | | S | | demand | 18 | | 30 33 | | d | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [d] This requirement refers to the ability of the AAA client or server to trigger re-authorization, or to the ability of the server to send updated authorization information to the device, such as "stop service." Authorization can allow for a time period, then additional authorization can be sought to continue. A server can initially authorize a user to connect and receive services, but later decide the user is no longer allowed use of the service, for example after N minutes. Authorizations can have a time limit. Re- authorization does not necessarily imply re-authentication. Regards, Tom -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Thu Apr 20 09:48:31 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id JAA03366 for ; Thu, 20 Apr 2000 09:48:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 587E65DE2B; Thu, 20 Apr 2000 09:45:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4535C5DE15; Thu, 20 Apr 2000 09:45:45 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 779905DDCF for ; Thu, 20 Apr 2000 09:45:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19252 for ; Thu, 20 Apr 2000 07:45:42 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.93.34]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id GAA08097; Thu, 20 Apr 2000 06:45:40 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA27505; Thu, 20 Apr 2000 06:45:06 -0700 Date: Thu, 20 Apr 2000 06:45:05 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Re: re-auth vs flexible auth? To: "=?iso-8859-1?Q?Tom_K._Weckstr=F6m?=" Cc: IETF AAA WG In-Reply-To: "Your message with ID" <38FE9507.51623A73@cc.hut.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by nic.merit.edu id JAA03366 Tom, The spirit of your comment below is already covered by the requirement. Certainly we could play with words, but we all know exactly what this means. Further, it is well defined in the NASREQ criteria draft. My opinion, leave the doc as-is. PatC ---- > > Hello! > > I was wondering whether the re-auhtenticatoin and re-authorization > requirements should be modified in draft-ietf-aaa-na-reqts-04.txt. > > What is the difference between re-authentication and authentication, except > that when re-authenticating, there may be a AAA session going on for the > user already? > > I would rephrase the 're-' parts to be a part of general authentication and > authorization requirements by satating something like: > > ----------------------------------------------------------- > [e] The AAA protocol MUST allow for a protocol participant > ^^^^^^^^^^^^^^^^^^^^^^^ > to be authenticated at any time. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > The protocol MUST allow for this event to be triggered by > either the user, access device (AAA client), or the home or visited > AAA server. > ----------------------------------------------------------- > > The 'user' in the original text (below) should be changed to something like > 'protocol participant' or 'communicating party'. The current 'user' is not > enough since the user may also want to authenticate the AAA server it is > communicating with... > > The 'protocol participant' should be then defined somewhere to mean > "the user, AAA Broker, access device (AAA client), or the home or visited > AAA server." Alternatively this long list of elements could replace the term > 'protocol participants'. A single term would be easier. When elements were > added, only the definition should be changed instead of all the lists > meaning the same thing... > > The same change from "re-doing" something should be changed in the > authorization requirements. It MUST be possible to make the authorization > any time, and that's it. > > The original text: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | > | Re-authentication | M | | S | > | on demand | 17 | | 30 33 | > | e | | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > [e] The AAA protocol MUST allow for a user to be re-authenticated on- > demand. The protocol MUST allow for this event to be triggered by > either the user, access device (AAA client), or the home or visited > AAA server. > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | | | | > | Re-Authorization on | M | | S | > | demand | 18 | | 30 33 | > | d | | | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > [d] This requirement refers to the ability of the AAA client or server > to trigger re-authorization, or to the ability of the server to > send updated authorization information to the device, such as "stop > service." Authorization can allow for a time period, then > additional authorization can be sought to continue. A server can > initially authorize a user to connect and receive services, but > later decide the user is no longer allowed use of the service, for > example after N minutes. Authorizations can have a time limit. Re- > authorization does not necessarily imply re-authentication. > > > Regards, > Tom > > -- > Tom Weckström tweckstr@cc.hut.fi > From owner-aaa-bof@merit.edu Thu Apr 20 10:20:51 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id KAA03749 for ; Thu, 20 Apr 2000 10:20:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 46CB35DDA8; Thu, 20 Apr 2000 10:20:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2E3F65DDBF; Thu, 20 Apr 2000 10:20:26 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id B36E95DDA8 for ; Thu, 20 Apr 2000 10:20:24 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id RAA47922; Thu, 20 Apr 2000 17:20:21 +0300 (EEST) Message-ID: <38FF1278.371E7293@cc.hut.fi> Date: Thu, 20 Apr 2000 17:21:44 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: "pcalhoun@eng.sun.com" Cc: IETF AAA WG Subject: Re: re-auth vs flexible auth? References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, What is obvious for one may not be clear for another. :-) The current text clearly leaves room for two different interpretations and it is sure that the feature will be interpreted and implemented in both possible ways if the AAA protocol RFC comes out with ambiguous definitions like this some day. Sorry about nit picking and playing with words, but the definition truly is ambiguous to me. It needs clarifications. If stated differently, it might cause less confusion. Regards, Tom "pcalhoun@eng.sun.com" wrote: > > Tom, > > The spirit of your comment below is already covered by the requirement. > Certainly we could play with words, but we all know exactly what this means. > Further, it is well defined in the NASREQ criteria draft. > > My opinion, leave the doc as-is. > > PatC > ---- > > > > Hello! > > > > I was wondering whether the re-auhtenticatoin and re-authorization > > requirements should be modified in draft-ietf-aaa-na-reqts-04.txt. > > > > What is the difference between re-authentication and authentication, except > > that when re-authenticating, there may be a AAA session going on for the > > user already? > > > > I would rephrase the 're-' parts to be a part of general authentication and > > authorization requirements by satating something like: > > > > ----------------------------------------------------------- > > [e] The AAA protocol MUST allow for a protocol participant > > ^^^^^^^^^^^^^^^^^^^^^^^ > > to be authenticated at any time. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > The protocol MUST allow for this event to be triggered by > > either the user, access device (AAA client), or the home or visited > > AAA server. > > ----------------------------------------------------------- > > > > The 'user' in the original text (below) should be changed to something like > > 'protocol participant' or 'communicating party'. The current 'user' is not > > enough since the user may also want to authenticate the AAA server it is > > communicating with... > > > > The 'protocol participant' should be then defined somewhere to mean > > "the user, AAA Broker, access device (AAA client), or the home or visited > > AAA server." Alternatively this long list of elements could replace the term > > 'protocol participants'. A single term would be easier. When elements were > > added, only the definition should be changed instead of all the lists > > meaning the same thing... > > > > The same change from "re-doing" something should be changed in the > > authorization requirements. It MUST be possible to make the authorization > > any time, and that's it. > > > > The original text: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | | | > > | Re-authentication | M | | S | > > | on demand | 17 | | 30 33 | > > | e | | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [e] The AAA protocol MUST allow for a user to be re-authenticated on- > > demand. The protocol MUST allow for this event to be triggered by > > either the user, access device (AAA client), or the home or visited > > AAA server. > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | | | | > > | Re-Authorization on | M | | S | > > | demand | 18 | | 30 33 | > > | d | | | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > [d] This requirement refers to the ability of the AAA client or server > > to trigger re-authorization, or to the ability of the server to > > send updated authorization information to the device, such as "stop > > service." Authorization can allow for a time period, then > > additional authorization can be sought to continue. A server can > > initially authorize a user to connect and receive services, but > > later decide the user is no longer allowed use of the service, for > > example after N minutes. Authorizations can have a time limit. Re- > > authorization does not necessarily imply re-authentication. > > > > > > Regards, > > Tom > > > > -- > > Tom Weckström tweckstr@cc.hut.fi > > -- Tom Weckström tweckstr@cc.hut.fi Otakaari 20 B 39 Helsinki University of Technology 02150 Espoo Department of Computer Science 09-4683249/040-5642709 http://www.niksula.cs.hut.fi/~tweckstr From owner-aaa-bof@merit.edu Thu Apr 20 14:58:12 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id OAA08095 for ; Thu, 20 Apr 2000 14:58:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA50A5DD8D; Thu, 20 Apr 2000 14:57:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B43B55DD9C; Thu, 20 Apr 2000 14:57:50 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 79F455DD8D for ; Thu, 20 Apr 2000 14:57:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06572; Thu, 20 Apr 2000 12:57:34 -0600 (MDT) Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.53.34]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id LAA16605; Thu, 20 Apr 2000 11:57:33 -0700 (PDT) Received: from mordor by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01419; Thu, 20 Apr 2000 11:57:31 -0700 Date: Thu, 20 Apr 2000 11:57:31 -0700 (PDT) From: "pcalhoun@eng.sun.com" Reply-To: "pcalhoun@eng.sun.com" Subject: Submission of DIAMETER as the AAA protocol To: aaa-wg@merit.edu Cc: pcalhoun@eng.sun.com, paul@mci.net, aboba@internaut.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, This is my official submission of the DIAMETER protocol to be considered as a candidate for the AAA protocol. All of the Internet Drafts described below have been submitted to the secretariat, and will be made available soon. If you wish to get access to them before, they can be found at www.diameter.org. I am submitting the following Internet Drafts for the WGs consideration: 1. draft-ietf-aaa-diameter-comp-00.txt This Internet Draft is a detailed comparison of the DIAMETER protocol against the requirements stated in the *-03 version of the Network Access Requirements 2. draft-calhoun-diameter-framework-07.txt This Informational Internet Draft contains the DIAMETER framework 3. draft-calhoun-diameter-14.txt This Standards Track Internet Draft contains the base DIAMETER protocol 4. draft-calhoun-diameter-accounting-05.txt This Standards Track Internet Draft contains the DIAMETER Accounting extension. 5. draft-calhoun-diameter-mobileip-07.txt This Standards Track Internet Draft contains the DIAMETER Mobile IP extension. 6. draft-calhoun-diameter-nasreq-03.txt This Standards Trach Internet Drafts contains the DIAMETER NASREQ extension. 7. draft-calhoun-diameter-res-mgmt-03.txt This Standards Track Internet Drafts contains the DIAMETER extension that is required for peers to exchange session state information. 8. draft-calhoun-diameter-strong-crypto-03.txt This Standards Track Internet Draft contains the DIAMETER extension that provides end-to-end object level security. 9. draft-calhoun-diameter-impl-guide-02.txt This Informational Implementation Guide contains information for DIAMETER developers. I agree to all of the terms listed in the official protocol submission e-mail, and all of the I-Ds are in full conformance with all provisions of section 10 of RFC 2026. Although the AAA mailing list should hold discussions on how the DIAMETER protocol does/does not meet the requirements, I would ask that any protocol-related discussions be moved to the DIAMETER mailing list. To join, send an e-mail to diameter-request@diameter.org. Thanks, PatC From owner-aaa-bof@merit.edu Thu Apr 20 15:06:15 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id PAA08353 for ; Thu, 20 Apr 2000 15:06:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 615345DDB9; Thu, 20 Apr 2000 15:05:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4A3BD5DDB1; Thu, 20 Apr 2000 15:05:56 -0400 (EDT) Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14]) by segue.merit.edu (Postfix) with ESMTP id 2A2D25DD9C for ; Thu, 20 Apr 2000 15:05:55 -0400 (EDT) Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Thu, 20 Apr 2000 15:04:37 -0400 Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id J2T7P6JF; Thu, 20 Apr 2000 15:04:30 -0400 Received: from mitton (mitton.corpeast.baynetworks.com [132.245.145.106]) by zbl6c008.corpeast.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 2SS0ZQFR; Thu, 20 Apr 2000 15:04:27 -0400 Message-Id: <4.2.2.20000420145313.00d549b0@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Apr 2000 15:05:58 -0400 To: IETF AAA WG , m=22?= , "pcalhoun@eng.sun.com" Original-To: IETF AAA WG , =?iso-8859-1?Q?=22Tom_K=2E_Weckström=22?= , "pcalhoun@eng.sun.com" PP-Warning: Parse error in original version of preceding To line From: "David Mitton" Subject: Re: re-auth vs flexible auth? In-Reply-To: <38FF1278.371E7293@cc.hut.fi> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nic.merit.edu id PAA08353 At 05:21 PM 4/20/00 +0300, Tom K. Weckström wrote: >Pat, > >What is obvious for one may not be clear for another. :-) Very true. >The current text clearly leaves room for two different interpretations and >it is sure that the >feature will be interpreted and implemented in both possible ways if the >AAA protocol RFC comes out >with ambiguous definitions like this some day. I'm sorry, but re-reading your original comments, I didn't get the sense of what the two possible interpretations you arrived at. Instead you seemed to want to simply the language, by removing the, in your opinion, redundant "re-" from the re-authentication and re-authorization requirements. Could you restate your comments as to the alternatives and suggest language on how we can disambiguate the interpretation? Most precedent protocols in this space require authentication and authorization (either of which may have trivial cases) before the session can fully exist. The act of re-doing these operations later in the life of the session, is not allowed for or permitted. That is why these additional requirements are worded as such. Thanks, Dave. >Sorry about nit picking and playing with words, but the definition truly >is ambiguous to me. It >needs clarifications. If stated differently, it might cause less confusion. > >Regards, > Tom > >"pcalhoun@eng.sun.com" wrote: > > > > Tom, > > > > The spirit of your comment below is already covered by the requirement. > > Certainly we could play with words, but we all know exactly what this > means. > > Further, it is well defined in the NASREQ criteria draft. > > > > My opinion, leave the doc as-is. > > > > PatC > > ---- > > > > > > Hello! > > > > > > I was wondering whether the re-auhtenticatoin and re-authorization > > > requirements should be modified in draft-ietf-aaa-na-reqts-04.txt. > > > > > > What is the difference between re-authentication and authentication, > except > > > that when re-authenticating, there may be a AAA session going on for the > > > user already? > > > > > > I would rephrase the 're-' parts to be a part of general > authentication and > > > authorization requirements by satating something like: > > > > > > ----------------------------------------------------------- > > > [e] The AAA protocol MUST allow for a protocol participant > > > ^^^^^^^^^^^^^^^^^^^^^^^ > > > to be authenticated at any time. > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > The protocol MUST allow for this event to be triggered by > > > either the user, access device (AAA client), or the home or visited > > > AAA server. > > > ----------------------------------------------------------- > > > > > > The 'user' in the original text (below) should be changed to > something like > > > 'protocol participant' or 'communicating party'. The current 'user' > is not > > > enough since the user may also want to authenticate the AAA server it is > > > communicating with... > > > > > > The 'protocol participant' should be then defined somewhere to mean > > > "the user, AAA Broker, access device (AAA client), or the home or visited > > > AAA server." Alternatively this long list of elements could replace > the term > > > 'protocol participants'. A single term would be easier. When elements > were > > > added, only the definition should be changed instead of all the lists > > > meaning the same thing... > > > > > > The same change from "re-doing" something should be changed in the > > > authorization requirements. It MUST be possible to make the authorization > > > any time, and that's it. > > > > > > The original text: > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | | | | > > > | Re-authentication | M | | S | > > > | on demand | 17 | | 30 33 | > > > | e | | | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > [e] The AAA protocol MUST allow for a user to be re-authenticated on- > > > demand. The protocol MUST allow for this event to be triggered by > > > either the user, access device (AAA client), or the home or visited > > > AAA server. > > > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | | | | | > > > | Re-Authorization on | M | | S | > > > | demand | 18 | | 30 33 | > > > | d | | | | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > [d] This requirement refers to the ability of the AAA client or server > > > to trigger re-authorization, or to the ability of the server to > > > send updated authorization information to the device, such as "stop > > > service." Authorization can allow for a time period, then > > > additional authorization can be sought to continue. A server can > > > initially authorize a user to connect and receive services, but > > > later decide the user is no longer allowed use of the service, for > > > example after N minutes. Authorizations can have a time limit. Re- > > > authorization does not necessarily imply re-authentication. > > > > > > > > > Regards, > > > Tom > > > > > > -- > > > Tom Weckström tweckstr@cc.hut.fi > > > > >-- > Tom Weckström tweckstr@cc.hut.fi > Otakaari 20 B 39 Helsinki University of Technology > 02150 Espoo Department of Computer Science > 09-4683249/040-5642709 http://www.niksula.cs.hut.fi/~tweckstr --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com From owner-aaa-bof@merit.edu Thu Apr 20 16:48:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id QAA09794 for ; Thu, 20 Apr 2000 16:48:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A5DF5DDFD; Thu, 20 Apr 2000 16:48:39 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 16B255DE07; Thu, 20 Apr 2000 16:48:39 -0400 (EDT) Received: from smtp-2.hut.fi (smtp-2.hut.fi [130.233.228.92]) by segue.merit.edu (Postfix) with ESMTP id 756135DDFD for ; Thu, 20 Apr 2000 16:48:37 -0400 (EDT) Received: from cc.hut.fi (root@alpha.hut.fi [130.233.224.50]) by smtp-2.hut.fi (8.9.3/8.9.3) with ESMTP id XAA51176; Thu, 20 Apr 2000 23:48:16 +0300 (EEST) Message-ID: <38FF6D61.321AB120@cc.hut.fi> Date: Thu, 20 Apr 2000 23:49:37 +0300 From: "Tom K. =?iso-8859-1?Q?Weckstr=F6m?=" Organization: HUT X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586) X-Accept-Language: en MIME-Version: 1.0 To: David Mitton Cc: IETF AAA WG , "pcalhoun@eng.sun.com" Subject: Re: re-auth vs flexible auth? References: <4.2.2.20000420145313.00d549b0@ZBL6C008.corpeast.baynetworks.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Yes, my two possible interpretations were not well visible in my previous comments. I would like to make a distinction between re-auth(z) and "auth(z) any time". They may eventually mean the same thing, but to me it appeared as if re-auth(z) might be something special and different from the "normal" auth(z), whereas "auth(z) any time" would always do the same thing and thus be simpler from the definition and implementation points of view. I am not sure whether this actually has any effect on the definition after all... Just my 2 cents for unambiguity... Another issue I pointed out was the fact that the requirement for re-authentication states that "The AAA protocol MUST allow for a user to be re-authenticated". The term "user" should be changed to perhaps "... a user or any AAA architecture element...", since I would definitely like to be able to verify (e.g., from a certificate) that my ISP is still who he claims to be. Regards, Tom David Mitton wrote: > At 05:21 PM 4/20/00 +0300, Tom K. Weckström wrote: > >The current text clearly leaves room for two different interpretations and > >it is sure that the > >feature will be interpreted and implemented in both possible ways if the > >AAA protocol RFC comes out > >with ambiguous definitions like this some day. > > I'm sorry, but re-reading your original comments, I didn't get the sense of > what the two possible interpretations you arrived at. Instead you seemed > to want to simply the language, by removing the, in your opinion, redundant > "re-" from the re-authentication and re-authorization requirements. > > Could you restate your comments as to the alternatives and suggest language > on how we can disambiguate the interpretation? > > Most precedent protocols in this space require authentication and > authorization (either of which may have trivial cases) before the session > can fully exist. The act of re-doing these operations later in the life of > the session, is not allowed for or permitted. That is why these additional > requirements are worded as such. > > Thanks, > Dave. > -- Tom Weckström tweckstr@cc.hut.fi From owner-aaa-bof@merit.edu Fri Apr 21 12:33:23 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id MAA24995 for ; Fri, 21 Apr 2000 12:33:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07BCF5DDFD; Fri, 21 Apr 2000 12:32:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E66CE5DE13; Fri, 21 Apr 2000 12:32:47 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by segue.merit.edu (Postfix) with ESMTP id 11C255DDFD for ; Fri, 21 Apr 2000 12:32:43 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA62358 for ; Fri, 21 Apr 2000 09:18:39 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: IETF 47 minutes Date: Fri, 21 Apr 2000 09:38:32 -0700 Message-ID: <005f01bfabb0$0ad94c30$428939cc@ntdev.microsoft.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 CWS, 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 IETF 47 minutes are now available for your inspection: http://www.drizzle.com/~aboba/AAA/IETF47/ietf47-minutes.html Many thanks to our minute taker, Dave Mitton. From owner-aaa-bof@merit.edu Tue Apr 25 22:05:34 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id WAA06417 for ; Tue, 25 Apr 2000 22:05:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C0D305DDD8; Tue, 25 Apr 2000 22:05:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A24095DDEA; Tue, 25 Apr 2000 22:05:11 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by segue.merit.edu (Postfix) with ESMTP id DE9AA5DDD8 for ; Tue, 25 Apr 2000 22:05:05 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id SAA73314 for ; Tue, 25 Apr 2000 18:50:35 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Subject: FW: Response to Solicitation Date: Tue, 25 Apr 2000 19:05:24 -0700 Message-ID: <004701bfaf23$e346b000$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com] Sent: Tuesday, April 25, 2000 12:55 PM To: 'aboba@internaut.com'; 'Paul Krumviede' Cc: Walker, Jesse; 'Weiss, Walter'; 'avri.doria@nokia.com'; Durham, David Subject: RE: SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP Hi Bernard & Paul, Just wanted to inform you that we plan to submit a draft on "COPS Usage for AAA" to the AAA Working Group. Thanks, Hormuzd. From owner-aaa-bof@merit.edu Wed Apr 26 21:28:13 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id VAA27365 for ; Wed, 26 Apr 2000 21:28:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 488F55DDD7; Wed, 26 Apr 2000 21:27:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3066F5DD91; Wed, 26 Apr 2000 21:27:51 -0400 (EDT) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id A5CBE5DD8D for ; Wed, 26 Apr 2000 21:27:49 -0400 (EDT) Received: from gwz (sj-dial-3-162.cisco.com [171.68.180.163]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id SAA15416; Wed, 26 Apr 2000 18:26:00 -0700 (PDT) Reply-To: From: "Glen Zorn" To: Cc: Subject: RE: AAA WG Last Call on draft-ietf-aaa-na-reqts-04.txt Date: Wed, 26 Apr 2000 18:25:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <001e01bfab70$a791a490$428939cc@ntdev.microsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-aaa-bof@merit.edu Precedence: bulk A couple of quick comments: In the Introduction: "This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ, ROAMOPS, and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents." Given that readers are directed to "the original documents" for requirements details, it wouldbe nice if references to those documents were given here, e.g., "This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5] working groups, as well as from TIA 45.6 [4]. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents." I think it would be helpful to provide a example row of the requirements matrix, with text explaining each entry in the row (perhaps as section 4.3). In section 4.2, under the term "Administrative Domain", the term "intra-net" is used but it is never defined (in fact, it may never have been defined outside the trades). I think that what is actually being described here is a little-i internet, no? I think that I have complained about this before. In section 4.2, under the term "Transparent Proxy", the words "A Local Proxy" should be "A Transparent Proxy" (cut/paste error?). In section 5.1, clarification [g] says: "The AAA protocol MUST be capable to transporting certificates." but should say: "The AAA protocol MUST be capable of transporting certificates." Last but not least, my email address should be gwz@cisco.com, since the ACM address has been bouncing (maybe I forgot to paymy dues ;-)) From owner-aaa-bof@merit.edu Thu Apr 27 03:07:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id DAA02579 for ; Thu, 27 Apr 2000 03:07:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 506DB5DD8D; Thu, 27 Apr 2000 03:06:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 397595DD91; Thu, 27 Apr 2000 03:06:28 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by segue.merit.edu (Postfix) with ESMTP id 6CAC85DD8D for ; Thu, 27 Apr 2000 03:06:19 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id XAA74937; Wed, 26 Apr 2000 23:51:31 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: Cc: Subject: RE: AAA WG Last Call on draft-ietf-aaa-na-reqts-04.txt Date: Thu, 27 Apr 2000 00:06:40 -0700 Message-ID: <001801bfb017$249c4260$428939cc@ntdev.microsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks. These changes will be incorporated into the next version of the document. -----Original Message----- From: Glen Zorn [mailto:gwz@cisco.com] Sent: Wednesday, April 26, 2000 6:26 PM To: aboba@internaut.com Cc: aaa-wg@merit.edu Subject: RE: AAA WG Last Call on draft-ietf-aaa-na-reqts-04.txt A couple of quick comments: In the Introduction: "This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ, ROAMOPS, and MOBILEIP working groups, as well as from TIA 45.6. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents." Given that readers are directed to "the original documents" for requirements details, it wouldbe nice if references to those documents were given here, e.g., "This document represents a summary of AAA protocol requirements for network access. In creating this documents, inputs were taken from documents produced by the NASREQ [3], ROAMOPS [2], and MOBILEIP [5] working groups, as well as from TIA 45.6 [4]. This document summarizes the requirements collected from those sources, separating requirements for authentication, authorization and accounting. Details on the requirements are available in the original documents." I think it would be helpful to provide a example row of the requirements matrix, with text explaining each entry in the row (perhaps as section 4.3). In section 4.2, under the term "Administrative Domain", the term "intra-net" is used but it is never defined (in fact, it may never have been defined outside the trades). I think that what is actually being described here is a little-i internet, no? I think that I have complained about this before. In section 4.2, under the term "Transparent Proxy", the words "A Local Proxy" should be "A Transparent Proxy" (cut/paste error?). In section 5.1, clarification [g] says: "The AAA protocol MUST be capable to transporting certificates." but should say: "The AAA protocol MUST be capable of transporting certificates." Last but not least, my email address should be gwz@cisco.com, since the ACM address has been bouncing (maybe I forgot to paymy dues ;-))