From owner-aaa-wg@merit.edu Sun Jul 1 07:49:56 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09780 for ; Sun, 1 Jul 2001 07:49:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6EB9C9123F; Sun, 1 Jul 2001 07:49:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3071191240; Sun, 1 Jul 2001 07:49:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBA1D9123F for ; Sun, 1 Jul 2001 07:49:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1409C5DDA0; Sun, 1 Jul 2001 07:51:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2B80C5DD90 for ; Sun, 1 Jul 2001 07:51:07 -0400 (EDT) Received: (qmail 21069 invoked by uid 500); 1 Jul 2001 11:38:42 -0000 Date: Sun, 1 Jul 2001 04:38:42 -0700 From: Pat Calhoun To: Paul Funk Cc: Pat Calhoun , Fredrik Johansson , Mark Eklund , Jacques Caron , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Message-ID: <20010701043842.N5195@charizard.diameter.org> Mail-Followup-To: Paul Funk , Pat Calhoun , Fredrik Johansson , Mark Eklund , Jacques Caron , AAA Listan References: <20010629092206.E25503@charizard.diameter.org> <20010629060339.E23402@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> <20010630164447.L5195@charizard.diameter.org> <4.1.20010630210708.01d55230@cairo.funk.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20010630210708.01d55230@cairo.funk.com>; from paul@funk.com on Sat, Jun 30, 2001 at 09:40:16PM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sat, Jun 30, 2001 at 09:40:16PM -0400, Paul Funk wrote: > Pat, > > I think the text that describes how to generate Hop-By-Hop Identifier and > End-To-End Identifier should be the same -- that is, an identifier should be > locally unique for the long enough past the lifetime of a transaction to > prevent any ambiguity. How this is done is up to the sender, and there is > no requirement that the numbers be increasing, though the obvious way to > achieve this is to initialize the value in an intelligent way on reboot and > increment from then on. > > The identifier can be initialized randomly at reboot, but there is always the > risk that identifiers from before and after reboots could clash. That's okay > for Hop-By-Hop Identifiers, because when the connection goes down all > the pending transactions are dropped anyway. With End-To-End Identifier, > it's more problematic; the only way the server can disambiguate two > equal identifiers is by consulting Origin-State-Id, but that is not a required > attribute. > > Here's an algorithm for generating an initial value for an identifier that > guarantees uniqueness across reboot: > > Initialize the high order 12 bits of the identifier to the low order 12 > bits of the > current time, and initialize the low order 20 bits of the identifier to 0. > This is > guaranteed to produce unique identifiers across reboots provided that: > > 1 the device takes longer than a second to reboot > > 2 no transaction is kicking around for longer than an hour or so > (2 ^ 12 seconds) At first glance (just before hoping on a plane), I must admit that this sounds quite interesting. I'd be great if y'all could flush this one out while I am gone. > > 3 the transaction rate (the rate at which the identifier is incremented) > is no greater than a million per second (2 ^ 20). ok, I guess I'll have to put in a few sleep statements in my code :) :) PatC From owner-aaa-wg@merit.edu Sun Jul 1 13:01:59 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12811 for ; Sun, 1 Jul 2001 13:01:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1886C91242; Sun, 1 Jul 2001 13:01:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D876291243; Sun, 1 Jul 2001 13:01:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D04A491242 for ; Sun, 1 Jul 2001 13:01:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E2CB5DDBF; Sun, 1 Jul 2001 13:02:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by segue.merit.edu (Postfix) with ESMTP id DD78B5DDA0 for ; Sun, 1 Jul 2001 13:02:54 -0400 (EDT) Received: from knox6195.CISCO.COM (rsargent@knox6195.cisco.com [161.44.216.195]) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA17416; Sun, 1 Jul 2001 10:01:58 -0700 (PDT) Date: Sun, 1 Jul 2001 13:01:52 -0400 From: Robert Sargent To: Paul Funk , Pat Calhoun , Fredrik Johansson , Mark Eklund , Jacques Caron , AAA Listan Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier Message-ID: <20010701130152.A10008@Cisco.COM> Reply-To: Robert Sargent References: <20010629092206.E25503@charizard.diameter.org> <20010629060339.E23402@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> <20010630164447.L5195@charizard.diameter.org> <4.1.20010630210708.01d55230@cairo.funk.com> <20010701043842.N5195@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010701043842.N5195@charizard.diameter.org>; from pcalhoun@diameter.org on Sun, Jul 01, 2001 at 04:38:42AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Sun, Jul 01, 2001 at 04:38:42AM -0700, Pat Calhoun promised: > On Sat, Jun 30, 2001 at 09:40:16PM -0400, Paul Funk wrote: > > Pat, > > > > I think the text that describes how to generate Hop-By-Hop Identifier and > > End-To-End Identifier should be the same -- that is, an identifier should be > > locally unique for the long enough past the lifetime of a transaction to > > prevent any ambiguity. How this is done is up to the sender, and there is > > no requirement that the numbers be increasing, though the obvious way to > > achieve this is to initialize the value in an intelligent way on reboot and > > increment from then on. > > > > The identifier can be initialized randomly at reboot, but there is always the > > risk that identifiers from before and after reboots could clash. That's okay > > for Hop-By-Hop Identifiers, because when the connection goes down all > > the pending transactions are dropped anyway. With End-To-End Identifier, > > it's more problematic; the only way the server can disambiguate two > > equal identifiers is by consulting Origin-State-Id, but that is not a required > > attribute. > > > > Here's an algorithm for generating an initial value for an identifier that > > guarantees uniqueness across reboot: > > > > Initialize the high order 12 bits of the identifier to the low order 12 > > bits of the > > current time, and initialize the low order 20 bits of the identifier to 0. > > This is > > guaranteed to produce unique identifiers across reboots provided that: > > > > 1 the device takes longer than a second to reboot What if the device isn't being rebooted but the process (diameter or whatever) is being restarted? Rob > > > > 2 no transaction is kicking around for longer than an hour or so > > (2 ^ 12 seconds) > > At first glance (just before hoping on a plane), I must admit that this sounds > quite interesting. I'd be great if y'all could flush this one out while I am > gone. > > > > > 3 the transaction rate (the rate at which the identifier is incremented) > > is no greater than a million per second (2 ^ 20). > > ok, I guess I'll have to put in a few sleep statements in my code :) :) > > PatC -- Rob Sargent Tel: (865) 671-8823 Software Development Manager -*- Remote Site Manager - Knoxville 10850 Murdock Dr Knoxville TN 37932 http://darien.cisco.com/ From owner-aaa-wg@merit.edu Sun Jul 1 14:05:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13153 for ; Sun, 1 Jul 2001 14:05:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A57B291243; Sun, 1 Jul 2001 14:04:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 774EE91244; Sun, 1 Jul 2001 14:04:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 469C091243 for ; Sun, 1 Jul 2001 14:04:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEA195DDC0; Sun, 1 Jul 2001 14:06:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cairo.funk.com (cairo.funk.com [198.186.160.75]) by segue.merit.edu (Postfix) with ESMTP id 696D75DDA0 for ; Sun, 1 Jul 2001 14:06:06 -0400 (EDT) Received: from pii400 (pii400.funk.com [198.186.160.46]) by cairo.funk.com (8.9.3/8.9.3) with SMTP id NAA22864; Sun, 1 Jul 2001 13:54:52 -0400 (EDT) Message-Id: <4.1.20010701133702.01d53ca0@cairo.funk.com> X-Sender: paul@cairo.funk.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 01 Jul 2001 13:42:14 -0400 To: Robert Sargent , Pat Calhoun , Fredrik Johansson , Mark Eklund , Jacques Caron , AAA Listan From: Paul Funk Subject: Re: [AAA-WG]: Issue 93. End-to-End identifier In-Reply-To: <20010701130152.A10008@Cisco.COM> References: <20010701043842.N5195@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> <20010629060339.E23402@charizard.diameter.org> <20010629092206.E25503@charizard.diameter.org> <20010630164447.L5195@charizard.diameter.org> <4.1.20010630210708.01d55230@cairo.funk.com> <20010701043842.N5195@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-wg@merit.edu Precedence: bulk At 01:01 PM 7/1/01 -0400, Robert Sargent wrote: >On Sun, Jul 01, 2001 at 04:38:42AM -0700, Pat Calhoun promised: >> On Sat, Jun 30, 2001 at 09:40:16PM -0400, Paul Funk wrote: >> > Pat, >> > >> > I think the text that describes how to generate Hop-By-Hop Identifier and >> > End-To-End Identifier should be the same -- that is, an identifier should be >> > locally unique for the long enough past the lifetime of a transaction to >> > prevent any ambiguity. How this is done is up to the sender, and there is >> > no requirement that the numbers be increasing, though the obvious way to >> > achieve this is to initialize the value in an intelligent way on reboot and >> > increment from then on. >> > >> > The identifier can be initialized randomly at reboot, but there is always the >> > risk that identifiers from before and after reboots could clash. That's okay >> > for Hop-By-Hop Identifiers, because when the connection goes down all >> > the pending transactions are dropped anyway. With End-To-End Identifier, >> > it's more problematic; the only way the server can disambiguate two >> > equal identifiers is by consulting Origin-State-Id, but that is not a required >> > attribute. >> > >> > Here's an algorithm for generating an initial value for an identifier that >> > guarantees uniqueness across reboot: >> > >> > Initialize the high order 12 bits of the identifier to the low order 12 bits of the >> > current time, and initialize the low order 20 bits of the identifier to 0. This is >> > guaranteed to produce unique identifiers across reboots provided that: >> > >> > 1 the device takes longer than a second to reboot > >What if the device isn't being rebooted but the process (diameter or whatever) >is being restarted? Same difference. As long as the time between restarts of the process is at least a second, you won't get a duplicate initialization. > >> > >> > 2 no transaction is kicking around for longer than an hour or so >> > (2 ^ 12 seconds) >> >> At first glance (just before hoping on a plane), I must admit that this sounds >> quite interesting. I'd be great if y'all could flush this one out while I am >> gone. >> >> > >> > 3 the transaction rate (the rate at which the identifier is incremented) >> > is no greater than a million per second (2 ^ 20). >> >> ok, I guess I'll have to put in a few sleep statements in my code :) :) Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Mon Jul 2 13:23:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19307 for ; Mon, 2 Jul 2001 13:23:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 58F0491271; Mon, 2 Jul 2001 13:23:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 229ED91273; Mon, 2 Jul 2001 13:23:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1678F91271 for ; Mon, 2 Jul 2001 13:23:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB8695DDB4; Mon, 2 Jul 2001 13:24:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 118605DDAB for ; Mon, 2 Jul 2001 13:24:32 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA20454 for ; Mon, 2 Jul 2001 13:23:08 -0400 (EDT) Date: Mon, 2 Jul 2001 13:23:57 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-koehler-aaa-diameter-base-protocol-mib-00.txt In-Reply-To: <20010630162618.H5195@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Jay Koehler has created a mib for the Diameter base protocol and submitted it to IETF. It is available at http://www.ietf.org/internet-drafts/draft-koehler-aaa-diameter-base-protocol-mib-00.txt If it is O.K. with the list, please use aaa-wg@merit.edu to discuss any issues with this draft. -mark From owner-aaa-wg@merit.edu Tue Jul 3 08:14:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13889 for ; Tue, 3 Jul 2001 08:14:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 981BC912BD; Tue, 3 Jul 2001 08:14:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48428912BE; Tue, 3 Jul 2001 08:14:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4570C912BD for ; Tue, 3 Jul 2001 08:14:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 558EB5DD97; Tue, 3 Jul 2001 08:15:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by segue.merit.edu (Postfix) with ESMTP id ACB475DD96 for ; Tue, 3 Jul 2001 08:15:45 -0400 (EDT) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f63CFEI12332 for ; Tue, 3 Jul 2001 15:15:14 +0300 (EET DST) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 3 Jul 2001 15:14:50 +0300 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 3 Jul 2001 15:14:50 +0300 Message-ID: From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: Question on implicit session termination Date: Tue, 3 Jul 2001 15:14:46 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The base-06 defines in section 10.1 that: "An access device MAY include an Authorization-Lifetime AVP with a value of zero to inform the Diameter server that the authorization requested will only occur once, and no further auth messages are to be sent with this particular session identifier." It is not clear whether "no further auth messages" means that there MUST be only one Request/Answer pair if the implicit termination is used or is it possible to there MAY be more than one Request/Answer pair before the implicit session termination? There may be applications which use more than one Request/Answer pair e.g. for authentication before the authorization is accepted and for those allowing more one Request/Answer pair would be needed. The application should define when an authorization and/or authentication has succeeded or failed which is used to determine when the implicit session termination actually happens. Best Regards, Jaakko From owner-aaa-wg@merit.edu Tue Jul 3 13:55:14 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13957 for ; Tue, 3 Jul 2001 13:55:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9FD7191209; Tue, 3 Jul 2001 13:54:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67AD7912E0; Tue, 3 Jul 2001 13:54:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BDD8091209 for ; Tue, 3 Jul 2001 13:54:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 584605DDB0; Tue, 3 Jul 2001 13:56:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 077115DDA9 for ; Tue, 3 Jul 2001 13:56:06 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA10441 for ; Tue, 3 Jul 2001 10:55:12 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id KAA23462 for ; Tue, 3 Jul 2001 10:55:12 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Tue, 3 Jul 2001 12:55:11 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Martin Julien (ECE)'" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Issue 89: Editorial comments - Mobile-IP draft-06 Date: Tue, 3 Jul 2001 12:54:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Martin, I have a question with one of your comments in issue #89 (which is now in the resolved list). >> ... >> 8) Section 2.4, I don't think it is very clean, with regards to the >> specification, to expect that the HA will be responsible of forwarding >> the Session-Timeout, the Authorization-Lifetime, the MIP-FA-to-MN-Key >> and the MIP-FA-to-HA-Key AVPs in the HAA. When I see those attributes >> in the HAA, I always have to remind me that they are meaningless to the >> HAA, but only meaningful to make easier the conversion of the HAA into >> a AMA in the AAAH, which I consider not very useful anyway, since the >> AAAH still needs to check that they have been included properly. Well, >> my opinion is that we should remove them from there, since they are >> meaningless to the AAAH that receives the HAA. > > ok. A few revisions of the base protocol base, less state was required on > the AAAH. Nowadays, though, I agree that the AAAH can easily keep this > state information (or add it to Proxy-State if it really wants to). > ... Don't we need to have the Session-Timeout AVP in the HAR/HAA messages to refer to the session created between the AAAH and the HA? Thanks, -Panos From owner-aaa-wg@merit.edu Wed Jul 4 04:42:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02825 for ; Wed, 4 Jul 2001 04:42:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DAA91203; Wed, 4 Jul 2001 04:42:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8E5491225; Wed, 4 Jul 2001 04:42:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3BDF91203 for ; Wed, 4 Jul 2001 04:42:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B5D55DDB4; Wed, 4 Jul 2001 04:43:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 22D6F5DD8E for ; Wed, 4 Jul 2001 04:43:33 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f648gbN02301 for ; Wed, 4 Jul 2001 10:42:37 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 04 10:42:37 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 10:42:37 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1A9F3@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Thomas Panagiotis-PTHOMAS1'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft-06 Date: Wed, 4 Jul 2001 10:42:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA02825 Hi Thomas, See comments. > From: Thomas Panagiotis-PTHOMAS1 [mailto:panos.thomas@motorola.com] > > Hi Martin, > > I have a question with one of your comments in issue #89 > (which is now in > the resolved list). > > >> ... > >> 8) Section 2.4, I don't think it is very clean, with > regards to the > >> specification, to expect that the HA will be responsible > of forwarding > >> the Session-Timeout, the Authorization-Lifetime, the > MIP-FA-to-MN-Key > >> and the MIP-FA-to-HA-Key AVPs in the HAA. When I see those > attributes > >> in the HAA, I always have to remind me that they are > meaningless to the > >> HAA, but only meaningful to make easier the conversion of > the HAA into > >> a AMA in the AAAH, which I consider not very useful > anyway, since the > >> AAAH still needs to check that they have been included > properly. Well, > >> my opinion is that we should remove them from there, since they are > >> meaningless to the AAAH that receives the HAA. > > > > ok. A few revisions of the base protocol base, less state > was required on > > the AAAH. Nowadays, though, I agree that the AAAH can > easily keep this > > state information (or add it to Proxy-State if it really wants to). > > ... > > Don't we need to have the Session-Timeout AVP in the HAR/HAA messages > to refer to the session created between the AAAH and the HA? My understanding is that the Session-Timeout AVP is used to represent the time limit of a user-session in a Diameter node. It is used in the AMR to inform the AAAH about the maximum duration of the session in the Diameter client. That means that the AAAH can accept the hint, or change it for a lower value. It is then forwarded to the HA in the HAR, in order to clean the session accordingly at the session-timeout. So, basically, my understanding is that the FA, the AAAF, the AAAH and the HA should have the same value of the Session-Timeout, right? It seems to be only one final value of the Session-Timeout, which is decided by the AAAH. What I am not sure is if the HA could lower down again the value of the Session-Timeout? That would be a possible good reason for including the Session-Timeout AVP in the HAR???? Any thoughts? Note that the Session-Timeout is also discussed in issue 82. Now that we´re talking about it, I am wondering a couple of things. The problem is that the Authorization Session State-Machine (10.1) says that when the Session-Timeout expires on a Diameter client, then an STR is sent. However, when it expires on the AAAH, nothing needs to be sent, only clean-up occurs. That would mean that the FA and the HA would send simultaneously an STR, which would make the AAAH receive 2 STR for the same session, while it is already cleaning the session. Receiving 2 STR is fine, since the AAAH have to support MIP roaming between different FAs. However, it is not so good to be already cleaning the session in the AAAH, while 2 STR are expected. Unless I don't have a good understanding of the Session-Timeout AVP, I think it would not work very well. What do you think? Maybe an issue should be raised about it. Martin > Thanks, > > -Panos > From owner-aaa-wg@merit.edu Wed Jul 4 16:18:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11174 for ; Wed, 4 Jul 2001 16:18:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A9AC91229; Wed, 4 Jul 2001 16:18:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F0C349122F; Wed, 4 Jul 2001 16:18:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA08391229 for ; Wed, 4 Jul 2001 16:18:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A1275DDB5; Wed, 4 Jul 2001 16:19:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id C7AA35DD8E for ; Wed, 4 Jul 2001 16:19:40 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id NAA28787 for ; Wed, 4 Jul 2001 13:18:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA28943 for ; Wed, 4 Jul 2001 13:11:36 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 4 Jul 2001 15:18:39 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Martin Julien (ECE)'" Cc: "'aaa-wg@merit.edu'" , Thomas Panagiotis-PTHOMAS1 Subject: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft-06 Date: Wed, 4 Jul 2001 15:18:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk hmmm... I understood it differently. So we need at least some text to clarify things :), maybe as part of issue 82? Here's what I thought... Session Management is generic and defined across applications (MIPv4,Dial-up,...). The Session-Timeout AVP is tied to a Session-Id, therefore each session has its own Session-Timeout. Diameter entities initiate sessions by sending Application-Specific requests which MAY carry a proposed value for the Session-Timeout. However, the receiver of the request has the last word on the value of the Session-Timeout, which is sent in the corresponding answer. Offering MIPv4 service to a user requires the establishment of more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, where [ ] indicates the initiator of the session. The sessions are tied together through the Accounting-Multi-Session-Id. So, if the above is the indent, then the Session-Timeout AVP should be included (as optional) in the definition of the AMR/AMA, HAR/HAA messages. In addition, the Authorization-Lifetime AVP must be included (as mandatory) in the HAR message to inform the HA on the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should be noted somewhere that the trigger for initiating sessions is not always an Auth Request from the Client, but MAY be an application specific message (HAR) coming from a Server. -Panos -----Original Message----- From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se] Sent: 04 July 2001 03:43 To: 'Thomas Panagiotis-PTHOMAS1'; Martin Julien (ECE) Cc: 'aaa-wg@merit.edu' Subject: RE: Issue 89: Editorial comments - Mobile-IP draft-06 Hi Thomas, See comments. > From: Thomas Panagiotis-PTHOMAS1 [mailto:panos.thomas@motorola.com] > > Hi Martin, > > I have a question with one of your comments in issue #89 > (which is now in > the resolved list). > > >> ... > >> 8) Section 2.4, I don't think it is very clean, with > regards to the > >> specification, to expect that the HA will be responsible > of forwarding > >> the Session-Timeout, the Authorization-Lifetime, the > MIP-FA-to-MN-Key > >> and the MIP-FA-to-HA-Key AVPs in the HAA. When I see those > attributes > >> in the HAA, I always have to remind me that they are > meaningless to the > >> HAA, but only meaningful to make easier the conversion of > the HAA into > >> a AMA in the AAAH, which I consider not very useful > anyway, since the > >> AAAH still needs to check that they have been included > properly. Well, > >> my opinion is that we should remove them from there, since they are > >> meaningless to the AAAH that receives the HAA. > > > > ok. A few revisions of the base protocol base, less state > was required on > > the AAAH. Nowadays, though, I agree that the AAAH can > easily keep this > > state information (or add it to Proxy-State if it really wants to). > > ... > > Don't we need to have the Session-Timeout AVP in the HAR/HAA messages > to refer to the session created between the AAAH and the HA? My understanding is that the Session-Timeout AVP is used to represent the time limit of a user-session in a Diameter node. It is used in the AMR to inform the AAAH about the maximum duration of the session in the Diameter client. That means that the AAAH can accept the hint, or change it for a lower value. It is then forwarded to the HA in the HAR, in order to clean the session accordingly at the session-timeout. So, basically, my understanding is that the FA, the AAAF, the AAAH and the HA should have the same value of the Session-Timeout, right? It seems to be only one final value of the Session-Timeout, which is decided by the AAAH. What I am not sure is if the HA could lower down again the value of the Session-Timeout? That would be a possible good reason for including the Session-Timeout AVP in the HAR???? Any thoughts? Note that the Session-Timeout is also discussed in issue 82. Now that we´re talking about it, I am wondering a couple of things. The problem is that the Authorization Session State-Machine (10.1) says that when the Session-Timeout expires on a Diameter client, then an STR is sent. However, when it expires on the AAAH, nothing needs to be sent, only clean-up occurs. That would mean that the FA and the HA would send simultaneously an STR, which would make the AAAH receive 2 STR for the same session, while it is already cleaning the session. Receiving 2 STR is fine, since the AAAH have to support MIP roaming between different FAs. However, it is not so good to be already cleaning the session in the AAAH, while 2 STR are expected. Unless I don't have a good understanding of the Session-Timeout AVP, I think it would not work very well. What do you think? Maybe an issue should be raised about it. Martin > Thanks, > > -Panos > From owner-aaa-wg@merit.edu Thu Jul 5 04:05:26 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04854 for ; Thu, 5 Jul 2001 04:05:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56FE191213; Thu, 5 Jul 2001 04:05:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F1869122A; Thu, 5 Jul 2001 04:05:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1696691213 for ; Thu, 5 Jul 2001 04:05:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9325F5DDC4; Thu, 5 Jul 2001 04:06:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by segue.merit.edu (Postfix) with ESMTP id BB2B45DD93 for ; Thu, 5 Jul 2001 04:06:48 -0400 (EDT) Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f65869308440 for ; Thu, 5 Jul 2001 11:06:09 +0300 (EET DST) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 5 Jul 2001 11:05:51 +0300 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 5 Jul 2001 11:05:02 +0300 Message-ID: From: jaakko.rajaniemi@nokia.com To: aaa-wg@merit.edu Subject: [AAA-WG]: NAS-Key-Binding should be optional in NAS-Session Key AVP (NASREQ ) Date: Thu, 5 Jul 2001 11:04:54 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, The ABNF grammar of the NAS-Session Key AVP is following: NAS-Session-Key ::= < AVP Header: 408 > { NAS-Key-Direction } { NAS-Key-Type } { NAS-Key } { NAS-Key-Binding } * [ AVP ] However, the description of the NAS-Key-Binding AVP says that: "This AVP MAY be present in a response from the Diameter server to inform the client of the type of key found in the NAS-Session-Key AVP." In order to make the ABNF grammar correct for the NAS-Session-Key AVP then the NAS-Key-Binding AVP should be optional. Right? Br, Jaakko From owner-aaa-wg@merit.edu Fri Jul 6 06:38:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25568 for ; Fri, 6 Jul 2001 06:38:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FC0C91238; Fri, 6 Jul 2001 06:38:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDB3391239; Fri, 6 Jul 2001 06:38:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACE1491238 for ; Fri, 6 Jul 2001 06:38:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5DB795DDBC; Fri, 6 Jul 2001 06:40:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id A4CAD5DD98 for ; Fri, 6 Jul 2001 06:40:04 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f66Ad6O14858 for ; Fri, 6 Jul 2001 12:39:06 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 06 12:38:59 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jul 2001 12:38:56 +0200 Message-ID: <577066326047D41180AC00508B955DDA05833C75@eestqnt104.es.eu.ericsson.se> From: "Marta Morant-Artazkotz (ECE)" To: Mark Eklund , aaa-wg@merit.edu Subject: RE: [AAA-WG]: draft-koehler-aaa-diameter-base-protocol-mib-00.txt Date: Fri, 6 Jul 2001 12:42:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I need some clarification regarding some of the objects defined in the diameterPerPeerStatsTable: - diameterPeerStatsAccSessState: this object is described as "state of accounting services" its possible values are (almost all) the states defined in the authorization session state machine does it have any sense define the session state per peer? one session per peer? IMHO, sessions are related to home servers, not any server, and there are several per each one... - diameterPeerStatsFailAccRequestes: this object is described as "failed accounting requests in and out per peer" again, does it have any senses define this per peer? IMHO, accounting requests are proccessed by home servers, not any server, any peer.. - diameterPeerStatsState: this object is described as "state of peer that Diameter server is communicating with" its possible values are (almost all) the states defined in the peer state machine in the base draft -05 IMHO, its possible values should be the states defined in the peer state machine in the base draft -06 - diameterPeerStatsEndToEndErrorrs: this object is described as "end to end error count" IMHO, end to end errors are proccessed by home servers, not any server, any peer.. - diameterPeerStatsTransientFailure, diameterPeerStatsPermanentFailure, diameterPeerStatsInfoEvent, diameterPeerStatsRedirectEvent IMHO, this objects should be alligned with the classes of errors defined in the draft -06 - diameterPeerStatsSessTerminSent what is the difference between this object and the diameterPeerStatsSTROut? Thank you in advance. Regards, Marta -----Original Message----- From: Mark Eklund [mailto:meklund@cisco.com] Sent: Monday, July 02, 2001 7:24 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-koehler-aaa-diameter-base-protocol-mib-00.txt All, Jay Koehler has created a mib for the Diameter base protocol and submitted it to IETF. It is available at http://www.ietf.org/internet-drafts/draft-koehler-aaa-diameter-base-protocol-mib-00.txt If it is O.K. with the list, please use aaa-wg@merit.edu to discuss any issues with this draft. -mark From owner-aaa-wg@merit.edu Fri Jul 6 08:28:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29048 for ; Fri, 6 Jul 2001 08:28:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8725D91239; Fri, 6 Jul 2001 08:28:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 550C79123A; Fri, 6 Jul 2001 08:28:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BC6791239 for ; Fri, 6 Jul 2001 08:28:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DA1C25DDC8; Fri, 6 Jul 2001 08:29:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 0898E5DD90 for ; Fri, 6 Jul 2001 08:29:50 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f66CSqO05123 for ; Fri, 6 Jul 2001 14:28:52 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 06 14:28:51 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 6 Jul 2001 14:28:49 +0200 Message-ID: <3DFC2DB418B2D211A1950008C7A4E1EA611FC4@eestqnt102> From: "Guillermo Guardia-Lozano (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Accounting questions Date: Fri, 6 Jul 2001 14:27:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, After reading the base draft I have several question regarding "Accounting" and maybe somebody in the list can clarify them. First I have included the parts of the document that all together lead me to confusion and, at the end, my questions. Thanks in advance. Chapter 10.0 When a service only makes use of the Accounting portion of the Diameter protocol, even in combination with an application, the Session-Id is still used to identify user sessions. However, the session termination messages are not used, since a session is signaled as being terminated by issuing an accounting stop message. Chapter 11.5 A particular value of Accounting-Session-Id MUST appear only in one sequence of accounting records from a DIAMETER client, except for the purposes of retransmission. The one sequence that is sent MUST be either one record with Accounting-Record-Type AVP set to the value EVENT_RECORD, or several records starting with one having the value START_RECORD, followed by zero or more INTERIM_RECORD, and a single STOP_RECORD. Chapter 11.6 However, there are certain applications that require multiple accounting sub-sessions. Such applications would send messages with a constant Session-Id AVP, but a different Accounting-Session-Id AVP. Chapter 13.3 The Accounting-Record-Number AVP (AVP Code 485) is of type Unsigned32 and identifies this record within one session. As Session-Id AVPs are globally unique, the combination of Session-Id and Accounting- Record-Number AVPs is also globally unique, and can be used in matching accounting records with confirmations. An easy way to produce unique numbers is to set the value to 0 for records of type EVENT_RECORD and START_RECORD, and set the value to 1 for the first INTERIM_RECORD, 2 for the second, and so on until the value for STOP_RECORD is one more than for the last INTERIM_RECORD. Chapter 13.4 The Accounting-Session-Id AVP (AVP Code 44) is of type UTF8String, following the format specified in section 10.7. The Accounting- Session-Id is not used by the Diameter protocol, since the Session-Id defined in [1] is used for both authentication/authorization and accounting purposes. Q1- If the service only makes use of the Accounting portion, but besides, it requires multiple accounting sub-sessions ( constant Session-Id but a different Accounting-Session-Id ), how is this session signaled as being terminated ? Is still applicable the "Accounting Session State Machine" in chapter 10.2 ? Q2- Are Accounting-Record-Numbers unique within the session ( Session-Id ) or unique within the accounting sub-session (Accounting-Session-Id ) ? Q3- In the message format of and the Accounting-Session-Id AVP appears as mandatory, but the AVP description (chapter 13.4 ) says : "The Accounting-Session-Id is not used by the Diameter protocol, since ...." Is it coherent ? From owner-aaa-wg@merit.edu Mon Jul 9 18:01:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29648 for ; Mon, 9 Jul 2001 18:01:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CE95E91216; Mon, 9 Jul 2001 18:01:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EA2091217; Mon, 9 Jul 2001 18:01:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1120991216 for ; Mon, 9 Jul 2001 18:01:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6C5F15DDF1; Mon, 9 Jul 2001 18:02:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id 9E8DD5DDE9 for ; Mon, 9 Jul 2001 18:02:56 -0400 (EDT) Received: from knox6039 (knox6039.cisco.com [161.44.216.39]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA03974; Mon, 9 Jul 2001 18:01:09 -0400 (EDT) Date: Mon, 9 Jul 2001 18:02:05 -0400 (EDT) From: Mark Eklund X-Sender: meklund@knox6039 To: "Marta Morant-Artazkotz (ECE)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: draft-koehler-aaa-diameter-base-protocol-mib-00.txt In-Reply-To: <577066326047D41180AC00508B955DDA05833C75@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Marta, Thanks for your input. Please see responses inline. On Fri, 6 Jul 2001, Marta Morant-Artazkotz (ECE) wrote: > Hi, > I need some clarification regarding some of the objects defined in the diameterPerPeerStatsTable: > - diameterPeerStatsAccSessState: > this object is described as "state of accounting services" its > possible values are (almost all) the states defined in the > authorization session state machine does it have any sense define > the session state per peer? one session per peer? IMHO, sessions > are related to home servers, not any server, and there are several > per each one... Agreed. This will be removed. > - diameterPeerStatsFailAccRequestes: > this object is described as "failed accounting requests in and > out per peer" again, does it have any senses define this per peer? > IMHO, accounting requests are proccessed by home servers, not any > server, any peer.. Consider a proxy in the middle of the chain. If it attempts to proxy an accounting request and fails, that failure would be counted here. From this you could determine if one of the peers is acting flakey when it comes to responding to accounting requests. > - diameterPeerStatsState: > this object is described as "state of peer that Diameter > server is communicating with" its possible values are (almost all) > the states defined in the peer state machine in the base draft -05 > IMHO, its possible values should be the states defined in the peer > state machine in the base draft -06 Agreed. This will be updated. > - diameterPeerStatsEndToEndErrorrs: > this object is described as "end to end error count" IMHO, end > to end errors are proccessed by home servers, not any server, any > peer.. Agreed. This object will be removed. > - diameterPeerStatsTransientFailure, diameterPeerStatsPermanentFailure, > diameterPeerStatsInfoEvent, diameterPeerStatsRedirectEvent > IMHO, this objects should be alligned with the classes of > errors defined in the draft -06 I believe that the MRA mechanism is changing once again. If it is O.K. with you, we will wait until draft -07 to update this. > - diameterPeerStatsSessTerminSent > what is the difference between this object and the > diameterPeerStatsSTROut? Agreed. This object will be removed. Again, thanks for your input. I welcome any more you have. -mark > Thank you in advance. > Regards, > Marta > > -----Original Message----- > From: Mark Eklund [mailto:meklund@cisco.com] > Sent: Monday, July 02, 2001 7:24 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: draft-koehler-aaa-diameter-base-protocol-mib-00.txt > > > All, > > Jay Koehler has created a mib for the Diameter base protocol and > submitted it to IETF. It is available at > > http://www.ietf.org/internet-drafts/draft-koehler-aaa-diameter-base-protocol-mib-00.txt > > If it is O.K. with the list, please use aaa-wg@merit.edu to > discuss any issues with this draft. > > -mark > > > > From owner-aaa-wg@merit.edu Tue Jul 10 12:31:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07325 for ; Tue, 10 Jul 2001 12:31:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EBD39122B; Tue, 10 Jul 2001 12:31:42 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B36269122C; Tue, 10 Jul 2001 12:31:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3FDEE9122B for ; Tue, 10 Jul 2001 12:31:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC6285DE1A; Tue, 10 Jul 2001 12:33:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4FFEA5DD94 for ; Tue, 10 Jul 2001 12:33:04 -0400 (EDT) Received: (qmail 11389 invoked by uid 500); 10 Jul 2001 16:21:17 -0000 Date: Tue, 10 Jul 2001 09:21:17 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Thomas Panagiotis-PTHOMAS1'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft-06 Message-ID: <20010710092117.D10676@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Thomas Panagiotis-PTHOMAS1' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9F3@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9F3@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Wed, Jul 04, 2001 at 10:42:32AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit > My understanding is that the Session-Timeout AVP is used to represent > the time limit of a user-session in a Diameter node. It is used in > the AMR to inform the AAAH about the maximum duration of the session in > the Diameter client. That means that the AAAH can accept the hint, or > change it for a lower value. It is then forwarded to the HA in the HAR, > in order to clean the session accordingly at the session-timeout. So, > basically, my understanding is that the FA, the AAAF, the AAAH and the > HA should have the same value of the Session-Timeout, right? It seems > to be only one final value of the Session-Timeout, which is decided by > the AAAH. What I am not sure is if the HA could lower down again the > value of the Session-Timeout? That would be a possible good reason for > including the Session-Timeout AVP in the HAR???? Any thoughts? The HA cannot lower the Session-Timeout. It is an AAAH policy. The HA can force the mobile to reregister by including the desired value in the RRP lifetime field. > > Note that the Session-Timeout is also discussed in issue 82. > > Now that we´re talking about it, I am wondering a couple of things. > The problem is that the Authorization Session State-Machine (10.1) > says that when the Session-Timeout expires on a Diameter client, > then an STR is sent. However, when it expires on the AAAH, nothing > needs to be sent, only clean-up occurs. That would mean that the FA > and the HA would send simultaneously an STR, which would make the > AAAH receive 2 STR for the same session, while it is already cleaning > the session. Receiving 2 STR is fine, since the AAAH have to support > MIP roaming between different FAs. However, it is not so good to be > already cleaning the session in the AAAH, while 2 STR are expected. > Unless I don't have a good understanding of the > Session-Timeout AVP, I think it would not work very well. What do you > think? Maybe an issue should be raised about it. The mobileip application states that a different session-id is used for the FA-AAAH and the AAAH-HA session, so while 2 STRs would be received, they would be for 2 separate sessions. This is needed since a MN movement would cause the old FA to issue an STR, and we don't want this to clean up AAAH-HA resources. Hope this addresses your comments, PatC > > Martin > > > Thanks, > > > > -Panos > > > From owner-aaa-wg@merit.edu Tue Jul 10 12:44:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08007 for ; Tue, 10 Jul 2001 12:44:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1219F9122F; Tue, 10 Jul 2001 12:44:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D21C89124E; Tue, 10 Jul 2001 12:44:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B99329122F for ; Tue, 10 Jul 2001 12:44:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A25BD5DE03; Tue, 10 Jul 2001 12:45:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 10C3E5DD94 for ; Tue, 10 Jul 2001 12:45:27 -0400 (EDT) Received: (qmail 11474 invoked by uid 500); 10 Jul 2001 16:33:40 -0000 Date: Tue, 10 Jul 2001 09:33:40 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: NAS-Key-Binding should be optional in NAS-Session Key AVP (NASREQ ) Message-ID: <20010710093340.G10676@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jaakko.rajaniemi@nokia.com on Thu, Jul 05, 2001 at 11:04:54AM +0300 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 05, 2001 at 11:04:54AM +0300, jaakko.rajaniemi@nokia.com wrote: > Hi, > > The ABNF grammar of the NAS-Session Key AVP is following: > > NAS-Session-Key ::= < AVP Header: 408 > > { NAS-Key-Direction } > { NAS-Key-Type } > { NAS-Key } > { NAS-Key-Binding } > * [ AVP ] > > However, the description of the NAS-Key-Binding AVP says that: > > "This AVP MAY be present in a response from the Diameter server to inform > the client of the type of key found in the NAS-Session-Key AVP." > > In order to make the ABNF grammar correct for the NAS-Session-Key AVP then > the NAS-Key-Binding AVP should be optional. Right? No, I believe that the correct fix is to change MAY to MUST in the NAS-Key-Binding AVP definition. I'll create an issue for this later today. PatC > > Br, Jaakko From owner-aaa-wg@merit.edu Tue Jul 10 12:44:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08025 for ; Tue, 10 Jul 2001 12:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88BF49122C; Tue, 10 Jul 2001 12:36:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58ADA9122F; Tue, 10 Jul 2001 12:36:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C23C9122C for ; Tue, 10 Jul 2001 12:36:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 003155DE03; Tue, 10 Jul 2001 12:38:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9C9CF5DD94 for ; Tue, 10 Jul 2001 12:37:59 -0400 (EDT) Received: (qmail 11414 invoked by uid 500); 10 Jul 2001 16:26:13 -0000 Date: Tue, 10 Jul 2001 09:26:13 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft-06 Message-ID: <20010710092612.E10676@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Wed, Jul 04, 2001 at 03:18:39PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk > Session Management is generic and defined across applications > (MIPv4,Dial-up,...). The Session-Timeout AVP is tied to a > Session-Id, therefore each session has its own Session-Timeout. correct. > Diameter entities initiate sessions by sending Application-Specific > requests which MAY carry a proposed value for the Session-Timeout. > However, the receiver of the request has the last word on the value > of the Session-Timeout, which is sent in the corresponding answer. > Offering MIPv4 service to a user requires the establishment of > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > where [ ] indicates the initiator of the session. The sessions > are tied together through the Accounting-Multi-Session-Id. The AAAH, acting as a server, always has the final say on the session and authorization timeouts. > > So, if the above is the indent, then the Session-Timeout AVP > should be included (as optional) in the definition of the AMR/AMA, > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > be included (as mandatory) in the HAR message to inform the HA on > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > be noted somewhere that the trigger for initiating sessions is not > always an Auth Request from the Client, but MAY be an application > specific message (HAR) coming from a Server. How could the AAAH cause the FA to force the mobile to re-register? I'm not sure that I understand your point here. PatC From owner-aaa-wg@merit.edu Tue Jul 10 14:09:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12474 for ; Tue, 10 Jul 2001 14:09:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73DB891230; Tue, 10 Jul 2001 14:09:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 45D5991231; Tue, 10 Jul 2001 14:09:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3574791230 for ; Tue, 10 Jul 2001 14:08:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34D5A5DDD8; Tue, 10 Jul 2001 14:10:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 976A25DD93 for ; Tue, 10 Jul 2001 14:10:27 -0400 (EDT) Received: (qmail 14782 invoked by uid 500); 10 Jul 2001 17:58:40 -0000 Date: Tue, 10 Jul 2001 10:58:40 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 93: End-to-End Identifier Message-ID: <20010710105840.P10676@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Here's my proposed language to resolve issue 93, following Paul's proposal found at http://www.merit.edu/mail.archives/aaa-wg/msg01528.html "End-to-End Identifier The End-to-End Identifier is used to detect duplicate messages. Upon reboot, the high order 12 bits are initiated to contain the low order 12 bits of current time, while the low order 20 bits is set to zero (0). For devices that take less than one second to reboot, the high order 12 bits should be incremented by one. Senders of request or answer messages MUST insert a unique identifier on each message, by monotonically incrementing the low order 20 bits. The End-to-End Identifier MUST NOT be modified by relay agents. The combination of the Origin-Host and this field is used to detect duplicates. Duplicate answer messages that are to be locally consumed (see Section 6.2) SHOULD be silently discarded." Comments appreciated, PatC From owner-aaa-wg@merit.edu Tue Jul 10 16:16:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21063 for ; Tue, 10 Jul 2001 16:16:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72E2F91257; Tue, 10 Jul 2001 16:13:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 422B091259; Tue, 10 Jul 2001 16:13:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A05D91257 for ; Tue, 10 Jul 2001 16:13:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 09DB35DE0F; Tue, 10 Jul 2001 16:14:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A282C5DE0D for ; Tue, 10 Jul 2001 16:14:39 -0400 (EDT) Received: (qmail 17049 invoked by uid 500); 10 Jul 2001 20:02:52 -0000 Date: Tue, 10 Jul 2001 13:02:52 -0700 From: Pat Calhoun To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: NAS-Key-Binding should be optional in NAS-Session Key AVP (NASREQ ) Message-ID: <20010710130252.V10676@charizard.diameter.org> Mail-Followup-To: jaakko.rajaniemi@nokia.com, aaa-wg@merit.edu References: <20010710093340.G10676@charizard.diameter.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010710093340.G10676@charizard.diameter.org>; from pcalhoun@diameter.org on Tue, Jul 10, 2001 at 09:33:40AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 10, 2001 at 09:33:40AM -0700, Pat Calhoun wrote: > On Thu, Jul 05, 2001 at 11:04:54AM +0300, jaakko.rajaniemi@nokia.com wrote: > > Hi, > > > > The ABNF grammar of the NAS-Session Key AVP is following: > > > > NAS-Session-Key ::= < AVP Header: 408 > > > { NAS-Key-Direction } > > { NAS-Key-Type } > > { NAS-Key } > > { NAS-Key-Binding } > > * [ AVP ] > > > > However, the description of the NAS-Key-Binding AVP says that: > > > > "This AVP MAY be present in a response from the Diameter server to inform > > the client of the type of key found in the NAS-Session-Key AVP." > > > > In order to make the ABNF grammar correct for the NAS-Session-Key AVP then > > the NAS-Key-Binding AVP should be optional. Right? > > No, I believe that the correct fix is to change MAY to MUST in the > NAS-Key-Binding AVP definition. > > I'll create an issue for this later today. Having looked at the text, I changed the text to: " The NAS-Key-Binding AVP (AVP Code 404) is of type Enumerated, and specifies the purpose for the key. A Diameter client MAY include this AVP in a request to specify to the Diameter server the type of key it desires. Responses that include the NAS-Session-Key AVP MUST include this AVP which is used to specify the type of key found in the NAS-Key-Data AVP." The reason for the MAY, was that the NAS-Key-Session MAY be present, but if it is, the NAS-Key-Binding MUST be present. PatC PatC From owner-aaa-wg@merit.edu Tue Jul 10 16:29:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22106 for ; Tue, 10 Jul 2001 16:29:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A33CA9125D; Tue, 10 Jul 2001 16:15:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6E78C91260; Tue, 10 Jul 2001 16:15:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCA379125D for ; Tue, 10 Jul 2001 16:15:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F6E95DE0D; Tue, 10 Jul 2001 16:17:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A3ADF5DDD8 for ; Tue, 10 Jul 2001 16:17:10 -0400 (EDT) Received: (qmail 17057 invoked by uid 500); 10 Jul 2001 20:05:23 -0000 Date: Tue, 10 Jul 2001 13:05:23 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 16: Redirect Server Certificates Message-ID: <20010710130523.W10676@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Following the suggestion I sent to the list before leaving for vacation, I am proposing adding the following paragraph to section 3.2 of the CMS security draft: " For multiple Diameter servers within a domain that share a public key, each server's identity is encoded in the subjectAltName extension. This allows any server within a domain to decrypt AVPs intended for that domain." Comments welcome, PatC From owner-aaa-wg@merit.edu Tue Jul 10 16:52:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23741 for ; Tue, 10 Jul 2001 16:52:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9607D91232; Tue, 10 Jul 2001 16:52:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63FD091256; Tue, 10 Jul 2001 16:52:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5185F91232 for ; Tue, 10 Jul 2001 16:52:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5B2515DDEF; Tue, 10 Jul 2001 16:54:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C3F8B5DDD8 for ; Tue, 10 Jul 2001 16:54:20 -0400 (EDT) Received: (qmail 17208 invoked by uid 500); 10 Jul 2001 20:42:33 -0000 Date: Tue, 10 Jul 2001 13:42:33 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 91: MIP SPI Message-ID: <20010710134232.Z10676@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1A9E4@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1A9E4@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Jun 29, 2001 at 09:59:12AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Finally getting back into things... On Fri, Jun 29, 2001 at 09:59:12AM +0200, Martin Julien (ECE) wrote: > The HA would select a SPI for the MN-HA SA and the FA-HA SA. > The thing is that it is not so easy for the FA to suggest a > Preferred HA-FA SPI, since it might not know the HA yet, since > it needs to be allocated by the AAAH. The HA-FA SPI, allocated by the > HA, could be returned in the HAA, to inform the AAAH about it, > so that it can include it in the FA-HA Key AVP destined to the FA. > In that example, there is no need for a Preferred HA-FA SPI, neither > for a Preferred HA-MN SPI, right? correct. > > The FA would then be responsible for allocating the SPI of the SA > between the FA and the MN. In the AMR, the FA would include the > allocated FA-MN SPI for the AAAF to keep the SPI value, in case > it supports returning an existing set of Session keys a new > FA, when the MN is roaming. In that example, there is no need for > a Preferred MN-FA SPI, right? ok, but *some* AVP will be required to communicate the SPI value to the AAAF. > > ok, so the Diameter draft could state that the AAAH still > > inserts an SPI, but > > the HA is allowed to override that value if it is deemed > > necessary. Would this > > work? > > I think so, but I still do not see the need for the AAAH to be > involved at all in that allocation, not even in forwarding the > Preferred-SPI. what do other folks think?? > > Not sure. I think that the Preferred-SPIs MUST be present for > > key request, > > since the SPIs are present in the MIP Key Request extension, so it is > > trivial for an FA to include these values in the Diameter > > message. I think > > that we should mandate that the FA include these values. What > > do you think? > > But maybe not the HA-FA SPI, in the case where you do not know the > HA yet? correct. > It depends if you agree with me that the Preferred-SPI AVPs are not required. > I think we could use them, but since I don't see them very useful, > I think it would simplify the protocol to remove them and use an alternative > solution, which can never be wrong. Maybe you're thinking of something I > have not realized yet, though? Well, The MIP Key extensions allow the mobile to "suggest" an SPI. If this information cannot be communicated to the AAAH, and the AAA infrastructure generates SPIs, then we have a problem. If we can agree that SPI allocation is not the responsibility of the AAAH, then the simplest solution is to remove the AVPs, and add a little text about returning the SPIs in the HAA. Others? PatC From owner-aaa-wg@merit.edu Wed Jul 11 10:29:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05182 for ; Wed, 11 Jul 2001 10:29:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 446C59123C; Wed, 11 Jul 2001 10:18:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 186A19123D; Wed, 11 Jul 2001 10:18:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9ED99123C for ; Wed, 11 Jul 2001 10:18:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65C305DD90; Wed, 11 Jul 2001 10:19:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id C0FE75DD8F for ; Wed, 11 Jul 2001 10:19:45 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id HAA19450 for ; Wed, 11 Jul 2001 07:11:36 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA19919 for ; Wed, 11 Jul 2001 07:18:41 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3LL2KMCZ>; Wed, 11 Jul 2001 09:18:41 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , Thomas Panagiotis-PTHOMAS1 Cc: "'Martin Julien \\(ECE\\)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06 Date: Wed, 11 Jul 2001 09:18:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > > So, if the above is the intent, then the Session-Timeout AVP > > should be included (as optional) in the definition of the AMR/AMA, > > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > > be included (as mandatory) in the HAR message to inform the HA on > > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > > be noted somewhere that the trigger for initiating sessions is not > > always an Auth Request from the Client, but MAY be an application > > specific message (HAR) coming from a Server. > > How could the AAAH cause the FA to force the mobile to re-register? I'm > not sure that I understand your point here. Let me try one more time... AAAH will have at least 2 session state machines (SMs) on behalf of a user. One for the session with the serving FA (FA-AAAH) and one for the session with the HA (AAAH-HA). Correct? Consider the session between the AAAH and the HA. What's the event/action for the transition from Idle to Pending on the AAAH side? What's the event/action for the transition from Idle to Open on the HA side? > > Diameter entities initiate sessions by sending Application-Specific > > requests which MAY carry a proposed value for the Session-Timeout. > > However, the receiver of the request has the last word on the value > > of the Session-Timeout, which is sent in the corresponding answer. > > Offering MIPv4 service to a user requires the establishment of > > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > > where [ ] indicates the initiator of the session. The sessions > > are tied together through the Accounting-Multi-Session-Id. > > The AAAH, acting as a server, always has the final say on the session > and authorization timeouts. I agree. How would this be enforced for the Session-Timeout value? a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST accept the value. In this case there is no need to return the value to AAAH. b) AAAH sends a HAR message to HA with the preferred Session-Timeout value and the Authorization-Lifetime AVP. If HA doesn't like the Session-Timeout it can propose any value larger than the Authorization-Lifetime AVP. If AAAH doesn't like the value it sends back an error. So, is (a) what you have in mind? -Panos -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: 10 July 2001 11:26 To: Thomas Panagiotis-PTHOMAS1 Cc: 'Martin Julien \(ECE\)'; 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft-06 > Session Management is generic and defined across applications > (MIPv4,Dial-up,...). The Session-Timeout AVP is tied to a > Session-Id, therefore each session has its own Session-Timeout. correct. > Diameter entities initiate sessions by sending Application-Specific > requests which MAY carry a proposed value for the Session-Timeout. > However, the receiver of the request has the last word on the value > of the Session-Timeout, which is sent in the corresponding answer. > Offering MIPv4 service to a user requires the establishment of > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > where [ ] indicates the initiator of the session. The sessions > are tied together through the Accounting-Multi-Session-Id. The AAAH, acting as a server, always has the final say on the session and authorization timeouts. > > So, if the above is the intent, then the Session-Timeout AVP > should be included (as optional) in the definition of the AMR/AMA, > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > be included (as mandatory) in the HAR message to inform the HA on > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > be noted somewhere that the trigger for initiating sessions is not > always an Auth Request from the Client, but MAY be an application > specific message (HAR) coming from a Server. How could the AAAH cause the FA to force the mobile to re-register? I'm not sure that I understand your point here. PatC From owner-aaa-wg@merit.edu Wed Jul 11 11:01:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06429 for ; Wed, 11 Jul 2001 11:01:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 93AB89123D; Wed, 11 Jul 2001 11:01:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F9229123E; Wed, 11 Jul 2001 11:01:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2690B9123D for ; Wed, 11 Jul 2001 11:01:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C47575DDB1; Wed, 11 Jul 2001 11:03:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 081525DDA9 for ; Wed, 11 Jul 2001 11:03:12 -0400 (EDT) Received: (qmail 31639 invoked by uid 500); 11 Jul 2001 14:51:20 -0000 Date: Wed, 11 Jul 2001 07:51:20 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06 Message-ID: <20010711075120.M27470@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Wed, Jul 11, 2001 at 09:18:40AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 11, 2001 at 09:18:40AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > > > So, if the above is the intent, then the Session-Timeout AVP > > > should be included (as optional) in the definition of the AMR/AMA, > > > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > > > be included (as mandatory) in the HAR message to inform the HA on > > > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > > > be noted somewhere that the trigger for initiating sessions is not > > > always an Auth Request from the Client, but MAY be an application > > > specific message (HAR) coming from a Server. > > > > How could the AAAH cause the FA to force the mobile to re-register? I'm > > not sure that I understand your point here. > > Let me try one more time... > > AAAH will have at least 2 session state machines (SMs) on behalf of a user. > One for the session with the serving FA (FA-AAAH) and one for the session > with the HA (AAAH-HA). Correct? yes > > Consider the session between the AAAH and the HA. What's the event/action > for the transition from Idle to Pending on the AAAH side? Sending the HAR moves it from Idle to Pending, this is the first event in the state machine. The HAA moves it to Open. > What's the > event/action > for the transition from Idle to Open on the HA side? Receiving, and successfully processing the HAA. This is the second event in the state machine. I am still missing the issue, though :( > > > > Diameter entities initiate sessions by sending Application-Specific > > > requests which MAY carry a proposed value for the Session-Timeout. > > > However, the receiver of the request has the last word on the value > > > of the Session-Timeout, which is sent in the corresponding answer. > > > Offering MIPv4 service to a user requires the establishment of > > > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > > > where [ ] indicates the initiator of the session. The sessions > > > are tied together through the Accounting-Multi-Session-Id. > > > > The AAAH, acting as a server, always has the final say on the session > > and authorization timeouts. > > I agree. How would this be enforced for the Session-Timeout value? > a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST > accept the value. In this case there is no need to return the value > to AAAH. correct. > b) AAAH sends a HAR message to HA with the preferred Session-Timeout value > and the Authorization-Lifetime AVP. If HA doesn't like the > Session-Timeout > it can propose any value larger than the Authorization-Lifetime AVP. If > AAAH doesn't like the value it sends back an error. no, the HA cannot increase the Session-Timeout. However, if the HA is in a foreign network, I *suppose* it (or the AAAF processing the HAR/HAA) should be permitted to lower the Session-Timeout and/or Authorization-Lifetime AVPs. > > So, is (a) what you have in mind? That was my initial thought, but (b) now sounds quite feasible. PatC From owner-aaa-wg@merit.edu Wed Jul 11 12:23:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09841 for ; Wed, 11 Jul 2001 12:22:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 91F5491260; Wed, 11 Jul 2001 12:22:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6060C91262; Wed, 11 Jul 2001 12:22:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3517691260 for ; Wed, 11 Jul 2001 12:22:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EA5D85DDA9; Wed, 11 Jul 2001 12:24:27 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id C513A5DD93 for ; Wed, 11 Jul 2001 12:24:26 -0400 (EDT) Received: (qmail 548 invoked by uid 500); 11 Jul 2001 16:12:35 -0000 Date: Wed, 11 Jul 2001 09:12:35 -0700 From: Pat Calhoun To: Thomas Panagiotis-PTHOMAS1 Cc: "'Pat Calhoun'" , "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06 Message-ID: <20010711091235.S27470@charizard.diameter.org> Mail-Followup-To: Thomas Panagiotis-PTHOMAS1 , 'Pat Calhoun' , "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from panos.thomas@motorola.com on Wed, Jul 11, 2001 at 11:10:51AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 11, 2001 at 11:10:51AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > I think we are in sync now! :) Please see comments below. > > > > Consider the session between the AAAH and the HA. What's the event/ > > > action for the transition from Idle to Pending on the AAAH side? > > > > Sending the HAR moves it from Idle to Pending, this is the first event > > in the state machine. The HAA moves it to Open. > > > > > What's the event/action for the transition from Idle to Open on the > > > HA side? > > > > Receiving, and successfully processing the HAA. This is the second event > > in the state machine. > > It's HAR right? oops, right. > > > > > I am still missing the issue, though :( > > It's only editorial. Below is the description of the session state machine > in > 10.1 of diameter-05.txt. If it is clear to everyone that HAR *is* a > "Service- > Specific authorization request", then there is no issue at all :) you are correct, and yes I agree there is no issue :) PatC > > State Event Action New State > ------------------------------------------------------------- > Idle Client or Device Requests send Pending > access service > specific > auth req > > Idle Service-Specific authorization send serv. Open > request received, and specific > successfully processed answer > > Pending Successful Service-Specific Grant Open > Authorization answer Access > received > > -Panos > > > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: 11 July 2001 09:51 > To: Thomas Panagiotis-PTHOMAS1 > Cc: 'Pat Calhoun'; 'Martin Julien (ECE)'; 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP > draft- 06 > > > On Wed, Jul 11, 2001 at 09:18:40AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > > > > So, if the above is the intent, then the Session-Timeout AVP > > > > should be included (as optional) in the definition of the AMR/AMA, > > > > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > > > > be included (as mandatory) in the HAR message to inform the HA on > > > > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > > > > be noted somewhere that the trigger for initiating sessions is not > > > > always an Auth Request from the Client, but MAY be an application > > > > specific message (HAR) coming from a Server. > > > > > > How could the AAAH cause the FA to force the mobile to re-register? I'm > > > not sure that I understand your point here. > > > > Let me try one more time... > > > > AAAH will have at least 2 session state machines (SMs) on behalf of a > user. > > One for the session with the serving FA (FA-AAAH) and one for the session > > with the HA (AAAH-HA). Correct? > yes > > > > > Consider the session between the AAAH and the HA. What's the event/action > > for the transition from Idle to Pending on the AAAH side? > > Sending the HAR moves it from Idle to Pending, this is the first event in > the state machine. The HAA moves it to Open. > > > What's the > > event/action > > for the transition from Idle to Open on the HA side? > > Receiving, and successfully processing the HAA. This is the second event in > the > state machine. > > I am still missing the issue, though :( > > > > > > > > Diameter entities initiate sessions by sending Application-Specific > > > > requests which MAY carry a proposed value for the Session-Timeout. > > > > However, the receiver of the request has the last word on the value > > > > of the Session-Timeout, which is sent in the corresponding answer. > > > > Offering MIPv4 service to a user requires the establishment of > > > > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > > > > where [ ] indicates the initiator of the session. The sessions > > > > are tied together through the Accounting-Multi-Session-Id. > > > > > > The AAAH, acting as a server, always has the final say on the session > > > and authorization timeouts. > > > > I agree. How would this be enforced for the Session-Timeout value? > > a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST > > accept the value. In this case there is no need to return the value > > to AAAH. > > correct. > > > b) AAAH sends a HAR message to HA with the preferred Session-Timeout value > > and the Authorization-Lifetime AVP. If HA doesn't like the > > Session-Timeout > > it can propose any value larger than the Authorization-Lifetime AVP. If > > AAAH doesn't like the value it sends back an error. > > no, the HA cannot increase the Session-Timeout. However, if the HA is in a > foreign network, I *suppose* it (or the AAAF processing the HAR/HAA) should > be permitted to lower the Session-Timeout and/or Authorization-Lifetime > AVPs. > > > > > So, is (a) what you have in mind? > > That was my initial thought, but (b) now sounds quite feasible. > > PatC From owner-aaa-wg@merit.edu Wed Jul 11 13:44:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13186 for ; Wed, 11 Jul 2001 13:44:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0B4E9125C; Wed, 11 Jul 2001 12:10:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8288E9125E; Wed, 11 Jul 2001 12:10:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7043F9125C for ; Wed, 11 Jul 2001 12:10:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 32D2D5DDA9; Wed, 11 Jul 2001 12:11:56 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 0F88D5DD93 for ; Wed, 11 Jul 2001 12:11:56 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA01416 for ; Wed, 11 Jul 2001 09:10:52 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA09602 for ; Wed, 11 Jul 2001 09:10:51 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3LL2KQ21>; Wed, 11 Jul 2001 11:10:51 -0500 Message-ID: From: Thomas Panagiotis-PTHOMAS1 To: "'Pat Calhoun'" , Thomas Panagiotis-PTHOMAS1 Cc: "'Martin Julien (ECE)'" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06 Date: Wed, 11 Jul 2001 11:10:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk I think we are in sync now! :) Please see comments below. > > Consider the session between the AAAH and the HA. What's the event/ > > action for the transition from Idle to Pending on the AAAH side? > > Sending the HAR moves it from Idle to Pending, this is the first event > in the state machine. The HAA moves it to Open. > > > What's the event/action for the transition from Idle to Open on the > > HA side? > > Receiving, and successfully processing the HAA. This is the second event > in the state machine. It's HAR right? > > I am still missing the issue, though :( It's only editorial. Below is the description of the session state machine in 10.1 of diameter-05.txt. If it is clear to everyone that HAR *is* a "Service- Specific authorization request", then there is no issue at all :) State Event Action New State ------------------------------------------------------------- Idle Client or Device Requests send Pending access service specific auth req Idle Service-Specific authorization send serv. Open request received, and specific successfully processed answer Pending Successful Service-Specific Grant Open Authorization answer Access received -Panos -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: 11 July 2001 09:51 To: Thomas Panagiotis-PTHOMAS1 Cc: 'Pat Calhoun'; 'Martin Julien (ECE)'; 'aaa-wg@merit.edu' Subject: Re: [AAA-WG]: RE: Issue 89: Editorial comments - Mobile-IP draft- 06 On Wed, Jul 11, 2001 at 09:18:40AM -0500, Thomas Panagiotis-PTHOMAS1 wrote: > > > So, if the above is the intent, then the Session-Timeout AVP > > > should be included (as optional) in the definition of the AMR/AMA, > > > HAR/HAA messages. In addition, the Authorization-Lifetime AVP must > > > be included (as mandatory) in the HAR message to inform the HA on > > > the lower limit of the [AAAH]-HA:Session-Timeout. Finally, it should > > > be noted somewhere that the trigger for initiating sessions is not > > > always an Auth Request from the Client, but MAY be an application > > > specific message (HAR) coming from a Server. > > > > How could the AAAH cause the FA to force the mobile to re-register? I'm > > not sure that I understand your point here. > > Let me try one more time... > > AAAH will have at least 2 session state machines (SMs) on behalf of a user. > One for the session with the serving FA (FA-AAAH) and one for the session > with the HA (AAAH-HA). Correct? yes > > Consider the session between the AAAH and the HA. What's the event/action > for the transition from Idle to Pending on the AAAH side? Sending the HAR moves it from Idle to Pending, this is the first event in the state machine. The HAA moves it to Open. > What's the > event/action > for the transition from Idle to Open on the HA side? Receiving, and successfully processing the HAA. This is the second event in the state machine. I am still missing the issue, though :( > > > > Diameter entities initiate sessions by sending Application-Specific > > > requests which MAY carry a proposed value for the Session-Timeout. > > > However, the receiver of the request has the last word on the value > > > of the Session-Timeout, which is sent in the corresponding answer. > > > Offering MIPv4 service to a user requires the establishment of > > > more than one sessions: [FA-1]-AAAH, [FA-2]-AAAH,..., [AAAH]-HA, > > > where [ ] indicates the initiator of the session. The sessions > > > are tied together through the Accounting-Multi-Session-Id. > > > > The AAAH, acting as a server, always has the final say on the session > > and authorization timeouts. > > I agree. How would this be enforced for the Session-Timeout value? > a) AAAH sends a HAR message to HA with a Session-Timeout value. HA MUST > accept the value. In this case there is no need to return the value > to AAAH. correct. > b) AAAH sends a HAR message to HA with the preferred Session-Timeout value > and the Authorization-Lifetime AVP. If HA doesn't like the > Session-Timeout > it can propose any value larger than the Authorization-Lifetime AVP. If > AAAH doesn't like the value it sends back an error. no, the HA cannot increase the Session-Timeout. However, if the HA is in a foreign network, I *suppose* it (or the AAAF processing the HAR/HAA) should be permitted to lower the Session-Timeout and/or Authorization-Lifetime AVPs. > > So, is (a) what you have in mind? That was my initial thought, but (b) now sounds quite feasible. PatC From owner-aaa-wg@merit.edu Thu Jul 12 07:46:36 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06711 for ; Thu, 12 Jul 2001 07:46:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A0B5191285; Thu, 12 Jul 2001 07:46:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7053091286; Thu, 12 Jul 2001 07:46:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43DAF91285 for ; Thu, 12 Jul 2001 07:46:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8EE385DDCE; Thu, 12 Jul 2001 07:48:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 7E8365DE77 for ; Thu, 12 Jul 2001 07:46:22 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6CBjGN03305 for ; Thu, 12 Jul 2001 13:45:16 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Jul 12 13:45:15 2001 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 12 Jul 2001 13:45:15 +0200 Message-ID: <0154633DAF7BD4119C360002A513AA030AC49E@efijont102> From: "Johanna Tuominen (LMF)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: The Diameter XML-file Date: Thu, 12 Jul 2001 13:44:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk In the latest diameter API included a link to an command dictionary file which is described in XML also it includes the DTD. It suppose to be available in following adress: http://www.diameter.org/diameter.xml. Does anyone know anything about this document because we haven't been able to find it. From owner-aaa-wg@merit.edu Thu Jul 12 10:31:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28208 for ; Thu, 12 Jul 2001 10:31:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 29B9391289; Thu, 12 Jul 2001 10:31:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E97AA9128A; Thu, 12 Jul 2001 10:31:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E17B191289 for ; Thu, 12 Jul 2001 10:31:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 69F0B5DDB6; Thu, 12 Jul 2001 10:33:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id C7B9D5DD93 for ; Thu, 12 Jul 2001 10:33:15 -0400 (EDT) Received: (qmail 7697 invoked by uid 500); 12 Jul 2001 14:32:09 -0000 Date: Thu, 12 Jul 2001 09:32:09 -0500 From: David Frascone To: "Johanna Tuominen (LMF)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: The Diameter XML-file Message-ID: <20010712093209.V27418@newman.frascone.com> Mail-Followup-To: "Johanna Tuominen (LMF)" , "'aaa-wg@merit.edu'" References: <0154633DAF7BD4119C360002A513AA030AC49E@efijont102> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <0154633DAF7BD4119C360002A513AA030AC49E@efijont102>; from Johanna.Tuominen@lmf.ericsson.se on Thu, Jul 12, 2001 at 01:44:41PM +0200 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk The Diameter DTD and XML Dictionary are being developed right now, so their state is in constant flux. I will be putting out a new API draft today (or in the morning), and I will make sure that the links point to the most current DTD and dictionary. Sorry for any inconvenience, -Dave On Thu, Jul 12, 2001 at 01:44:41PM +0200, Johanna Tuominen (LMF) wrote: > In the latest diameter API included a link to an command dictionary file which is described in XML also it includes the DTD. > It suppose to be available in following adress: http://www.diameter.org/diameter.xml. Does anyone know anything about this document because we haven't been able to find it. > From owner-aaa-wg@merit.edu Thu Jul 12 14:32:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01721 for ; Thu, 12 Jul 2001 14:32:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 73BF8912A0; Thu, 12 Jul 2001 14:32:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3F136912A1; Thu, 12 Jul 2001 14:32:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2010912A0 for ; Thu, 12 Jul 2001 14:32:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB9B05DDB6; Thu, 12 Jul 2001 14:33:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 62A6C5DDA7 for ; Thu, 12 Jul 2001 14:33:47 -0400 (EDT) Received: (qmail 31432 invoked by uid 500); 12 Jul 2001 17:47:59 -0000 Date: Thu, 12 Jul 2001 10:47:59 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed text for Issue 75 Message-ID: <20010712104759.B5588@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Before I go on I want to mention that we have two alternatives. The first, is to rely solely on configuration to allow server-initited messages to be routed to NASes. In today's networks, such configuration doesn't exist. If we decide to take this option, we will have to include a disclaimer in the draft stating that if reverse routing isn't setup, server-initiated messages will not work, and any application relying on these would perhaps fail. The second option is to include the text below, which allows a server to retain the list of hops taken for a message, and use the list of hops are source routes for reverse messages. If folks feel that making this explicitely supported in the protocol is needed, then the text below would capture the above ideas. I would welcome the following: 1. Do you think the text is needed, or simply configuration 2. Is the text below sufficient? Thanks, PatC ---- 5.3.X Alternate-Peer AVP The Alternate-Peer AVP (AVP Code TBD) is of type diameterIdentity, and contains the URI of an alternate peer that MAY be used in server- initiated requests, when routing using the Source-Route AVP. [...] 6.1.X Relaying and Proxying Server-Initiated Requests Server-initiated messages MUST include the Source-Route AVPs, whose contents are identical to the Record-Route AVPs received in requests from the access device for the given session, but in the reverse order. Agents receiving requests with one or more Source-Route AVP MUST use the last Source-Route AVP in the request to determine the request's next hop. In the event that the next hop encoded in the Source-Route is not reachable, an alternate peer MAY be used if the peer in question had advertised such peers via the Alternate-Peer AVP in the CER or CEA message. [...] 6.8.X Source-Route AVP The Source-Route AVP (AVP Code TBD) is of type DiameterIdentity. This AVP is used for routing decisions by agents for server-initiated messages. The order of the Source-Route AVPs MUST be the inverse of the Route-Record AVPs of auth messages received by the server for the session in question. From owner-aaa-wg@merit.edu Thu Jul 12 14:44:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03507 for ; Thu, 12 Jul 2001 14:44:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EC8869129F; Thu, 12 Jul 2001 14:31:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A35E8912A1; Thu, 12 Jul 2001 14:31:03 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A47C9129F for ; Thu, 12 Jul 2001 14:31:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0BAFC5DE03; Thu, 12 Jul 2001 14:32:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E599B5DDB6 for ; Thu, 12 Jul 2001 14:32:33 -0400 (EDT) Received: (qmail 31279 invoked by uid 500); 12 Jul 2001 17:42:33 -0000 Date: Thu, 12 Jul 2001 10:42:33 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed text for Issue 82 Message-ID: <20010712104233.A5588@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is some proposed text to solve Issue 82. I would welcome comments. PatC ---- 8.9 Authorization-Lifetime AVP The Authorization-Lifetime AVP (AVP Code 291) is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before the user is to be re-authenticated and/or re- authorized. Great care should be taken when the Authorization- Lifetime value is determined, since a low, non-zero, value could create significant Diameter traffic, which could congest both the network and the agents. A value of zero (0) means that immediate re-auth is necessary by the access device. This is typically used in cases where multiple authentication methods are used, and a successful auth response with this AVP set to one is used to signal that the next authentication method is to be immediately initiated. The absence of this AVP, or a value of all ones (-1) means no re-auth is expected. If both this AVP and the Session-Timeout AVP are present in a message, the value of the latter MUST NOT be smaller than the Authorization-Lifetime AVP. An Authorization-Lifetime AVP MAY be present in a re-authorization messages, and contains the number of seconds the user is authorized to receive service from the time the re-auth answer message is received by the access device. This AVP MAY be provided by the client as a hint of the maximum lifetime that it is willing to accept. However, the server MAY return a value that is equal to, or smaller, than the one provided by the client. 8.X Auth-Grace-Period AVP The Auth-Grace-Period AVP (AVP Code TBD) is of type Unsigned32 and contains the number of seconds the Diameter server will wait following the expiration of the Authorization-Lifetime AVP before cleaning up resources for the session. This AVP MAY be provided by the client as a hint of the maximum lifetime that it is willing to accept. However, the server MAY return a value that is equal to, or smaller, than the one provided by the client. Calhoun et al. expires December 2001 [Page 89] Internet-Draft June 2001 8.X Auth-Session-State AVP The Auth-Session-State AVP (AVP Code TBD) is of type Enumerated and specifies whether state is maintained for a particular session. The client MAY include this AVP in requests as a hint to the server. The following values are supported: STATE_MAINTAINED 0 This value is used to specify that session state is being maintained, and the access device MUST issue a session termination message when service to the user is terminated. This is the default value. NO_STATE_MAINTAINED 1 This value is used to specify that no session termination messages will be sent by the access device upon expiration of the Authorization-Lifetime. 8.X Re-Auth-Request-Type AVP The Re-Auth-Request-Type AVP (AVP Code TBD) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expection upon expiration of the Authorization- Lifetime. The following values are defined: AUTHORIZE_ONLY 0 An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization-Lifetime. AUTHORIZE_AUTHENTICATE 1 An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime. 8.10 Session-Timeout AVP The Session-Timeout AVP (AVP Code 27) [1] is of type Unsigned32 and contains the maximum number of seconds of service to be provided to the user before termination of the session. When both the Session- Timeout and the Authorization-Lifetime AVPs are present in an answer message, the former MUST be equal to or greater than the value of the latter. A session that terminates on an access device due to the expiration of the Session-Timeout MUST cause an STR to be issued, unless both Calhoun et al. expires December 2001 [Page 90] Internet-Draft June 2001 the access device and the home server had previously agreed that no session termination messages would be sent (see section 8.9). A Session-Timeout AVP MAY be present in a re-authorization messages, and contains the number of seconds from the beginning of the re-auth. A value of zero, or the absence of this AVP, means that this session has an unlimited number of seconds before termination. This AVP MAY be provided by the client as a hint of the maximum timeout that it is willing to accept. However, the server MAY return a value that is equal to, or smaller, than the one provided by the client. From owner-aaa-wg@merit.edu Thu Jul 12 17:18:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25856 for ; Thu, 12 Jul 2001 17:18:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D7981912A8; Thu, 12 Jul 2001 17:18:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A53DF912A9; Thu, 12 Jul 2001 17:18:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 88EF7912A8 for ; Thu, 12 Jul 2001 17:18:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 997025DDF5; Thu, 12 Jul 2001 17:19:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cisco.com (titans.cisco.com [161.44.72.74]) by segue.merit.edu (Postfix) with ESMTP id CFAFF5DDDC for ; Thu, 12 Jul 2001 17:19:49 -0400 (EDT) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id RAA02329 for aaa-wg@merit.edu; Thu, 12 Jul 2001 17:18:02 -0400 (EDT) From: Greg Weber Message-Id: <200107122118.RAA02329@cisco.com> Subject: [AAA-WG]: IETF-51 To: aaa-wg@merit.edu Date: Thu, 12 Jul 2001 17:18:02 -0400 (EDT) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I believe IETF 51 is only three weeks away. Will an agenda be published for AAA WG? Greg From owner-aaa-wg@merit.edu Thu Jul 12 19:42:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13760 for ; Thu, 12 Jul 2001 19:42:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CCCC3912B4; Thu, 12 Jul 2001 19:42:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98810912B7; Thu, 12 Jul 2001 19:42:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78214912B4 for ; Thu, 12 Jul 2001 19:42:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7E565DE0E; Thu, 12 Jul 2001 19:44:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 178855DE1B for ; Thu, 12 Jul 2001 19:44:29 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA50923 for ; Thu, 12 Jul 2001 16:35:27 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 12 Jul 2001 16:35:27 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Call for agenda items Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is a call for agenda items for IETF 51. If you have an agenda item, send it to myself or Dave Mitton (david@mitton.com). From owner-aaa-wg@merit.edu Thu Jul 12 19:46:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14181 for ; Thu, 12 Jul 2001 19:46:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DCCB6912B7; Thu, 12 Jul 2001 19:46:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8BFD8912B8; Thu, 12 Jul 2001 19:46:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23F22912B7 for ; Thu, 12 Jul 2001 19:46:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4889C5DE1B; Thu, 12 Jul 2001 19:47:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 236205DE0E for ; Thu, 12 Jul 2001 19:47:50 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15Kq8x-0002L4-00; Thu, 12 Jul 2001 16:45:15 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for agenda items References: Message-Id: Date: Thu, 12 Jul 2001 16:45:15 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > This is a call for agenda items for IETF 51. If you have an agenda item, > send it to myself or Dave Mitton (david@mitton.com). mine would be: o review of open issues with diameter drafts o summarize all open issues o plan for closing issues o schedule to get this sucker out the door! randy From owner-aaa-wg@merit.edu Fri Jul 13 10:36:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15477 for ; Fri, 13 Jul 2001 10:36:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 28DB5912CC; Fri, 13 Jul 2001 10:36:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E2463912CD; Fri, 13 Jul 2001 10:36:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC0F0912CC for ; Fri, 13 Jul 2001 10:36:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 392815DDD1; Fri, 13 Jul 2001 10:37:44 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A50505DD91 for ; Fri, 13 Jul 2001 10:37:43 -0400 (EDT) Received: (qmail 24491 invoked by uid 500); 13 Jul 2001 14:25:43 -0000 Date: Fri, 13 Jul 2001 07:25:43 -0700 From: Pat Calhoun To: Randy Bush Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for agenda items Message-ID: <20010713072543.F5588@charizard.diameter.org> Mail-Followup-To: Randy Bush , Bernard Aboba , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from randy@psg.com on Thu, Jul 12, 2001 at 04:45:15PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 12, 2001 at 04:45:15PM -0700, Randy Bush wrote: > > This is a call for agenda items for IETF 51. If you have an agenda item, > > send it to myself or Dave Mitton (david@mitton.com). > > mine would be: > o review of open issues with diameter drafts > o summarize all open issues > o plan for closing issues > o schedule to get this sucker out the door! Not to rain on your parade, but if the current trend continues, not only will we not have any issues to discuss, but the documents will be in last call. What could occur, though, are comments generated in the last call process. Thanks for everyone for their great participation in helping "to get this sucker out the door". PatC From owner-aaa-wg@merit.edu Fri Jul 13 10:57:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18615 for ; Fri, 13 Jul 2001 10:57:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C32E912CD; Fri, 13 Jul 2001 10:57:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17A80912CE; Fri, 13 Jul 2001 10:57:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2218A912CD for ; Fri, 13 Jul 2001 10:57:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9C54A5DE09; Fri, 13 Jul 2001 10:59:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 7C9375DDD1 for ; Fri, 13 Jul 2001 10:59:10 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15L4Mr-000GRH-00; Fri, 13 Jul 2001 07:56:33 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Pat Calhoun Cc: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for agenda items References: <20010713072543.F5588@charizard.diameter.org> Message-Id: Date: Fri, 13 Jul 2001 07:56:33 -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Not to rain on your parade, but if the current trend continues, > not only will we not have any issues to discuss, but the documents > will be in last call. i'll cry all the way to the rfc editor. :-) From owner-aaa-wg@merit.edu Fri Jul 13 12:41:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04055 for ; Fri, 13 Jul 2001 12:41:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22411912CE; Fri, 13 Jul 2001 12:41:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3DA6912CF; Fri, 13 Jul 2001 12:41:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A3378912CE for ; Fri, 13 Jul 2001 12:41:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 381885DE09; Fri, 13 Jul 2001 12:42:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 61D175DD96 for ; Fri, 13 Jul 2001 12:42:37 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id JAA52096 for ; Fri, 13 Jul 2001 09:33:31 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Fri, 13 Jul 2001 09:33:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Roadmap Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk For the last several months, we have been engaged in a fairly vigorous process of generating issues, and resolving them. More than 90 issues have been posted and all but a handful are resolved at this point. With the incoming rate of new issues declining to a trickle, we are entering the final phase of our efforts. This is a note to describe where we go from here. 1. Pat will be posting a revised draft set before the deadline, incorporating the latest issue resolutions. This draft set will be the basis of the discussion in London. I'd encourage everyone to read it carefully. 2. Some time after the revised draft set comes out, we will go to WG last call. In order to track last call issues, we ask that people post their issues in the same format that we have been using. This makes it easier to track the last call issues, and keep track of how we are resolving them. If you have any reservations about the Diameter drafts, or any suggested edits, there will not be any better time to raise them. Please set aside the time to do a thorough reading of the drafts so that we can get all the last call issues out on the table. 3. The London meeting will focus primarily on discussing issues. So far we don't have any other agenda suggestions, so please get them in. 4. Depending on how many last call issues we have, we may decide to hold an interim meeting to help get closure. 5. Once the last call issues are resolved, Pat will make the edits, and we will send the documents on to the IESG. While I don't want to set any precise timetable for items #1-5, my expectation is that we would complete the process by the end of the summer/early fall. Let's get the Diameter documents out! From owner-aaa-wg@merit.edu Fri Jul 13 18:29:12 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21394 for ; Fri, 13 Jul 2001 18:29:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DC9DD912D5; Fri, 13 Jul 2001 18:28:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC6CE912D6; Fri, 13 Jul 2001 18:28:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 79ADD912D5 for ; Fri, 13 Jul 2001 18:28:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 796C85DD9F; Fri, 13 Jul 2001 18:30:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 12BB05DD93 for ; Fri, 13 Jul 2001 18:30:28 -0400 (EDT) Received: (qmail 13007 invoked by uid 500); 13 Jul 2001 22:18:26 -0000 Date: Fri, 13 Jul 2001 15:18:26 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 28: Watchdog Timer issue with no Max-Wait-Time Message-ID: <20010713151826.W32517@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Paul has identified a problem that exists with the current watchdog algorithm since the Max-Wait-Time AVP has been removed. Please consider the following proposed text. I will re-open Issue 28. We have two options: 1. Leave the text as is, and let implementors deal with how to resolve this problem (it is not an interoperability issue, but more how to protect oneself against bad behavior), or 2. Accept the text I would like to hear what the WG feels, PatC ---- --=====================_133428019==_.ALT Content-Type: text/plain; charset="us-ascii" At 08:15 AM 6/28/01 -0700, Pat Calhoun wrote: >> 11. Issue 28 - Re-open Max-Wait-Time? >When a response is received for requests, this is not an issue. >Right now, how long a server wants to wait for a response is an >implementation issue. Measures need to be taken against servers >that do not respond. Paul will propose text to the list. >Watchdogs will be removed from the state machine, and the >definition would be expanded. A new section will discuss how >to deal with requests that have been in the list for too long. I'm not proposing that we reinstitute Max-Wait-Time. However, the absence of Max-Wait-Time does not alleviate the need to discard requests that are taking too long to complete. The client and each proxy must keep transaction state for each request. In theory, every request will be responded to, but for a variety of reasons it's possible that a request can get lost -- resource failures, malfunctions, etc. So every client and proxy needs to protect itself from slowly accumulating obsolete transaction state. My suggestion is simply that a client or proxy that has not received a response to a request within an appropriate (i.e., configurable) period of time simply discard it. If an answer comes in later, there is no transaction state so the answer will be ignored. I think a simple statement to this effect in the draft is all that's necessary. The other related issue is how to handle watchdogs. The approach proposed by Randy at the interim meeting relied on an answer (possibly a timeout error) always being returned at least by the next-hop proxy at the conclusion of Max-Wait- Time. That approach no longer works. So here's my homework assignment - a new watchdog algorithm. I have to say that I'm not pleased with how it came out; it is certainly more complex than I'd like. Can we discuss this on Thursday? An alternative to specifying this algorithm in detail would be to simply state that a peer MAY issue DWR to confirm the status of a connection, at whatever frequency it chooses. ----- Watchdog Algorithm The algorithm that follows uses the following variables: STATUS represents the level of confidence in the connection. It may take on one of the following values: OKAY indicates the connection is presumed working WAIT_DWA indicates that a DWR has been sent but a DWA has not yet been received SUSPECT indicates the connection is possibly congested or down PENDING is a flag that is true when there are no outstanding unanswered requests. T is the watchdog timer, measured in seconds. Every second, T is decremented. When it reaches 0, the OnTimerElapsed event (see below) is invoked. The algorithm uses the following time constants, which have default values but may be configured differently in an implementation: Ti, the idle time, represents the number of seconds that must elapse when there is no activity, before a DWR is sent. The default value of Ti is 30 seconds. Tr, the request pending time, represents the number of seconds that must elapse when there are requests pending but no messages have been received, before a DWR is sent. Tr should be less than Ti. The default value of Tr is 10 seconds. Tw, the watchdog pending time, represents the number of seconds that must elapse after a DWR is sent but no DWA has been received, before the STATUS of the connection is set to SUSPECT. The default value of Tw is 5 seconds. Tc, the close timer, the number of seconds that must elapse when the STATUS is SUSPECT and no DWA has been received, before the connection is stopped. The default value of Tc is 5 seconds. The algorithm processes the following events: OnSendRequest is processed whenever a request is sent on the connection. OnReceiveNonDWA is processed whenever a message other than DWA is received on the connection. This message may be a request or an answer. OnReceiveDWA is processed whenever a DWA is received. OnTimerElapsed is processed whenever timer T reaches 0. Pseudo-code for the algorithm is as follows: OnSendRequest if status = okay AND T > Tr T = Tr OnReceiveNonDWA if status = okay if pending T = Tr else T = Ti OnReceiveDWA if status = wait_DWA OR status = suspect if pending T = Tr else T = Ti OnTimerElapsed if status = okay SendWatchdog status = wait_DWA else if status = wait_DWA status = suspect T = Tc else if status = suspect Stop Connection Paul Funk Funk Software, Inc. 617 497-6339 paul@funk.com From owner-aaa-wg@merit.edu Fri Jul 13 18:31:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21675 for ; Fri, 13 Jul 2001 18:31:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9A79912D6; Fri, 13 Jul 2001 18:30:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D337912D9; Fri, 13 Jul 2001 18:30:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 77407912D6 for ; Fri, 13 Jul 2001 18:30:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 880645DDF1; Fri, 13 Jul 2001 18:32:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 430645DDA6 for ; Fri, 13 Jul 2001 18:32:29 -0400 (EDT) Received: (qmail 13024 invoked by uid 500); 13 Jul 2001 22:20:28 -0000 Date: Fri, 13 Jul 2001 15:20:28 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 91: Last Call Message-ID: <20010713152028.X32517@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Unless I hear otherwise, I will fix this issue based on the latest discussions, which is to let the Home Agent generate the SPI for the MIP SAs. Thanks, PatC From owner-aaa-wg@merit.edu Fri Jul 13 19:47:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01099 for ; Fri, 13 Jul 2001 19:47:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FE70912D8; Fri, 13 Jul 2001 19:47:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F63F912D9; Fri, 13 Jul 2001 19:47:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E934E912D8 for ; Fri, 13 Jul 2001 19:47:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 246415DD9F; Fri, 13 Jul 2001 19:49:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 563425DD93 for ; Fri, 13 Jul 2001 19:49:11 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6DNlpi27986 for ; Fri, 13 Jul 2001 18:48:04 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 13 Jul 2001 18:47:50 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: Diameter Mobile IPv6 Application Date: Fri, 13 Jul 2001 18:47:45 -0500 Message-ID: <7B5C0390ACE7D211BC9C0008C7EABA2B041F88AE@daeis07nok> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: Issue 91: Last Call X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEL6606PYimsXfdEdWBSQBQi2X+DwACaHLw From: To: Cc: , , <'charliep@iprg.nokia.com'> Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01099 Hello, A new draft titled Diameter Mobile IPv6 Application has been submitted today. The draft specifies a new Application to Diameter for Mobile IPv6, allowing an IPv6 mobile node to receive service from foreign service providers thanks to the support of inter domain roaming by the AAA infrastructure. The draft describes a solution that allows the Diameter infrastructure to authenticate and authorize an IPv6 mobile node, distribute security keys to enable the provisioning of services to the IPv6 mobile node, and perform and optimize mobility procedures for the IPv6 mobile node. The draft defines also enhanced features that allow for the development of new business models for service providers. Thank you, Franck From owner-aaa-wg@merit.edu Fri Jul 13 20:03:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03020 for ; Fri, 13 Jul 2001 20:03:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64BF3912D9; Fri, 13 Jul 2001 20:03:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2E1BE912DA; Fri, 13 Jul 2001 20:03:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07E27912D9 for ; Fri, 13 Jul 2001 20:03:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39BBA5DD9F; Fri, 13 Jul 2001 20:05:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id BD6CF5DD93 for ; Fri, 13 Jul 2001 20:05:17 -0400 (EDT) Received: (qmail 15494 invoked by uid 500); 13 Jul 2001 23:53:15 -0000 Date: Fri, 13 Jul 2001 16:53:15 -0700 From: Pat Calhoun To: Franck.Le@nokia.com Cc: aaa-wg@merit.edu, stefano.faccin@nokia.com, Basavaraj.Patil@nokia.com, 'charliep@iprg.nokia.com' Subject: Re: [AAA-WG]: Diameter Mobile IPv6 Application Message-ID: <20010713165315.Z32517@charizard.diameter.org> Mail-Followup-To: Franck.Le@nokia.com, aaa-wg@merit.edu, stefano.faccin@nokia.com, Basavaraj.Patil@nokia.com, 'charliep@iprg.nokia.com' References: <7B5C0390ACE7D211BC9C0008C7EABA2B041F88AE@daeis07nok> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <7B5C0390ACE7D211BC9C0008C7EABA2B041F88AE@daeis07nok>; from Franck.Le@nokia.com on Fri, Jul 13, 2001 at 06:47:45PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Out of curiosity, is the draft available somewhere so that I may read it before the secretariat gets through their enormous backlog? Thanks, PatC On Fri, Jul 13, 2001 at 06:47:45PM -0500, Franck.Le@nokia.com wrote: > Hello, > > A new draft titled Diameter Mobile IPv6 Application has been submitted > today. The draft specifies a new Application to Diameter for Mobile > IPv6, allowing an IPv6 mobile node to receive service from foreign > service providers thanks to the support of inter domain roaming by the > AAA infrastructure. The draft describes a solution that allows the > Diameter infrastructure to authenticate and authorize an IPv6 mobile > node, distribute security keys to enable the provisioning of services to > the IPv6 mobile node, and perform and optimize mobility procedures for > the IPv6 mobile node. The draft defines also enhanced features that > allow for the development of new business models for service providers. > > Thank you, > > Franck From owner-aaa-wg@merit.edu Sat Jul 14 18:14:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12084 for ; Sat, 14 Jul 2001 18:14:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AA509120D; Sat, 14 Jul 2001 18:13:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DAAEC9120E; Sat, 14 Jul 2001 18:13:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B9909120D for ; Sat, 14 Jul 2001 18:13:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 870665DDB3; Sat, 14 Jul 2001 18:15:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id C716C5DDA3 for ; Sat, 14 Jul 2001 18:15:32 -0400 (EDT) Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [135.214.42.163]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id PAA02469; Sat, 14 Jul 2001 15:09:29 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id PAA27383; Sat, 14 Jul 2001 15:09:29 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id PAA10151; Sat, 14 Jul 2001 15:09:27 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Sat, 14 Jul 2001 18:09:20 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508693E@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Randy Bush'" , Bernard Aboba Cc: aaa-wg@merit.edu, Bob Engelhart , Chuck Adams , "Daly, Brian" , ileana.leuca@attws.com, John Molchan , Luisa Marchetto Subject: RE: [AAA-WG]: Call for agenda items Date: Sat, 14 Jul 2001 18:09:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, Please include a tentative agenda item entitled "Diameter as a 3G charging protocol". This is tentative because a review of the Diameter RFC is still pending. If nothing interesting evolves from the review, I will not have anything to say. Thad -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: Thursday, July 12, 2001 7:45 PM To: Bernard Aboba Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Call for agenda items > This is a call for agenda items for IETF 51. If you have an agenda item, > send it to myself or Dave Mitton (david@mitton.com). mine would be: o review of open issues with diameter drafts o summarize all open issues o plan for closing issues o schedule to get this sucker out the door! randy From owner-aaa-wg@merit.edu Mon Jul 16 20:08:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12162 for ; Mon, 16 Jul 2001 20:08:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A6A891226; Mon, 16 Jul 2001 20:08:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0E70C91232; Mon, 16 Jul 2001 20:08:28 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3F1D91226 for ; Mon, 16 Jul 2001 20:08:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D44CF5DDD7; Mon, 16 Jul 2001 20:10:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 50B0D5DDC9 for ; Mon, 16 Jul 2001 20:10:08 -0400 (EDT) Received: (qmail 24495 invoked by uid 500); 16 Jul 2001 23:58:10 -0000 Date: Mon, 16 Jul 2001 16:58:10 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 91: MIP SPIs Message-ID: <20010716165810.U1139@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I'm in the process of addressing Issue 91. The new draft will let the HA create the SPIs, and in the process of making the changes, I've come across an additional necessary change. Currently, when the AAAH creates the keys for the mobile node, it creates the MIP generalized key extension. However, all keys destined for the FA and HA are sent as a Grouped AVP. It doesn't make sense to keep this model, since the SPI would be left null. Therefore, the keys destined for the mobile node will be changed to the Grouped AVP, and text will be added that states that the Home Agent is responsible for creating the Generalized key extension. PatC From owner-aaa-wg@merit.edu Tue Jul 17 09:39:04 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05708 for ; Tue, 17 Jul 2001 09:38:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19C1F91205; Tue, 17 Jul 2001 09:38:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDDB791206; Tue, 17 Jul 2001 09:38:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ACFC491205 for ; Tue, 17 Jul 2001 09:38:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B5F7C5DDDE; Tue, 17 Jul 2001 09:40:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 310BE5DDCE for ; Tue, 17 Jul 2001 09:40:32 -0400 (EDT) Received: (qmail 354 invoked by uid 500); 17 Jul 2001 13:28:31 -0000 Date: Tue, 17 Jul 2001 06:28:31 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Proposed Text for Issue 91 Message-ID: <20010717062831.Q1139@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Below is my proposed text for this issue. I'd *really* like some comments on this ASAP, as my deadline to get the drafts out is tomorrow. The changes aren't that major, and include: 1. Changing the Mobile keys to be Grouped AVPs 3. Added text in sub-sections 5.x to state that the mobile proposes its keys in the MIP AAA keys subtypes, and the HA uses these SPIs in the creation of the MIP AAA key reply extensions. 4. Added text in 5.x stating that the HA is responsible for creating the SPI used in the FA-HA key 5. Added two new AVPs, that the HA includes in the HAA. These AVPs contain the SPIs that the FA will use with the MN and the HA. These SPIs are used by the AAAH to create the grouped key AVPs that are sent to the foreign in the AMA. btw, I am not using my normal nroff environment, so the formatting MAY be a tad off. I will be out of contact today between 9 and 5 pacific, and will respond to comments upon my return. Comments most appreciated, PatC ---- 5.0 Key Distribution Center The mobile node and mobility agents use registration keys to compute authentication extensions applied to registration messages, as defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If registration keys are requested the AAA server(s) MUST create them after the Mobile Node is successfully authenticated and authorized. If the AAAH does not communicate directly with the foreign agent, and it does not wish for intermediate proxies to have access to the session keys, they SHOULD be protected using the CMS security application [9]. The Authorization-Lifetime AVP contains the number of seconds before registration keys destined for the Home Agent and/or Foreign Agent expire. A value of zero indicates infinity (no timeout). AAA support for key distribution departs slightly from the existing SPI usage, as described in [4]. The SPI values are used as key identifiers, meaning that each registration key has its own SPI value; nodes that share a key also share an SPI. The Mobile Node proposes SPIs for use in computing the Mobile-Foreign and Mobile-Home authentication extensions, via the Mobile IP AAA Key Request extensions [15], while the Home Agent allocates the Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. Once the registration keys have been distributed, subsequent Mobile IP registrations need not invoke the AAA infrastructure until the keys expire. These registrations MUST include the Mobile-Home authentication extension. In addition, subsequent registrations MUST also include Mobile-Foreign authentication extension if the Mobile- Foreign key was generated and distributed by AAA; similarly for subsequent use of the Foreign-Home authentication extensions. Each registration key that is generated by AAA will generally be distributed to two parties; for instance, a Mobile-Foreign key goes to both a mobile node and a foreign agent. The methods by which the key is encoded will depend upon the security associations available to the AAA server and each recipient of the key. These methods will often be different for the two recipients, so that the registration Calhoun, Perkins expires December 2001 [Page 26] Internet-Draft June 2001 key under consideration has to be encoded twice. See sections 6.0 for details about the format of the AVPs used to transport the registration keys. 5.1 Distributing the Mobile-Home Registration Key If the mobile node does not have a Mobile-Home registration key, then the AAAH is likely to be the only entity trusted that is available to the mobile node. Thus, the AAAH has to generate the Mobile-Home registration key, and encode it for eventual consumption by the mobile node and home agent. If the home agent is in the home domain, then AAAH can directly encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and include that AVP in the HAR message for delivery to the home agent. If, on the other hand, the home agent is to be allocated in the visited domain, the AAAH does not transmit the HAR to the home agent, but instead transmits the HAR to the AAAF. When the AAAF receives the HAR, it first allocates a home agent, and then issues the HAR for that home agent. The AAAH also has to arrange for the key to be delivered to the mobile node. Unfortunately, the AAA server only knows about Diameter messages and AVPs, and the mobile node only knows about Mobile IP messages and extensions [4]. For this purpose, AAAH encodes the Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its security association with the mobile node, which is added to the HAR message, and delivered either to a local home agent, or to the AAAF in the case where the home agent is in the visited network. The AAAH has to rely on the home agent (that also understands Diameter) to transfer the keying information into a Mobile IP Generalized MN-HA Key Reply extension [15] in the Registration Reply message, using the SPI proposed by the Mobile Node in the MN-HA Key Request From AAA Subtype extension. The home agent can format the Reply message and extensions correctly for eventual delivery to the mobile node. The resulting Registration Reply is added to the HAA's MIP-Reg-Reply AVP. After the HAA message is parsed by the AAAH, and transformed into an AMA, the AMA message containing the MIP-Reg-Reply AVP will eventually be received by the the foreign agent. The foreign agent can then use that AVP to recreate a Registration Reply message, containing the Generalized MN-HA Key Reply extension, for delivery to the mobile node. Calhoun, Perkins expires December 2001 [Page 27] Internet-Draft June 2001 In summary, the AAAH generates the Mobile-Home registration key and encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. These AVPs are delivered to a home agent by including them in a HAR message sent from either AAAH or AAAF. The home agent decodes the key for its own use. The home agent also copies the encoded registration key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply extension appended to the Mobile IP Registration Reply message. This Registration Reply message MUST also include the Mobile-Home authentication extension, created using the newly allocated Mobile- Home registration key. The home agent then encodes the Registration Reply message and extensions into a MIP-Reg-Reply AVP included as part of the HAA message to be sent back to the AAA server. 5.2 Distributing the Mobile-Foreign Registration Key The Mobile-Foreign registration key is also generated by AAAH (upon request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, which is added to the HAR, and copied by the home agent into a Generalized MN-FA Key Reply Extension [15] to the Mobile IP Registration Reply message, using the SPI proposed by the Mobile Node in the MN-FA Key Request From AAA Subtype extension. Further, the home agent includes the SPI in the HAA's MIP-FA-to-MN-SPI AVP. Most of the considerations for distributing the Mobile-Foreign registration key are similar to the distribution of the Mobile-Home Registration Key. Upon receipt of the HAA, if MN-FA keying was requested the AAAH creates the MIP-FA-to-MN-Key AVP, using the SPI in the MIP-FA-to-MN- SPI, and includes the AVP in the AMA. If the MIP-FA-to-MN-Key AVP was present in the AMA, the foreign agent MUST include the Mobile-Foreign authentication extension in the Registration Reply, using the newly distributed key. 5.3 Distributing the Foreign-Home Registration Key If the home agent is in the home domain, then AAAH has to generate the Foreign-Home registration key. Otherwise, it is generated by AAAF. In either case, the AAA server encodes the registration key into a MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message sent to the home agent, and waits for the HAA message to be returned. Upon receipt of the HAR, the home agent recovers the Foreign-Home registration key, allocates an SPI to be used with the key, and uses this key to create a Foreign-Home authentication extension to the Calhoun, Perkins expires December 2001 [Page 28] Internet-Draft June 2001 Registration Reply message. The allocated SPI is included in the HAA's MIP-FA-to-HA SPI AVP. Upon receipt of the HAA, the Diameter server responsible for key allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP- FA-to-HA-SPI, and includes the AVP in the AMA. 5.4 Key Distribution Example Figure 9 provides an example of subsequent Mobile IP message exchange, assuming that AAAH distributed registration keys for all three MN-FA, FA-HA and HA-MN authentication extensions. Mobile Node Foreign Agent Home Agent ----------- ------------- ---------- Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) Figure 9: Mobile IP Message Exchange 6.0 Key Distribution Center (KDC) AVPs The Mobile-IP protocol defines a set of security associations shared between the Mobile Node, Foreign Agent and Home Agents. These three security associations (Mobile-Home, Mobile-Foreign, and Foreign- Home), can be dynamically created by the AAAH. This requires that the AAAH create Mobile-IP Registration Keys, and that these keys be distributed to the three mobile entities, via the Diameter Protocol. AAA servers supporting the Diameter Mobile IP Application MUST implement the KDC AVPs defined in this document. In other words, AAA servers MUST be able to create three registration keys: the Mobile- Home, Mobile-Foreign, and Foreign-Home keys. The names of the KDC AVPs indicate the two entities sharing the security association defined by the encrypted key material; the intended receiver of the AVP is the first named entity. So, for instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key encrypted in a way that allows it to be recovered by the mobile node. If strong authentication and confidentiality of the registration keys Calhoun, Perkins expires December 2001 [Page 29] Internet-Draft June 2001 is required, it is recommended that the CMS security application [9] be used. The following table describes the Diameter AVPs defined in the Mobile IP application, their AVP Code values, types, possible flag values and whether the AVP MAY be encrypted. +---------------------+ | AVP Flag rules | |----+-----+----+-----|----+ AVP Section | | |SHLD| MUST|MAY | Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| -----------------------------------------|----+-----+----+-----|----| MIP-Algorithm- 345 6.9 Enumerated | M | P | | V | Y | Type | | | | | | MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | | V | Y | MIP-FA-to-HA-SPI 318 6.12 Unsigned32 | M | P | | V | Y | MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | | V | Y | MIP-FA-to-MN-SPI 319 6.11 Unsigned32 | M | P | | V | Y | MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | | V | Y | MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | | V | Y | MIP-MN-to-FA-Key 325 6.5 OctetString| M | P | | V | Y | MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | | V | Y | MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | | V | Y | MIP-Replay-Mode 346 6.10 Enumerated | M | P | | V | Y | MIP-Session-Key 343 6.8 OctetString| M | P | | V | Y | 6.1 MIP-FA-to-MN-Key AVP The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and contains the Foreign Agent's session key, which it shares with the Mobile Node. Its Data field has the following ABNF grammar: MIP-FA-to-MN-Key ::= < AVP Header: 326 > { MIP-Peer-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 6.2 MIP-FA-to-HA-Key AVP The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and contains the Foreign Agent's session key, which it shares with the Home Agent. Its Data field has the following ABNF grammar: MIP-FA-to-HA-Key ::= < AVP Header: 328 > Calhoun, Perkins expires December 2001 [Page 30] Internet-Draft June 2001 { MIP-Peer-SPI } { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP ] 6.3 MIP-HA-to-FA-Key AVP The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and contains the Home Agent's session key, which it shares with the Foreign Agent. Its Data field has the following ABNF grammar: MIP-HA-to-FA-Key ::= < AVP Header: 329 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] 6.4 MIP-HA-to-MN-Key AVP The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and contains the Home Agent's session key, which it shares with the Mobile Node. Its Data field has the following ABNF grammar: MIP-HA-to-MN-Key ::= < AVP Header: 332 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] 6.5 MIP-MN-to-FA-Key AVP The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and contains the Mobile Node's session key, which it shares with the Foreign Agent. The Home Agent uses this AVP in the construction of the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" extension [15]. The SPI in the extension's FA SPI field is allocated by the Home Agent, but it SHOULD take into consideration the SPI requested by the Mobile Node in the "MN-FA Key Request From AAA Subtype" extension. MIP-MN-to-FA-Key ::= < AVP Header: 325 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] Calhoun, Perkins expires December 2001 [Page 31] Internet-Draft June 2001 6.6 MIP-MN-to-HA-Key AVP The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and contains the Mobile Node's session key, which it shares with the Home Agent. The Home Agent uses this AVP in the construction of the Mobile IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. The SPI in the extension's HA SPI field is allocated by the Home Agent, but it SHOULD take into consideration the SPI requested by the Mobile Node in the "MN-HA Key Request From AAA Subtype" extension. MIP-MN-to-FA-Key ::= < AVP Header: 331 > { MIP-Algorithm-Type } { MIP-Replay-Mode } { MIP-Session-Key } * [ AVP ] 6.7 MIP-Peer-SPI AVP The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and contains the Security Parameter Index to use to reference the key in the associated MIP-Session-Key AVP. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. 6.8 MIP-Session-Key AVP The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and contains the Session Key to be used between two Mobile IP entities. 6.9 MIP-Algorithm-Type AVP The MIP-Algorithm-Type AVP (AVP Code 345) is of type Enumerated, and contains the Algorithm identifier used to generate the associated Mobile IP authentication extension. The following values are currently defined: 1 Prefix+Suffix MD5 [4] 2 HMAC-MD5 [13] 3 SHA-1 [17] 6.10 MIP-Replay-Mode AVP The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and contains the replay mode the Home Agent should use when Calhoun, Perkins expires December 2001 [Page 32] Internet-Draft June 2001 authenticating the Mobile Node. The following values are supported (see [4] for more information): 0 None 1 Timestamps 2 Nonces 6.11 MIP-FA-to-MN-SPI AVP The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and contains the Security Parameter Index the Foreign Agent is to use to refer to the session key it shares with the Mobile Node. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. This AVP MAY be added in the HAA message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of the MIP-FA-to-MN-Key AVP. 6.12 MIP-FA-to-HA-SPI AVP The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and contains the Security Parameter Index the Foreign Agent is to use to refer to the session key it shares with the Home Agent. The SPI created MUST NOT be a value between zero (0) and 255, which is the reserved namespace defined in [4]. This AVP MAY be added in the HAA message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of the MIP-FA-to-HA-Key AVP. From owner-aaa-wg@merit.edu Wed Jul 18 05:44:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10630 for ; Wed, 18 Jul 2001 05:44:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D7579124F; Wed, 18 Jul 2001 05:44:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 32FE691250; Wed, 18 Jul 2001 05:44:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 16B059124F for ; Wed, 18 Jul 2001 05:44:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B19CF5DD99; Wed, 18 Jul 2001 05:46:38 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3EF085DD96 for ; Wed, 18 Jul 2001 05:46:37 -0400 (EDT) Received: from linux (a20.local.ipunplugged.com [192.168.4.190]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id LAA28952 for ; Wed, 18 Jul 2001 11:47:11 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Martin Andersson To: aaa-wg@merit.edu Subject: [AAA-WG]: Ip addresses and ip names.. Date: Wed, 18 Jul 2001 11:45:39 +0200 X-Mailer: KMail [version 1.2] MIME-Version: 1.0 Message-Id: <01071811453901.00728@linux> Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Could anyone explain to me what happens if a node does not have a DNS resolvable address? Is that supposed to be looked at as a misconfiguration? I can see that for example OriginHost or uri:s could be handled with just the ip address, but how should for example OriginRealm be handled if we don't have defined ip masks? There is no way as I see it to get the realm from an address without the mask... Is there something that I miss here? /Martin From owner-aaa-wg@merit.edu Wed Jul 18 07:35:22 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03169 for ; Wed, 18 Jul 2001 07:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5113991251; Wed, 18 Jul 2001 07:35:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 24EF591252; Wed, 18 Jul 2001 07:35:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12AB691251 for ; Wed, 18 Jul 2001 07:35:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D6C8D5DD98; Wed, 18 Jul 2001 07:36:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 5169D5DD96 for ; Wed, 18 Jul 2001 07:36:46 -0400 (EDT) Received: (qmail 11889 invoked by uid 500); 18 Jul 2001 11:24:41 -0000 Date: Wed, 18 Jul 2001 04:24:41 -0700 From: Pat Calhoun To: Martin Andersson Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Ip addresses and ip names.. Message-ID: <20010718042441.J1139@charizard.diameter.org> Mail-Followup-To: Martin Andersson , aaa-wg@merit.edu References: <01071811453901.00728@linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <01071811453901.00728@linux>; from martin.andersson@ipunplugged.com on Wed, Jul 18, 2001 at 11:45:39AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 18, 2001 at 11:45:39AM +0200, Martin Andersson wrote: > > > Could anyone explain to me what happens if a node does not have a DNS > resolvable address? Is that supposed to be looked at as a misconfiguration? > I can see that for example OriginHost or uri:s could be handled with just the > ip address, but how should for example OriginRealm be handled if we don't > have defined ip masks? There is no way as I see it to get the realm from an > address without the mask... You have a couple of options. In today's RADIUS networks, this information is largely statically configured, and I suspect that there'll be plenty of static config in Diameter networks as well. However, the WG decided to do better than RADIUS and allow for dynamic configuration, which is what you are referring to. So, static configuration is your friend in this instance, PatC From owner-aaa-wg@merit.edu Wed Jul 18 15:58:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19131 for ; Wed, 18 Jul 2001 15:58:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E5A91260; Wed, 18 Jul 2001 15:58:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CC1991262; Wed, 18 Jul 2001 15:58:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4874891260 for ; Wed, 18 Jul 2001 15:58:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78C6F5DD9F; Wed, 18 Jul 2001 16:00:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9DE105DD98 for ; Wed, 18 Jul 2001 16:00:01 -0400 (EDT) Received: (qmail 14136 invoked by uid 500); 18 Jul 2001 19:47:55 -0000 Date: Wed, 18 Jul 2001 12:47:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Cc: randy@psg.com Subject: [AAA-WG]: Issues list hits zero (and ID annoucement) Message-ID: <20010718124755.Z1139@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu, randy@psg.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, As some of you that may have been watching the list of issues dwindle down, we've officially reached zero today. I am sending all of the new versions of the drafts to the secretariat, and making the drafts available for preview on www.diameter.org. As Bernard mentioned earlier this week, now that we've reached zero, the latest set of drafts will cause the WG Last Call to be issued once they are available on the IETF archives. Thanks again to everyone that helped get the protocol to where it is today, PatC From owner-aaa-wg@merit.edu Thu Jul 19 11:58:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00605 for ; Thu, 19 Jul 2001 11:58:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CBFC991277; Thu, 19 Jul 2001 11:58:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E4B391279; Thu, 19 Jul 2001 11:58:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F5EF91277 for ; Thu, 19 Jul 2001 11:58:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2F3095DD8F; Thu, 19 Jul 2001 12:00:28 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id A490D5DD8C for ; Thu, 19 Jul 2001 12:00:27 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JFxtI19253 for ; Thu, 19 Jul 2001 10:59:56 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 10:59:08 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 10:59:07 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 10:59:07 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81106AD7F@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Thread-Index: AcEQay+fVWBDr3wfEdWaKAAAhlNL6Q== From: To: , X-OriginalArrivalTime: 19 Jul 2001 15:59:07.0960 (UTC) FILETIME=[BE13D380:01C1106B] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA00605 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Diameter Mobile IPv6 Application Author(s) : S. Faccin et al. Filename : draft-le-aaa-diameter-mobileipv6-00.txt Pages : Date : 18-Jul-01 This document specifies a new Application to Diameter for Mobile IPv6, allowing an IPv6 mobile node to receive service from foreign service providers thanks to the support of inter domain roaming by the AAA infrastructure. The draft describes a solution that allows the Diameter infrastructure to authenticate and authorize an IPv6 mobile node, distribute security keys to enable the provisioning of services to the IPv6 mobile node, and perform and optimize mobility procedures for the IPv6 mobile node. A URL for this Internet-Draft is: 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-le-aaa-diameter-mobileipv6-00.txt". A list of Internet-Drafts directories can be found in or Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-aaa-wg@merit.edu Thu Jul 19 12:05:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02019 for ; Thu, 19 Jul 2001 12:05:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03C689127C; Thu, 19 Jul 2001 12:05:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6F439127F; Thu, 19 Jul 2001 12:05:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 005F89127C for ; Thu, 19 Jul 2001 12:05:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 127885DD90; Thu, 19 Jul 2001 12:06:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 560CE5DD8C for ; Thu, 19 Jul 2001 12:06:49 -0400 (EDT) Received: (qmail 31830 invoked by uid 500); 19 Jul 2001 15:54:37 -0000 Date: Thu, 19 Jul 2001 08:54:35 -0700 From: Pat Calhoun To: Franck.Le@nokia.com Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Message-ID: <20010719085433.B30610@charizard.diameter.org> Mail-Followup-To: Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <57A26D272F67A743952F6B4371B8F81106AD7F@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <57A26D272F67A743952F6B4371B8F81106AD7F@daebe007.NOE.Nokia.com>; from Franck.Le@nokia.com on Thu, Jul 19, 2001 at 10:59:07AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Very cool! I do, however, wonder where this work belongs. Should it be in AAA WG, or in Mobile IP? Once we are done with the set of specs in AAA, we will only have the API and the MIB left, so I believe they would have bandwidth. My preference is in AAA WG, but requiring some coordination with MIP. PatC On Thu, Jul 19, 2001 at 10:59:07AM -0500, Franck.Le@nokia.com wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Diameter Mobile IPv6 Application > Author(s) : S. Faccin et al. > Filename : draft-le-aaa-diameter-mobileipv6-00.txt > Pages : > Date : 18-Jul-01 > > This document specifies a new Application to Diameter for Mobile > IPv6, allowing an IPv6 mobile node to receive service from foreign > service providers thanks to the support of inter domain roaming by > the AAA infrastructure. The draft describes a solution that allows > the Diameter infrastructure to authenticate and authorize an IPv6 > mobile node, distribute security keys to enable the provisioning of > services to the IPv6 mobile node, and perform and optimize mobility > procedures for the IPv6 mobile node. > > A URL for this Internet-Draft is: > .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-le-aaa-diameter-mobileipv6-00.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > From owner-aaa-wg@merit.edu Thu Jul 19 12:46:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09293 for ; Thu, 19 Jul 2001 12:46:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 47ECB9127E; Thu, 19 Jul 2001 12:46:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19A669127F; Thu, 19 Jul 2001 12:46:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEA949127E for ; Thu, 19 Jul 2001 12:46:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D85145DD8C; Thu, 19 Jul 2001 12:48:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 58E375DDB6 for ; Thu, 19 Jul 2001 12:48:31 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JGlEi03927 for ; Thu, 19 Jul 2001 11:47:14 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 11:47:08 -0500 Received: from daebe005.NOE.Nokia.com ([172.18.242.203]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 11:47:07 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 11:47:07 -0500 Message-ID: <82ECD4351A4A9547957C606034A3CB8D0A17D8@daebe005.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQbMe2JTBD53xeEdWJUgAIx6TWpQABOwtQ From: To: , Cc: , X-OriginalArrivalTime: 19 Jul 2001 16:47:07.0869 (UTC) FILETIME=[72A310D0:01C11072] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA09293 Pat, I agree with you. I'd prefer to see this work done in AAA WG, but definitely MIP WG needs to provide inputs and we need to make sure there is coordination. Taz -----Original Message----- From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] Sent: Thursday, July 19, 2001 10:55 AM To: Le Franck (NRC/Dallas) Cc: aaa-wg@merit.edu; mobile-ip@sunroof.eng.sun.com Subject: Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Very cool! I do, however, wonder where this work belongs. Should it be in AAA WG, or in Mobile IP? Once we are done with the set of specs in AAA, we will only have the API and the MIB left, so I believe they would have bandwidth. My preference is in AAA WG, but requiring some coordination with MIP. PatC On Thu, Jul 19, 2001 at 10:59:07AM -0500, Franck.Le@nokia.com wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Diameter Mobile IPv6 Application > Author(s) : S. Faccin et al. > Filename : draft-le-aaa-diameter-mobileipv6-00.txt > Pages : > Date : 18-Jul-01 > > This document specifies a new Application to Diameter for Mobile > IPv6, allowing an IPv6 mobile node to receive service from foreign > service providers thanks to the support of inter domain roaming by > the AAA infrastructure. The draft describes a solution that allows > the Diameter infrastructure to authenticate and authorize an IPv6 > mobile node, distribute security keys to enable the provisioning of > services to the IPv6 mobile node, and perform and optimize mobility > procedures for the IPv6 mobile node. > > A URL for this Internet-Draft is: > .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-le-aaa-diameter-mobileipv6-00.txt". > > A list of Internet-Drafts directories can be found in > > or > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > From owner-aaa-wg@merit.edu Thu Jul 19 13:08:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12658 for ; Thu, 19 Jul 2001 13:08:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24F0491280; Thu, 19 Jul 2001 13:08:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EAC1391281; Thu, 19 Jul 2001 13:08:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C45C091280 for ; Thu, 19 Jul 2001 13:08:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 08C7A5DDA0; Thu, 19 Jul 2001 13:09:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 78C2F5DD8C for ; Thu, 19 Jul 2001 13:09:56 -0400 (EDT) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6JH8hi06698 for ; Thu, 19 Jul 2001 12:08:43 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Thu, 19 Jul 2001 12:08:27 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 19 Jul 2001 12:08:26 -0500 content-class: urn:content-classes:message Subject: RE: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Date: Thu, 19 Jul 2001 12:08:26 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF4408606E@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Index: AcEQbMe2JTBD53xeEdWJUgAIx6TWpQACHSOg From: To: , Cc: , X-OriginalArrivalTime: 19 Jul 2001 17:08:26.0878 (UTC) FILETIME=[6CFC59E0:01C11075] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA12658 > > Very cool! > > I do, however, wonder where this work belongs. Should it be in AAA WG, > or in Mobile IP? Once we are done with the set of specs in AAA, we > will only have the API and the MIB left, so I believe they would have > bandwidth. > > My preference is in AAA WG, but requiring some coordination with MIP. The work needs to be done in the AAA WG. And yes it will require coordination between the two WGs. I completely agree with your view Pat. -Basavaraj From owner-aaa-wg@merit.edu Thu Jul 19 13:14:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13562 for ; Thu, 19 Jul 2001 13:14:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EBAF191281; Thu, 19 Jul 2001 13:14:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B72DF91282; Thu, 19 Jul 2001 13:14:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A72DC91281 for ; Thu, 19 Jul 2001 13:14:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D80BD5DD90; Thu, 19 Jul 2001 13:16:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 9012C5DD8C for ; Thu, 19 Jul 2001 13:16:42 -0400 (EDT) Received: (qmail 1230 invoked by uid 500); 19 Jul 2001 17:04:30 -0000 Date: Thu, 19 Jul 2001 10:04:29 -0700 From: Pat Calhoun To: Basavaraj.Patil@nokia.com Cc: pcalhoun@diameter.org, Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, aboba@internaut.com, david@mitton.com Subject: Re: [AAA-WG]: FW: I-D ACTION:draft-le-aaa-diameter-mobileipv6-00.txt Message-ID: <20010719100429.D30610@charizard.diameter.org> Mail-Followup-To: Basavaraj.Patil@nokia.com, pcalhoun@diameter.org, Franck.Le@nokia.com, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, aboba@internaut.com, david@mitton.com References: <697DAA22C5004B4596E033803A7CEF4408606E@daebe007.NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <697DAA22C5004B4596E033803A7CEF4408606E@daebe007.NOE.Nokia.com>; from Basavaraj.Patil@nokia.com on Thu, Jul 19, 2001 at 12:08:26PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 19, 2001 at 12:08:26PM -0500, Basavaraj.Patil@nokia.com wrote: > > > > Very cool! > > > > I do, however, wonder where this work belongs. Should it be in AAA WG, > > or in Mobile IP? Once we are done with the set of specs in AAA, we > > will only have the API and the MIB left, so I believe they would have > > bandwidth. > > > > My preference is in AAA WG, but requiring some coordination with MIP. > > The work needs to be done in the AAA WG. And yes it will require > coordination > between the two WGs. I completely agree with your view Pat. Bernard & Dave, Since there seems to be some consensus, we need to raise this issue in the AAA WG meeting, and see whether the document can be added to the milestones. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jul 19 14:02:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26986 for ; Thu, 19 Jul 2001 14:02:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07A4B9120C; Thu, 19 Jul 2001 14:02:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D29809126F; Thu, 19 Jul 2001 14:02:35 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C85C9120C for ; Thu, 19 Jul 2001 14:02:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE0905DD90; Thu, 19 Jul 2001 14:04:20 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by segue.merit.edu (Postfix) with ESMTP id 945295DD8F for ; Thu, 19 Jul 2001 14:04:20 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id 63DDC142E; Thu, 19 Jul 2001 11:03:05 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA10942; Thu, 19 Jul 2001 11:04:53 -0700 (PDT) Date: Thu, 19 Jul 2001 11:04:53 -0700 (PDT) From: Joe Lau Message-Id: <200107191804.LAA10942@strtio1.cup.hp.com> To: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Cc: jlau@cup.hp.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, I have a question on your recent proposed text for Issue 91 (KDC) > Below is my proposed text for this issue. > ... > > 6.1 MIP-FA-to-MN-Key AVP > > ... > > MIP-FA-to-MN-Key ::== > { MIP-Peer-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP] > > 6.5 MIP-MN-to-FA-Key AVp > > ... > > MIP-MN-to-FA-Key ::== > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP] How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no MIP-Replay-Mode AVP? Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". Thanks for the clarification. Joe From owner-aaa-wg@merit.edu Thu Jul 19 14:04:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27523 for ; Thu, 19 Jul 2001 14:04:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43F969126F; Thu, 19 Jul 2001 14:04:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F9B691282; Thu, 19 Jul 2001 14:04:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED85E9126F for ; Thu, 19 Jul 2001 14:04:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E9E15DD90; Thu, 19 Jul 2001 14:06:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DAC045DD8F for ; Thu, 19 Jul 2001 14:06:07 -0400 (EDT) Received: (qmail 3308 invoked by uid 500); 19 Jul 2001 17:53:53 -0000 Date: Thu, 19 Jul 2001 10:53:53 -0700 From: Pat Calhoun To: Joe Lau Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org Subject: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010719105352.F30610@charizard.diameter.org> Mail-Followup-To: Joe Lau , aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com, pcalhoun@diameter.org References: <200107191804.LAA10942@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107191804.LAA10942@strtio1.cup.hp.com>; from jlau@cup.hp.com on Thu, Jul 19, 2001 at 11:04:53AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 19, 2001 at 11:04:53AM -0700, Joe Lau wrote: > Pat, > > I have a question on your recent proposed text for Issue 91 (KDC) > > > Below is my proposed text for this issue. > > ... > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > ... > > > > MIP-FA-to-MN-Key ::== > > { MIP-Peer-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP] > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > ... > > > > MIP-MN-to-FA-Key ::== > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP] > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > MIP-Replay-Mode AVP? > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". RFC 2002 provides MN-HA replay protection only, via either timestamps or nonces. The protocol doesn't provide such replay protection between MN-FA and FA-HA. The Challenge extension provides the MN-FA replay protection, but that is well before the registration request has even been sent, so sending this info in AAA is pointless. PatC > > Thanks for the clarification. > > Joe > From owner-aaa-wg@merit.edu Thu Jul 19 14:25:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04467 for ; Thu, 19 Jul 2001 14:25:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9969E91286; Thu, 19 Jul 2001 14:22:19 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 563BC91296; Thu, 19 Jul 2001 14:22:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2C3CF91286 for ; Thu, 19 Jul 2001 14:20:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7912F5DDA9; Thu, 19 Jul 2001 14:22:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by segue.merit.edu (Postfix) with ESMTP id 501795DDA5 for ; Thu, 19 Jul 2001 14:22:11 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel1.hp.com (Postfix) with ESMTP id 24CA51BA2; Thu, 19 Jul 2001 11:20:56 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id LAA11087; Thu, 19 Jul 2001 11:22:44 -0700 (PDT) Date: Thu, 19 Jul 2001 11:22:44 -0700 (PDT) From: Joe Lau Message-Id: <200107191822.LAA11087@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Cc: aaa-wg@merit.edu, jlau@cup.hp.com, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, > RFC 2002 provides MN-HA replay protection only, via either timestamps > or nonces. The protocol doesn't provide such replay protection > between MN-FA and FA-HA. But then why MIP-MN-to-FA-Key had a MIP-Replay-Mode AVP? Similar problem on MIP-HA-to-FA-Key AVP. > > > MIP-MN-to-FA-Key ::== > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } <=========== Here > > > { MIP-Session-Key } > > > * [ AVP] I am still puzzled. Thanks in advance for the clarification again. Joe ---------------------- Origial email ------------------------ > > I have a question on your recent proposed text for Issue 91 (KDC) > > > > > Below is my proposed text for this issue. > > > ... > > > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > > > ... > > > > > > MIP-FA-to-MN-Key ::== > > > { MIP-Peer-SPI } > > > { MIP-Algorithm-Type } > > > { MIP-Session-Key } > > > * [ AVP] > > > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > > > ... > > > > > > MIP-MN-to-FA-Key ::== > > > { MIP-Algorithm-Type } > > > { MIP-Replay-Mode } > > > { MIP-Session-Key } > > > * [ AVP] > > > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > > MIP-Replay-Mode AVP? > > > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". > > RFC 2002 provides MN-HA replay protection only, via either timestamps > or nonces. The protocol doesn't provide such replay protection > between MN-FA and FA-HA. The Challenge extension provides the MN-FA > replay protection, but that is well before the registration request > has even been sent, so sending this info in AAA is pointless. > > PatC > > > > Thanks for the clarification. > > > > Joe > > > From owner-aaa-wg@merit.edu Thu Jul 19 14:40:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08310 for ; Thu, 19 Jul 2001 14:40:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF1F491283; Thu, 19 Jul 2001 14:40:22 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 92CE691284; Thu, 19 Jul 2001 14:40:22 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 86D4191283 for ; Thu, 19 Jul 2001 14:40:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DAE595DDA9; Thu, 19 Jul 2001 14:42:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 4E4355DDA5 for ; Thu, 19 Jul 2001 14:42:07 -0400 (EDT) Received: (qmail 5183 invoked by uid 500); 19 Jul 2001 18:29:55 -0000 Date: Thu, 19 Jul 2001 11:29:54 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010719112953.G30610@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <200107191822.LAA11087@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107191822.LAA11087@strtio1.cup.hp.com>; from jlau@cup.hp.com on Thu, Jul 19, 2001 at 11:22:44AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk An oversight. This will have to be taken care of during the last call phase. Thanks, PatC On Thu, Jul 19, 2001 at 11:22:44AM -0700, Joe Lau wrote: > Pat, > > > RFC 2002 provides MN-HA replay protection only, via either timestamps > > or nonces. The protocol doesn't provide such replay protection > > between MN-FA and FA-HA. > > > But then why MIP-MN-to-FA-Key had a MIP-Replay-Mode AVP? > Similar problem on MIP-HA-to-FA-Key AVP. > > > > > MIP-MN-to-FA-Key ::== > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } <=========== Here > > > > { MIP-Session-Key } > > > > * [ AVP] > > I am still puzzled. > Thanks in advance for the clarification again. > > Joe > > ---------------------- Origial email ------------------------ > > > > I have a question on your recent proposed text for Issue 91 (KDC) > > > > > > > Below is my proposed text for this issue. > > > > ... > > > > > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > > > > > ... > > > > > > > > MIP-FA-to-MN-Key ::== > > > > { MIP-Peer-SPI } > > > > { MIP-Algorithm-Type } > > > > { MIP-Session-Key } > > > > * [ AVP] > > > > > > > > 6.5 MIP-MN-to-FA-Key AVp > > > > > > > > ... > > > > > > > > MIP-MN-to-FA-Key ::== > > > > { MIP-Algorithm-Type } > > > > { MIP-Replay-Mode } > > > > { MIP-Session-Key } > > > > * [ AVP] > > > > > > How come MIP-FA-to-MN-Key, unlike MIP-MN-to-FA-Key, has no > > > MIP-Replay-Mode AVP? > > > > > > Similar problem for the "6.2 MIP-FA-to-HA-Key AVP". > > > > RFC 2002 provides MN-HA replay protection only, via either timestamps > > or nonces. The protocol doesn't provide such replay protection > > between MN-FA and FA-HA. The Challenge extension provides the MN-FA > > replay protection, but that is well before the registration request > > has even been sent, so sending this info in AAA is pointless. > > > > PatC > > > > > > Thanks for the clarification. > > > > > > Joe > > > > > From owner-aaa-wg@merit.edu Fri Jul 20 10:53:20 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25899 for ; Fri, 20 Jul 2001 10:53:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A57C912CB; Fri, 20 Jul 2001 10:53:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 25B3E912CC; Fri, 20 Jul 2001 10:53:16 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3619912CB for ; Fri, 20 Jul 2001 10:53:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CA88E5DDB5; Fri, 20 Jul 2001 10:55:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by segue.merit.edu (Postfix) with ESMTP id 7F1025DDB2 for ; Fri, 20 Jul 2001 10:55:02 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) id 15Nbf0-0005WI-00; Fri, 20 Jul 2001 16:53:46 +0200 Received: from ee.tu-berlin.de (root@ftmail.ee.tu-berlin.de [130.149.49.250]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6KErjh26070; Fri, 20 Jul 2001 16:53:45 +0200 Message-ID: <3B584644.3D7264A3@ee.tu-berlin.de> Date: Fri, 20 Jul 2001 16:55:00 +0200 From: Guenter Schaefer X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Proposed Text for Issue 91 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I have just subscribed to the list today, as I stumbled over some unclear points related to the session key distribution issue in the internet draft "Diameter Mobile IPv4 Application". This also relates to the proposed Text for Issue 91. To explain my questions, let's consider that, - Point A: Two or more mobile nodes from the same organization (home domain) want to register at the same foreign agent and all session keys should be generated by the home AAA server. It is not unlikely, that they want to register at the same HA. - Point B: Later on, one of them makes a handover to another foreign agent, served by the same foreign AAA server, so that an optimized re-registration should take place (the mobile node includes the previous foreign agent address and wants to re-use the same session keys). Regarding Point A, I have the impression that with the current internet drafts two HA-FA keys, one for each mobile node will be created and distributed. If the lifetime of these key would not play a role, one key could be sufficient. However, if the FA-HA security association should have a limited lifetime, then in fact two keys may be required, as for example the two registrations do not need to occur at the same moment of time, and the SA needs to be valid also during the entire lifetime of the SA HA-MN2 (considering MN2 is the second one to register). My first question related to this is, how does the current approach to choosing the SPI guarantee the required uniqueness of the SPI at both peers (FA and HA)? In IPSec an SPI always belongs to a unidirectional security association and it needs to be unique for the receiver side. So the receiving side determines the SPI and a security association is uniquely identified by the pair . The approach in the current internet draft seems to be a different one: > AAA support for key distribution departs slightly from the existing > SPI usage, as described in [4]. The SPI values are used as key > identifiers, meaning that each registration key has its own SPI > value; nodes that share a key also share an SPI. The Mobile Node > proposes SPIs for use in computing the Mobile-Foreign and > Mobile-Home authentication extensions, via the Mobile IP AAA Key > Request extensions [15], while the Home Agent allocates the > Mobile-Foreign, Mobile-Home and Foreign-Home SPIs. > > Once the registration keys have been distributed, subsequent Mobile > IP registrations need not invoke the AAA infrastructure until the > keys expire. These registrations MUST include the Mobile-Home > authentication extension. In addition, subsequent registrations > MUST also include Mobile-Foreign authentication extension if the > Mobile-Foreign key was generated and distributed by AAA; > similarly for subsequent use of the Foreign-Home authentication > extensions. This model just works if an SA is identified by a triple and for every key there are two entries in the SA databases at both sides: - - If an SA should be identified by only , the above approach will not work, as the home agent does not have complete knowledge of the SPIs in use at the foreign agent. However, the use of the triple raises another issue which occurs in the situation described as Point B (optimized local handover): - The new foreign agent needs an FA-HA key to HA of the MN performing the handover. For this he could either: - Alternative B.1: use an FA-HA key he already has established with the MN's home agent (following the idea "one key per pair of entities"). However, this introduces a problem with the lifetime of the FAnew-HA key as it should be valid at least as long as the MN-HA key. - Alternative B.2: try to use the same FA-HA key the old foreign agent has used for this mobile node (following the idea "one FA-HA key per MN-session"). This key could be provided by the foreign AAA server, which also has to provide the MN-FA key of the old foreign agent. - If alternative B.2 is to be realized, this creates a problem with the SPI: how will the home agent associate the key FAold-HA with the new foreign agent? One solution could be that the old-foreign-agent-extension is carried over to the HA and that HA modifies the entries to But what happens, if there exists already another key with the same SPI between the two enitities FAnew and HA? Do you think it is desiable to add some clarification about this issue of "uniquely identifying SAs and handing them over from one foreign agent to another" to the internet draft? All suggestions are welcome, with best regards, Guenter Schaefer ------------------------------------------------------------------------ Guenter Schaefer, Institute of Telecommunication Systems, Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Fri Jul 20 14:32:33 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23329 for ; Fri, 20 Jul 2001 14:32:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 79CAC91216; Fri, 20 Jul 2001 14:32:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7BA5491217; Fri, 20 Jul 2001 14:32:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7A62991216 for ; Fri, 20 Jul 2001 14:32:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D7F95DDA9; Fri, 20 Jul 2001 14:34:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 5D0B35DD91 for ; Fri, 20 Jul 2001 14:34:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6KIWM516804; Fri, 20 Jul 2001 13:32:23 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6KIWMj18611; Fri, 20 Jul 2001 13:32:22 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA08938; Fri, 20 Jul 2001 13:32:21 -0500 (CDT) Received: from ericsson.com (busam54.berkeley.us.am.ericsson.se [138.85.159.204]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA19860; Fri, 20 Jul 2001 13:32:19 -0500 (CDT) Message-ID: <3B5877E0.48F67CD7@ericsson.com> Date: Fri, 20 Jul 2001 11:26:40 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Cc: diameter@diameter.org, kevin.purser@ericsson.com Subject: [AAA-WG]: Diameter interop testing event (bake off) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, Here is the official invitation to the next Diameter interoperability testing event (bake off). * Location: Ericsson Research, 2100 Shattuck Ave, Berkeley, California. * Date: The first week of October (10/1/01-10/5/01). * No Fee, but the registration is binding. Please find all additional information and how to register at the link below. http://standards.ericsson.net/diameter-bake-off /Tony From owner-aaa-wg@merit.edu Mon Jul 23 16:17:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21062 for ; Mon, 23 Jul 2001 16:17:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 416FB9124A; Mon, 23 Jul 2001 16:17:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCF7B91248; Mon, 23 Jul 2001 16:17:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 84D0591247 for ; Mon, 23 Jul 2001 16:17:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 45C155DDCB; Mon, 23 Jul 2001 16:19:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by segue.merit.edu (Postfix) with ESMTP id 1EF645DDC9 for ; Mon, 23 Jul 2001 16:19:00 -0400 (EDT) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel2.hp.com (Postfix) with ESMTP id E5B0F117D; Mon, 23 Jul 2001 13:17:39 -0700 (PDT) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id NAA16669; Mon, 23 Jul 2001 13:19:27 -0700 (PDT) Date: Mon, 23 Jul 2001 13:19:27 -0700 (PDT) From: Joe Lau Message-Id: <200107232019.NAA16669@strtio1.cup.hp.com> To: pcalhoun@diameter.org Subject: Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Cc: aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, With MIP-MN-to-HA-Key defined as a grouped AVP instead of the previous Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype, MIP-MN-to-FA-Key ::== { MIP-Algorithm-Type } { MIP-Session-Key } * [ AVP] how can the HA figure out the "AAA SPI" field in order to create the Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype in the Registration Reply to the MN. Also, am I right that AAA SPI refers to algorithm like CHAP-SPI? What are the other possible algorithms? Thank you for the clarification and info. Joe From owner-aaa-wg@merit.edu Mon Jul 23 18:12:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27535 for ; Mon, 23 Jul 2001 18:12:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A28959124E; Mon, 23 Jul 2001 18:12:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 705C59124F; Mon, 23 Jul 2001 18:12:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4FDA89124E for ; Mon, 23 Jul 2001 18:12:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C13D5DDCD; Mon, 23 Jul 2001 18:14:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 33F645DDC9 for ; Mon, 23 Jul 2001 18:14:04 -0400 (EDT) Received: (qmail 20011 invoked by uid 500); 23 Jul 2001 22:01:49 -0000 Date: Mon, 23 Jul 2001 15:01:49 -0700 From: Pat Calhoun To: Joe Lau Cc: pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com Subject: Re: [AAA-WG]: Re: Proposed Text for Issue 91 (KDC) Message-ID: <20010723150149.W10225@charizard.diameter.org> Mail-Followup-To: Joe Lau , pcalhoun@diameter.org, aaa-wg@merit.edu, mobile-ip@sunroof.eng.sun.com References: <200107232019.NAA16669@strtio1.cup.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200107232019.NAA16669@strtio1.cup.hp.com>; from jlau@cup.hp.com on Mon, Jul 23, 2001 at 01:19:27PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Mon, Jul 23, 2001 at 01:19:27PM -0700, Joe Lau wrote: > Hi Pat, > > With MIP-MN-to-HA-Key defined as a grouped AVP instead of the previous > Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype, > > MIP-MN-to-FA-Key ::== > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP] > > how can the HA figure out the "AAA SPI" field in order to create the > Generalized Key Reply Extension with Unsolicited MN-FA Key Material subtype > in the Registration Reply to the MN. Ah, I see the problem. Yes, this Grouped AVP does need to include the AAA SPI, which the HA includes in the MIP key extension. Another issue that needs to be resolved as part of last call comments. Thanks, PatC > Also, am I right that AAA SPI refers to algorithm like CHAP-SPI? What > are the other possible algorithms? No, the SPI refers to an encryption transform. Similar to MIP autentication extensions, both sides have an SPI that points to the auth transform used in the authenticator computation, the AAA SPI will point to the transform used to encrypt/decrypt the session keys. Hope this helps, PatC From owner-aaa-wg@merit.edu Tue Jul 24 04:14:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03643 for ; Tue, 24 Jul 2001 04:14:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AF5F29125D; Tue, 24 Jul 2001 04:14:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 64C5D9125E; Tue, 24 Jul 2001 04:14:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3A2779125D for ; Tue, 24 Jul 2001 04:14:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3F6F95DDCE; Tue, 24 Jul 2001 04:16:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 4681F5DD9D for ; Tue, 24 Jul 2001 04:16:16 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6O8EsO28443 for ; Tue, 24 Jul 2001 10:14:54 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Jul 24 10:14:53 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 10:14:53 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , aaa-wg@merit.edu Cc: "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Proposed Text for Issue 91 Date: Tue, 24 Jul 2001 10:10:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, Thanks for the text, it is what I was expecting. However, a few things to change. 1- The MIP-Replay-Mode AVP should NOT be part of the MIP-HA-to-FA-Key AVP. 2- The MIP-Replay-Mode AVP should NOT be part of the MIP-MN-to-FA-Key AVP. 3- The MIP-Peer-SPI AVP should be included in the MIP-MN-to-FA-Key AVP. 4- The MIP-MN-to-FA-Key and the MIP-MN-to-HA-Key AVPs should rather include the MIP-Session-Key-Material AVP instead of the MIP-Session-Key AVP, right? At least, according to the aaa-key-07 draft, it would make more sense. Also, they should include the AAA-SPI. That also means that for all the other "key" AVPs, the real MIP-Session-Key is intended to be placed in the AVP directly. So, for example, I should be expecting the MIP-Session-Key in the MIP-HA-to-FA-Key and the MIP-FA-to-HA-Key AVPs to be the same, right? 5- In 6.10, could you change the number so that they match with the aaa-key-07 draft, if you don't mind, i.e. from 1 to 3? Regards, Martin > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Tuesday, July 17, 2001 3:29 PM > To: aaa-wg@merit.edu > Subject: [AAA-WG]: Proposed Text for Issue 91 > > > All, > > Below is my proposed text for this issue. I'd *really* like some > comments on this ASAP, as my deadline to get the drafts out is > tomorrow. The changes aren't that major, and include: > > 1. Changing the Mobile keys to be Grouped AVPs > 3. Added text in sub-sections 5.x to state that the mobile proposes > its keys in the MIP AAA keys subtypes, and the HA uses these SPIs > in the creation of the MIP AAA key reply extensions. > 4. Added text in 5.x stating that the HA is responsible for creating > the SPI used in the FA-HA key > 5. Added two new AVPs, that the HA includes in the HAA. These AVPs > contain the SPIs that the FA will use with the MN and the HA. These > SPIs are used by the AAAH to create the grouped key AVPs that are > sent to the foreign in the AMA. > > btw, I am not using my normal nroff environment, so the formatting MAY > be a tad off. I will be out of contact today between 9 and 5 > pacific, and > will respond to comments upon my return. > > Comments most appreciated, > > PatC > ---- > > > 5.0 Key Distribution Center > > The mobile node and mobility agents use registration keys > to compute > authentication extensions applied to registration messages, as > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > registration keys are requested the AAA server(s) MUST create them > after the Mobile Node is successfully authenticated and authorized. > > If the AAAH does not communicate directly with the foreign > agent, and > it does not wish for intermediate proxies to have access to the > session keys, they SHOULD be protected using the CMS security > application [9]. > > The Authorization-Lifetime AVP contains the number of > seconds before > registration keys destined for the Home Agent and/or Foreign Agent > expire. A value of zero indicates infinity (no timeout). > > AAA support for key distribution departs slightly from the existing > SPI usage, as described in [4]. The SPI values are used as key > identifiers, meaning that each registration key has its own SPI > value; nodes that share a key also share an SPI. The Mobile Node > proposes SPIs for use in computing the Mobile-Foreign and > Mobile-Home > authentication extensions, via the Mobile IP AAA Key Request > extensions [15], while the Home Agent allocates the Mobile-Foreign, > Mobile-Home and Foreign-Home SPIs. > > Once the registration keys have been distributed, subsequent Mobile > IP registrations need not invoke the AAA infrastructure until the > keys expire. These registrations MUST include the Mobile-Home > authentication extension. In addition, subsequent > registrations MUST > also include Mobile-Foreign authentication extension if the Mobile- > Foreign key was generated and distributed by AAA; similarly for > subsequent use of the Foreign-Home authentication extensions. > > Each registration key that is generated by AAA will generally be > distributed to two parties; for instance, a Mobile-Foreign key goes > to both a mobile node and a foreign agent. The methods by > which the > key is encoded will depend upon the security associations available > to the AAA server and each recipient of the key. These > methods will > often be different for the two recipients, so that the registration > > > > Calhoun, Perkins expires December 2001 > [Page 26] > > > > > > Internet-Draft > June 2001 > > > key under consideration has to be encoded twice. > > See sections 6.0 for details about the format of the AVPs used to > transport the registration keys. > > > 5.1 Distributing the Mobile-Home Registration Key > > If the mobile node does not have a Mobile-Home > registration key, then > the AAAH is likely to be the only entity trusted that is > available to > the mobile node. Thus, the AAAH has to generate the Mobile-Home > registration key, and encode it for eventual consumption by the > mobile node and home agent. > > If the home agent is in the home domain, then AAAH can directly > encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP > and include that AVP in the HAR message for delivery to the home > agent. > > If, on the other hand, the home agent is to be allocated in the > visited domain, the AAAH does not transmit the HAR to the > home agent, > but instead transmits the HAR to the AAAF. When the AAAF > receives the > HAR, it first allocates a home agent, and then issues the HAR for > that home agent. > > The AAAH also has to arrange for the key to be delivered to the > mobile node. Unfortunately, the AAA server only knows > about Diameter > messages and AVPs, and the mobile node only knows about Mobile IP > messages and extensions [4]. For this purpose, AAAH encodes the > Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its > security association with the mobile node, which is added > to the HAR > message, and delivered either to a local home agent, or to the AAAF > in the case where the home agent is in the visited > network. The AAAH > has to rely on the home agent (that also understands Diameter) to > transfer the keying information into a Mobile IP Generalized MN-HA > Key Reply extension [15] in the Registration Reply > message, using the > SPI proposed by the Mobile Node in the MN-HA Key Request From AAA > Subtype extension. The home agent can format the Reply message and > extensions correctly for eventual delivery to the mobile node. The > resulting Registration Reply is added to the HAA's > MIP-Reg-Reply AVP. > > After the HAA message is parsed by the AAAH, and > transformed into an > AMA, the AMA message containing the MIP-Reg-Reply AVP will > eventually > be received by the the foreign agent. The foreign agent > can then use > that AVP to recreate a Registration Reply message, containing the > Generalized MN-HA Key Reply extension, for delivery to the mobile > node. > > > > > Calhoun, Perkins expires December 2001 > [Page 27] > > > > > > Internet-Draft > June 2001 > > > In summary, the AAAH generates the Mobile-Home registration key and > encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. > These AVPs are delivered to a home agent by including them in a HAR > message sent from either AAAH or AAAF. The home agent > decodes the key > for its own use. The home agent also copies the encoded > registration > key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA > Key Reply > extension appended to the Mobile IP Registration Reply > message. This > Registration Reply message MUST also include the Mobile-Home > authentication extension, created using the newly allocated Mobile- > Home registration key. The home agent then encodes the Registration > Reply message and extensions into a MIP-Reg-Reply AVP included as > part of the HAA message to be sent back to the AAA server. > > > 5.2 Distributing the Mobile-Foreign Registration Key > > The Mobile-Foreign registration key is also generated by AAAH (upon > request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, > which is added to the HAR, and copied by the home agent into a > Generalized MN-FA Key Reply Extension [15] to the Mobile IP > Registration Reply message, using the SPI proposed by the > Mobile Node > in the MN-FA Key Request From AAA Subtype extension. Further, the > home agent includes the SPI in the HAA's MIP-FA-to-MN-SPI AVP. Most > of the considerations for distributing the Mobile-Foreign > registration key are similar to the distribution of the Mobile-Home > Registration Key. > > Upon receipt of the HAA, if MN-FA keying was requested the AAAH > creates the MIP-FA-to-MN-Key AVP, using the SPI in the > MIP-FA-to-MN- > SPI, and includes the AVP in the AMA. If the > MIP-FA-to-MN-Key AVP was > present in the AMA, the foreign agent MUST include the > Mobile-Foreign > authentication extension in the Registration Reply, using the newly > distributed key. > > > 5.3 Distributing the Foreign-Home Registration Key > > If the home agent is in the home domain, then AAAH has to generate > the Foreign-Home registration key. Otherwise, it is generated by > AAAF. > > In either case, the AAA server encodes the registration key into a > MIP-HA-to-FA-Key AVP and includes that AVP as part of the > HAR message > sent to the home agent, and waits for the HAA message to > be returned. > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > registration key, allocates an SPI to be used with the > key, and uses > this key to create a Foreign-Home authentication extension to the > > > > Calhoun, Perkins expires December 2001 > [Page 28] > > > > > > Internet-Draft > June 2001 > > > Registration Reply message. The allocated SPI is included in the > HAA's MIP-FA-to-HA SPI AVP. > > Upon receipt of the HAA, the Diameter server responsible for key > allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP- > FA-to-HA-SPI, and includes the AVP in the AMA. > > > 5.4 Key Distribution Example > > Figure 9 provides an example of subsequent Mobile IP message > exchange, assuming that AAAH distributed registration keys for all > three MN-FA, FA-HA and HA-MN authentication extensions. > > Mobile Node Foreign Agent Home Agent > ----------- ------------- ---------- > > Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> > > Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> > > <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) > > <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) > > Figure 9: Mobile IP Message Exchange > > > 6.0 Key Distribution Center (KDC) AVPs > > The Mobile-IP protocol defines a set of security > associations shared > between the Mobile Node, Foreign Agent and Home Agents. These three > security associations (Mobile-Home, Mobile-Foreign, and Foreign- > Home), can be dynamically created by the AAAH. This > requires that the > AAAH create Mobile-IP Registration Keys, and that these keys be > distributed to the three mobile entities, via the Diameter > Protocol. > AAA servers supporting the Diameter Mobile IP Application MUST > implement the KDC AVPs defined in this document. In other > words, AAA > servers MUST be able to create three registration keys: the Mobile- > Home, Mobile-Foreign, and Foreign-Home keys. > > The names of the KDC AVPs indicate the two entities sharing the > security association defined by the encrypted key material; the > intended receiver of the AVP is the first named entity. So, for > instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key > encrypted in a way that allows it to be recovered by the > mobile node. > > If strong authentication and confidentiality of the > registration keys > > > > Calhoun, Perkins expires December 2001 > [Page 29] > > > > > > Internet-Draft > June 2001 > > > is required, it is recommended that the CMS security > application [9] > be used. > > The following table describes the Diameter AVPs defined in > the Mobile > IP application, their AVP Code values, types, possible flag values > and whether the AVP MAY be encrypted. > > +---------------------+ > | AVP Flag rules | > > |----+-----+----+-----|----+ > AVP Section | | > |SHLD| MUST|MAY | > Attribute Name Code Defined Value Type |MUST| MAY | > NOT| NOT|Encr| > > -----------------------------------------|----+-----+----+-----|----| > MIP-Algorithm- 345 6.9 Enumerated | M | P | > | V | Y | > Type | | | > | | | > MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | > | V | Y | > MIP-FA-to-HA-SPI 318 6.12 Unsigned32 | M | P | > | V | Y | > MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | > | V | Y | > MIP-FA-to-MN-SPI 319 6.11 Unsigned32 | M | P | > | V | Y | > MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | > | V | Y | > MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | > | V | Y | > MIP-MN-to-FA-Key 325 6.5 OctetString| M | P | > | V | Y | > MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | > | V | Y | > MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | > | V | Y | > MIP-Replay-Mode 346 6.10 Enumerated | M | P | > | V | Y | > MIP-Session-Key 343 6.8 OctetString| M | P | > | V | Y | > > > 6.1 MIP-FA-to-MN-Key AVP > > The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and > contains the Foreign Agent's session key, which it shares with the > Mobile Node. Its Data field has the following ABNF grammar: > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > { MIP-Peer-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > > 6.2 MIP-FA-to-HA-Key AVP > > The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and > contains the Foreign Agent's session key, which it shares with the > Home Agent. Its Data field has the following ABNF grammar: > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > > Calhoun, Perkins expires December 2001 > [Page 30] > > > > > > Internet-Draft > June 2001 > > > { MIP-Peer-SPI } > { MIP-Algorithm-Type } > { MIP-Session-Key } > * [ AVP ] > > > 6.3 MIP-HA-to-FA-Key AVP > > The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and > contains the Home Agent's session key, which it shares with the > Foreign Agent. Its Data field has the following ABNF grammar: > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > > 6.4 MIP-HA-to-MN-Key AVP > > The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and > contains the Home Agent's session key, which it shares with the > Mobile Node. Its Data field has the following ABNF grammar: > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > > 6.5 MIP-MN-to-FA-Key AVP > > The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and > contains the Mobile Node's session key, which it shares with the > Foreign Agent. The Home Agent uses this AVP in the construction of > the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" > extension [15]. > The SPI in the extension's FA SPI field is allocated by the Home > Agent, but it SHOULD take into consideration the SPI > requested by the > Mobile Node in the "MN-FA Key Request From AAA Subtype" extension. > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > > > > Calhoun, Perkins expires December 2001 > [Page 31] > > > > > > Internet-Draft > June 2001 > > > 6.6 MIP-MN-to-HA-Key AVP > > The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and > contains the Mobile Node's session key, which it shares > with the Home > Agent. The Home Agent uses this AVP in the construction of > the Mobile > IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. > The SPI in > the extension's HA SPI field is allocated by the Home Agent, but it > SHOULD take into consideration the SPI requested by the Mobile Node > in the "MN-HA Key Request From AAA Subtype" extension. > > MIP-MN-to-FA-Key ::= < AVP Header: 331 > > { MIP-Algorithm-Type } > { MIP-Replay-Mode } > { MIP-Session-Key } > * [ AVP ] > > > 6.7 MIP-Peer-SPI AVP > > The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and > contains the Security Parameter Index to use to reference > the key in > the associated MIP-Session-Key AVP. The SPI created MUST NOT be a > value between zero (0) and 255, which is the reserved namespace > defined in [4]. > > > 6.8 MIP-Session-Key AVP > > The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and > contains the Session Key to be used between two Mobile IP entities. > > > 6.9 MIP-Algorithm-Type AVP > > The MIP-Algorithm-Type AVP (AVP Code 345) is of type > Enumerated, and > contains the Algorithm identifier used to generate the associated > Mobile IP authentication extension. The following values are > currently defined: > > 1 Prefix+Suffix MD5 [4] > 2 HMAC-MD5 [13] > 3 SHA-1 [17] > > > 6.10 MIP-Replay-Mode AVP > > The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and > contains the replay mode the Home Agent should use when > > > > Calhoun, Perkins expires December 2001 > [Page 32] > > > > > > Internet-Draft > June 2001 > > > authenticating the Mobile Node. > > The following values are supported (see [4] for more information): > > 0 None > 1 Timestamps > 2 Nonces > > > 6.11 MIP-FA-to-MN-SPI AVP > > The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and > contains the Security Parameter Index the Foreign Agent is > to use to > refer to the session key it shares with the Mobile Node. The SPI > created MUST NOT be a value between zero (0) and 255, which is the > reserved namespace defined in [4]. This AVP MAY be added in the HAA > message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of > the MIP-FA-to-MN-Key AVP. > > > 6.12 MIP-FA-to-HA-SPI AVP > > The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and > contains the Security Parameter Index the Foreign Agent is > to use to > refer to the session key it shares with the Home Agent. The SPI > created MUST NOT be a value between zero (0) and 255, which is the > reserved namespace defined in [4]. This AVP MAY be added in the HAA > message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of > the MIP-FA-to-HA-Key AVP. > From owner-aaa-wg@merit.edu Tue Jul 24 08:54:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14647 for ; Tue, 24 Jul 2001 08:54:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3AD239126A; Tue, 24 Jul 2001 08:54:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 04AFD9126B; Tue, 24 Jul 2001 08:54:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D628E9126A for ; Tue, 24 Jul 2001 08:54:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 419F25DDDB; Tue, 24 Jul 2001 08:56:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 924455DD9F for ; Tue, 24 Jul 2001 08:56:43 -0400 (EDT) Received: (qmail 25555 invoked by uid 500); 24 Jul 2001 12:44:26 -0000 Date: Tue, 24 Jul 2001 05:44:26 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Text for Issue 91 Message-ID: <20010724054426.F10225@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Tue, Jul 24, 2001 at 10:10:00AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk I agree with all your comments, and thanks for the summary. It makes it easier when I need to make the change :) PatC On Tue, Jul 24, 2001 at 10:10:00AM +0200, Martin Julien (ECE) wrote: > Hi Pat, > > Thanks for the text, it is what I was expecting. > However, a few things to change. > > 1- The MIP-Replay-Mode AVP should NOT be part of the MIP-HA-to-FA-Key AVP. > > 2- The MIP-Replay-Mode AVP should NOT be part of the MIP-MN-to-FA-Key AVP. > > 3- The MIP-Peer-SPI AVP should be included in the MIP-MN-to-FA-Key AVP. > > 4- The MIP-MN-to-FA-Key and the MIP-MN-to-HA-Key AVPs should rather include > the MIP-Session-Key-Material AVP instead of the MIP-Session-Key AVP, right? > At least, according to the aaa-key-07 draft, it would make more sense. > Also, they should include the AAA-SPI. > > That also means that for all the other "key" AVPs, the real MIP-Session-Key > is intended to be placed in the AVP directly. So, for example, > I should be expecting the MIP-Session-Key in the MIP-HA-to-FA-Key > and the MIP-FA-to-HA-Key AVPs to be the same, right? > > 5- In 6.10, could you change the number so that they match with the > aaa-key-07 draft, if you don't mind, i.e. from 1 to 3? > > Regards, > Martin > > > > -----Original Message----- > > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Tuesday, July 17, 2001 3:29 PM > > To: aaa-wg@merit.edu > > Subject: [AAA-WG]: Proposed Text for Issue 91 > > > > > > All, > > > > Below is my proposed text for this issue. I'd *really* like some > > comments on this ASAP, as my deadline to get the drafts out is > > tomorrow. The changes aren't that major, and include: > > > > 1. Changing the Mobile keys to be Grouped AVPs > > 3. Added text in sub-sections 5.x to state that the mobile proposes > > its keys in the MIP AAA keys subtypes, and the HA uses these SPIs > > in the creation of the MIP AAA key reply extensions. > > 4. Added text in 5.x stating that the HA is responsible for creating > > the SPI used in the FA-HA key > > 5. Added two new AVPs, that the HA includes in the HAA. These AVPs > > contain the SPIs that the FA will use with the MN and the HA. These > > SPIs are used by the AAAH to create the grouped key AVPs that are > > sent to the foreign in the AMA. > > > > btw, I am not using my normal nroff environment, so the formatting MAY > > be a tad off. I will be out of contact today between 9 and 5 > > pacific, and > > will respond to comments upon my return. > > > > Comments most appreciated, > > > > PatC > > ---- > > > > > > 5.0 Key Distribution Center > > > > The mobile node and mobility agents use registration keys > > to compute > > authentication extensions applied to registration messages, as > > defined in [4]: Mobile-Foreign, Foreign-Home and Mobile-Home. If > > registration keys are requested the AAA server(s) MUST create them > > after the Mobile Node is successfully authenticated and authorized. > > > > If the AAAH does not communicate directly with the foreign > > agent, and > > it does not wish for intermediate proxies to have access to the > > session keys, they SHOULD be protected using the CMS security > > application [9]. > > > > The Authorization-Lifetime AVP contains the number of > > seconds before > > registration keys destined for the Home Agent and/or Foreign Agent > > expire. A value of zero indicates infinity (no timeout). > > > > AAA support for key distribution departs slightly from the existing > > SPI usage, as described in [4]. The SPI values are used as key > > identifiers, meaning that each registration key has its own SPI > > value; nodes that share a key also share an SPI. The Mobile Node > > proposes SPIs for use in computing the Mobile-Foreign and > > Mobile-Home > > authentication extensions, via the Mobile IP AAA Key Request > > extensions [15], while the Home Agent allocates the Mobile-Foreign, > > Mobile-Home and Foreign-Home SPIs. > > > > Once the registration keys have been distributed, subsequent Mobile > > IP registrations need not invoke the AAA infrastructure until the > > keys expire. These registrations MUST include the Mobile-Home > > authentication extension. In addition, subsequent > > registrations MUST > > also include Mobile-Foreign authentication extension if the Mobile- > > Foreign key was generated and distributed by AAA; similarly for > > subsequent use of the Foreign-Home authentication extensions. > > > > Each registration key that is generated by AAA will generally be > > distributed to two parties; for instance, a Mobile-Foreign key goes > > to both a mobile node and a foreign agent. The methods by > > which the > > key is encoded will depend upon the security associations available > > to the AAA server and each recipient of the key. These > > methods will > > often be different for the two recipients, so that the registration > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 26] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > key under consideration has to be encoded twice. > > > > See sections 6.0 for details about the format of the AVPs used to > > transport the registration keys. > > > > > > 5.1 Distributing the Mobile-Home Registration Key > > > > If the mobile node does not have a Mobile-Home > > registration key, then > > the AAAH is likely to be the only entity trusted that is > > available to > > the mobile node. Thus, the AAAH has to generate the Mobile-Home > > registration key, and encode it for eventual consumption by the > > mobile node and home agent. > > > > If the home agent is in the home domain, then AAAH can directly > > encode the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP > > and include that AVP in the HAR message for delivery to the home > > agent. > > > > If, on the other hand, the home agent is to be allocated in the > > visited domain, the AAAH does not transmit the HAR to the > > home agent, > > but instead transmits the HAR to the AAAF. When the AAAF > > receives the > > HAR, it first allocates a home agent, and then issues the HAR for > > that home agent. > > > > The AAAH also has to arrange for the key to be delivered to the > > mobile node. Unfortunately, the AAA server only knows > > about Diameter > > messages and AVPs, and the mobile node only knows about Mobile IP > > messages and extensions [4]. For this purpose, AAAH encodes the > > Mobile-Home registration key into a MIP-MN-to-HA-Key AVP, using its > > security association with the mobile node, which is added > > to the HAR > > message, and delivered either to a local home agent, or to the AAAF > > in the case where the home agent is in the visited > > network. The AAAH > > has to rely on the home agent (that also understands Diameter) to > > transfer the keying information into a Mobile IP Generalized MN-HA > > Key Reply extension [15] in the Registration Reply > > message, using the > > SPI proposed by the Mobile Node in the MN-HA Key Request From AAA > > Subtype extension. The home agent can format the Reply message and > > extensions correctly for eventual delivery to the mobile node. The > > resulting Registration Reply is added to the HAA's > > MIP-Reg-Reply AVP. > > > > After the HAA message is parsed by the AAAH, and > > transformed into an > > AMA, the AMA message containing the MIP-Reg-Reply AVP will > > eventually > > be received by the the foreign agent. The foreign agent > > can then use > > that AVP to recreate a Registration Reply message, containing the > > Generalized MN-HA Key Reply extension, for delivery to the mobile > > node. > > > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 27] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > In summary, the AAAH generates the Mobile-Home registration key and > > encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key AVP. > > These AVPs are delivered to a home agent by including them in a HAR > > message sent from either AAAH or AAAF. The home agent > > decodes the key > > for its own use. The home agent also copies the encoded > > registration > > key from the MIP-MN-to-HA-Key AVP into a Generalized MN-HA > > Key Reply > > extension appended to the Mobile IP Registration Reply > > message. This > > Registration Reply message MUST also include the Mobile-Home > > authentication extension, created using the newly allocated Mobile- > > Home registration key. The home agent then encodes the Registration > > Reply message and extensions into a MIP-Reg-Reply AVP included as > > part of the HAA message to be sent back to the AAA server. > > > > > > 5.2 Distributing the Mobile-Foreign Registration Key > > > > The Mobile-Foreign registration key is also generated by AAAH (upon > > request), so that it can be encoded into a MIP-MN-to-FA-Key AVP, > > which is added to the HAR, and copied by the home agent into a > > Generalized MN-FA Key Reply Extension [15] to the Mobile IP > > Registration Reply message, using the SPI proposed by the > > Mobile Node > > in the MN-FA Key Request From AAA Subtype extension. Further, the > > home agent includes the SPI in the HAA's MIP-FA-to-MN-SPI AVP. Most > > of the considerations for distributing the Mobile-Foreign > > registration key are similar to the distribution of the Mobile-Home > > Registration Key. > > > > Upon receipt of the HAA, if MN-FA keying was requested the AAAH > > creates the MIP-FA-to-MN-Key AVP, using the SPI in the > > MIP-FA-to-MN- > > SPI, and includes the AVP in the AMA. If the > > MIP-FA-to-MN-Key AVP was > > present in the AMA, the foreign agent MUST include the > > Mobile-Foreign > > authentication extension in the Registration Reply, using the newly > > distributed key. > > > > > > 5.3 Distributing the Foreign-Home Registration Key > > > > If the home agent is in the home domain, then AAAH has to generate > > the Foreign-Home registration key. Otherwise, it is generated by > > AAAF. > > > > In either case, the AAA server encodes the registration key into a > > MIP-HA-to-FA-Key AVP and includes that AVP as part of the > > HAR message > > sent to the home agent, and waits for the HAA message to > > be returned. > > > > Upon receipt of the HAR, the home agent recovers the Foreign-Home > > registration key, allocates an SPI to be used with the > > key, and uses > > this key to create a Foreign-Home authentication extension to the > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 28] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > Registration Reply message. The allocated SPI is included in the > > HAA's MIP-FA-to-HA SPI AVP. > > > > Upon receipt of the HAA, the Diameter server responsible for key > > allocation adds the MIP-FA-to-HA Key AVP, using the SPI in the MIP- > > FA-to-HA-SPI, and includes the AVP in the AMA. > > > > > > 5.4 Key Distribution Example > > > > Figure 9 provides an example of subsequent Mobile IP message > > exchange, assuming that AAAH distributed registration keys for all > > three MN-FA, FA-HA and HA-MN authentication extensions. > > > > Mobile Node Foreign Agent Home Agent > > ----------- ------------- ---------- > > > > Reg-Req(MN-HA-Auth, MN-FA-Auth)--------> > > > > Reg-Req(MN-HA-Auth, FA-HA-Auth)--------> > > > > <--------Reg-Rep(MN-HA-Auth, FA-HA-Auth) > > > > <--------Reg-Rep(MN-HA-Auth, MN-FA-Auth) > > > > Figure 9: Mobile IP Message Exchange > > > > > > 6.0 Key Distribution Center (KDC) AVPs > > > > The Mobile-IP protocol defines a set of security > > associations shared > > between the Mobile Node, Foreign Agent and Home Agents. These three > > security associations (Mobile-Home, Mobile-Foreign, and Foreign- > > Home), can be dynamically created by the AAAH. This > > requires that the > > AAAH create Mobile-IP Registration Keys, and that these keys be > > distributed to the three mobile entities, via the Diameter > > Protocol. > > AAA servers supporting the Diameter Mobile IP Application MUST > > implement the KDC AVPs defined in this document. In other > > words, AAA > > servers MUST be able to create three registration keys: the Mobile- > > Home, Mobile-Foreign, and Foreign-Home keys. > > > > The names of the KDC AVPs indicate the two entities sharing the > > security association defined by the encrypted key material; the > > intended receiver of the AVP is the first named entity. So, for > > instance, the MIP-MN-to-HA-Key AVP contains the Mobile-Home key > > encrypted in a way that allows it to be recovered by the > > mobile node. > > > > If strong authentication and confidentiality of the > > registration keys > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 29] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > is required, it is recommended that the CMS security > > application [9] > > be used. > > > > The following table describes the Diameter AVPs defined in > > the Mobile > > IP application, their AVP Code values, types, possible flag values > > and whether the AVP MAY be encrypted. > > > > +---------------------+ > > | AVP Flag rules | > > > > |----+-----+----+-----|----+ > > AVP Section | | > > |SHLD| MUST|MAY | > > Attribute Name Code Defined Value Type |MUST| MAY | > > NOT| NOT|Encr| > > > > -----------------------------------------|----+-----+----+-----|----| > > MIP-Algorithm- 345 6.9 Enumerated | M | P | > > | V | Y | > > Type | | | > > | | | > > MIP-FA-to-HA-Key 328 6.2 Grouped | M | P | > > | V | Y | > > MIP-FA-to-HA-SPI 318 6.12 Unsigned32 | M | P | > > | V | Y | > > MIP-FA-to-MN-Key 326 6.1 Grouped | M | P | > > | V | Y | > > MIP-FA-to-MN-SPI 319 6.11 Unsigned32 | M | P | > > | V | Y | > > MIP-HA-to-FA-Key 329 6.3 Grouped | M | P | > > | V | Y | > > MIP-HA-to-MN-Key 332 6.4 Grouped | M | P | > > | V | Y | > > MIP-MN-to-FA-Key 325 6.5 OctetString| M | P | > > | V | Y | > > MIP-MN-to-HA-Key 331 6.6 OctetString| M | P | > > | V | Y | > > MIP-Peer-SPI 342 6.7 Unsigned32 | M | P | > > | V | Y | > > MIP-Replay-Mode 346 6.10 Enumerated | M | P | > > | V | Y | > > MIP-Session-Key 343 6.8 OctetString| M | P | > > | V | Y | > > > > > > 6.1 MIP-FA-to-MN-Key AVP > > > > The MIP-FA-to-MN-Key AVP (AVP Code 326) is of type Grouped, and > > contains the Foreign Agent's session key, which it shares with the > > Mobile Node. Its Data field has the following ABNF grammar: > > > > MIP-FA-to-MN-Key ::= < AVP Header: 326 > > > { MIP-Peer-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > 6.2 MIP-FA-to-HA-Key AVP > > > > The MIP-FA-to-HA-Key AVP (AVP Code 328) is of type Grouped, and > > contains the Foreign Agent's session key, which it shares with the > > Home Agent. Its Data field has the following ABNF grammar: > > > > MIP-FA-to-HA-Key ::= < AVP Header: 328 > > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 30] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > { MIP-Peer-SPI } > > { MIP-Algorithm-Type } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > 6.3 MIP-HA-to-FA-Key AVP > > > > The MIP-HA-to-FA-Key AVP (AVP Code 329) is of type Grouped, and > > contains the Home Agent's session key, which it shares with the > > Foreign Agent. Its Data field has the following ABNF grammar: > > > > MIP-HA-to-FA-Key ::= < AVP Header: 329 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > 6.4 MIP-HA-to-MN-Key AVP > > > > The MIP-HA-to-MN-Key AVP (AVP Code 332) is of type Grouped, and > > contains the Home Agent's session key, which it shares with the > > Mobile Node. Its Data field has the following ABNF grammar: > > > > MIP-HA-to-MN-Key ::= < AVP Header: 332 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > 6.5 MIP-MN-to-FA-Key AVP > > > > The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type Grouped, and > > contains the Mobile Node's session key, which it shares with the > > Foreign Agent. The Home Agent uses this AVP in the construction of > > the Mobile IP "Unsolicted MN-FA Key from AAA Subtype" > > extension [15]. > > The SPI in the extension's FA SPI field is allocated by the Home > > Agent, but it SHOULD take into consideration the SPI > > requested by the > > Mobile Node in the "MN-FA Key Request From AAA Subtype" extension. > > > > MIP-MN-to-FA-Key ::= < AVP Header: 325 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 31] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > 6.6 MIP-MN-to-HA-Key AVP > > > > The MIP-MN-to-HA-Key AVP (AVP Code 331) is of type Grouped, and > > contains the Mobile Node's session key, which it shares > > with the Home > > Agent. The Home Agent uses this AVP in the construction of > > the Mobile > > IP "Unsolicted MN-HA Key from AAA Subtype" extension [15]. > > The SPI in > > the extension's HA SPI field is allocated by the Home Agent, but it > > SHOULD take into consideration the SPI requested by the Mobile Node > > in the "MN-HA Key Request From AAA Subtype" extension. > > > > MIP-MN-to-FA-Key ::= < AVP Header: 331 > > > { MIP-Algorithm-Type } > > { MIP-Replay-Mode } > > { MIP-Session-Key } > > * [ AVP ] > > > > > > 6.7 MIP-Peer-SPI AVP > > > > The MIP-Peer-SPI AVP (AVP Code 342) is of type Unsigned32, and > > contains the Security Parameter Index to use to reference > > the key in > > the associated MIP-Session-Key AVP. The SPI created MUST NOT be a > > value between zero (0) and 255, which is the reserved namespace > > defined in [4]. > > > > > > 6.8 MIP-Session-Key AVP > > > > The MIP-Session-Key AVP (AVP Code 343) is of type OctetString and > > contains the Session Key to be used between two Mobile IP entities. > > > > > > 6.9 MIP-Algorithm-Type AVP > > > > The MIP-Algorithm-Type AVP (AVP Code 345) is of type > > Enumerated, and > > contains the Algorithm identifier used to generate the associated > > Mobile IP authentication extension. The following values are > > currently defined: > > > > 1 Prefix+Suffix MD5 [4] > > 2 HMAC-MD5 [13] > > 3 SHA-1 [17] > > > > > > 6.10 MIP-Replay-Mode AVP > > > > The MIP-Replay-Mode AVP (AVP Code 346) is of type Enumerated and > > contains the replay mode the Home Agent should use when > > > > > > > > Calhoun, Perkins expires December 2001 > > [Page 32] > > > > > > > > > > > > Internet-Draft > > June 2001 > > > > > > authenticating the Mobile Node. > > > > The following values are supported (see [4] for more information): > > > > 0 None > > 1 Timestamps > > 2 Nonces > > > > > > 6.11 MIP-FA-to-MN-SPI AVP > > > > The MIP-FA-to-MN-SPI AVP (AVP Code 319) is of type Unsigned32, and > > contains the Security Parameter Index the Foreign Agent is > > to use to > > refer to the session key it shares with the Mobile Node. The SPI > > created MUST NOT be a value between zero (0) and 255, which is the > > reserved namespace defined in [4]. This AVP MAY be added in the HAA > > message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of > > the MIP-FA-to-MN-Key AVP. > > > > > > 6.12 MIP-FA-to-HA-SPI AVP > > > > The MIP-FA-to-HA-SPI AVP (AVP Code 318) is of type Unsigned32, and > > contains the Security Parameter Index the Foreign Agent is > > to use to > > refer to the session key it shares with the Home Agent. The SPI > > created MUST NOT be a value between zero (0) and 255, which is the > > reserved namespace defined in [4]. This AVP MAY be added in the HAA > > message by the Home Agent for the AAAH's use in MIP-Peer-SPI AVP of > > the MIP-FA-to-HA-Key AVP. > > From owner-aaa-wg@merit.edu Tue Jul 24 09:14:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15764 for ; Tue, 24 Jul 2001 09:14:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E1D279126C; Tue, 24 Jul 2001 09:14:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AD8FC9126D; Tue, 24 Jul 2001 09:14:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7CD769126C for ; Tue, 24 Jul 2001 09:14:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8DA85DDCE; Tue, 24 Jul 2001 09:16:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 1A62B5DDCB for ; Tue, 24 Jul 2001 09:16:07 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6ODEjN08225 for ; Tue, 24 Jul 2001 15:14:45 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Tue Jul 24 15:14:21 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Jul 2001 15:14:21 +0200 Message-ID: <577066326047D41180AC00508B955DDA05D1C536@eestqnt104.es.eu.ericsson.se> From: "Marta Morant-Artazkotz (ECE)" To: aaa-wg@merit.edu Subject: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments Date: Tue, 24 Jul 2001 15:14:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I need some clarification regarding some points in the last Diameter Base Protocol draft, version -07. These are my first comments: - First of all, as a general comment, IMHO any reference to the "Domain Routing Table" should be change to "Realm Routing Table" and any reference to "domain" while talking about the key of this table should be changed to "realm". Those concepts are piggybacked, as the NAI rfc2486 states: "administration of the NAI realm namespace will piggyback on the administration of the DNS namespace", but they are not neccessary identical. - Status attribute of a Diameter peer This attribute of a Diameter peer, an entry in the Peer Table, is described in section 2.6 to have the values listed in section 5.6 where the peer state machine is described. According to the description of peer connections made in sectio 5.1, I miss the "suspicious" state to describe a connection that might be broken but on which failover procedures has not been applied yet. IMHO, the values of the status in the Peer Control Block described section 5.5.3 should be added in the possible state values in the peer state machine. Per peer, there should be an entry in a table as described in 2.6, adding the state values in 5.5.3 to status and the flag and the related pending request queue. - Oigin-State-Id AVP In 8.16, page 94, it is stated that this AVP may be includeded in any Diameter message. IMHO, that means that [ Origin-State-Id ] should appear in all ABNF Diameter message definitions. In this draft, it does not appear in the Device Watchdog messages, nor *[ AVP ], perhaps attempting to make those messages simpler. - Session-Id AVP In 7.2, page 79, there is the ABNF definition of the protocol-related error answer message with the line < Session-Id >. For request of the type per peer, non proxiable messages (the others are Capabilities Exchange and Device Watchdog messages), the aswer must not include the Session-Id AVP, must it? The anwer must contain Session-Id AVP only if it was included in the request, as it is satated in 5.2, page 44: "if the Session-Id is present in the request, it MUST be included in the answer". IMHO, this AVP should be left optional in the ABNF definition. - Error-Reporting-Host AVP, In 7.1, page 74, it is stated that "a non-successful Result-Code AVP (one containing a non 2xxx value) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. IMHO, that means that this AVP should be included in any answer message. I miss it in the STA and ASA ABNF definitions in the base protocol draft. I will keep sending doubts as I collect them. Regards, Marta From owner-aaa-wg@merit.edu Tue Jul 24 09:23:29 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16401 for ; Tue, 24 Jul 2001 09:23:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54CA19126D; Tue, 24 Jul 2001 09:23:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 228749126E; Tue, 24 Jul 2001 09:23:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E5FC99126D for ; Tue, 24 Jul 2001 09:23:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 65D255DDCE; Tue, 24 Jul 2001 09:25:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by segue.merit.edu (Postfix) with ESMTP id 3842A5DDCB for ; Tue, 24 Jul 2001 09:25:04 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) id 15P2A2-00053b-00; Tue, 24 Jul 2001 15:23:42 +0200 Received: from ee.tu-berlin.de (root@ftmail.ee.tu-berlin.de [130.149.49.250]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6ODNgh16713; Tue, 24 Jul 2001 15:23:42 +0200 Message-ID: <3B5D7729.CB1E5134@ee.tu-berlin.de> Date: Tue, 24 Jul 2001 15:24:57 +0200 From: Guenter Schaefer X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: Pat Calhoun Cc: "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Text for Issue 91 References: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> <20010724054426.F10225@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear participants of the AAA-WG, please excuse me for coming back to an issue that you may assume resolved, but that still is somehow unclear to me: In case of a handover of a mobile node from one FAold to an FAnew, how are the internal SPI databases updated conceptually at the two foreign agents and at the home agent? And how is it assured that SPIs remain unique between FAnew and HA? If the AAAF communicates an already established set of session keys K_FAold_MN and K_FAold_HA to the new foreign agent FAnew, it may happen (maybe with a low probability) that the SPI corresponding to K_FAold_HA is already used for another key between FAnew and HA. Am I missing something here? If such an "SPI-collision" would occur, how could this issue be resolved? I would appreciate any comment on this, with kind regards, Guenter Schaefer P.S.: Please excuse me for coming into your discussion "out of nowhere". We (at TKN, Technical University of Berlin, Germany) are currently studying the Mobile IP related AAA internet drafts in the context of a joint project with Siemens Corporation. Special focus is on authentication performance during handover. ------------------------------------------------------------------------ Guenter Schaefer, Institute of Telecommunication Systems, Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Tue Jul 24 09:48:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17667 for ; Tue, 24 Jul 2001 09:48:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A147491272; Tue, 24 Jul 2001 09:47:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B0E09127A; Tue, 24 Jul 2001 09:47:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1126091272 for ; Tue, 24 Jul 2001 09:47:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98D875DDCE; Tue, 24 Jul 2001 09:49:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0EA085DDCB for ; Tue, 24 Jul 2001 09:49:41 -0400 (EDT) Received: (qmail 26183 invoked by uid 500); 24 Jul 2001 13:37:23 -0000 Date: Tue, 24 Jul 2001 06:37:23 -0700 From: Pat Calhoun To: Guenter Schaefer Cc: Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Text for Issue 91 Message-ID: <20010724063723.I10225@charizard.diameter.org> Mail-Followup-To: Guenter Schaefer , Pat Calhoun , "Martin Julien (ECE)" , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> <20010724054426.F10225@charizard.diameter.org> <3B5D7729.CB1E5134@ee.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5D7729.CB1E5134@ee.tu-berlin.de>; from schaefer@ee.tu-berlin.de on Tue, Jul 24, 2001 at 03:24:57PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 24, 2001 at 03:24:57PM +0200, Guenter Schaefer wrote: > please excuse me for coming back to an issue that you may assume > resolved, but that still is somehow unclear to me: > > In case of a handover of a mobile node from one FAold to an FAnew, > how are the internal SPI databases updated conceptually at the > two foreign agents and at the home agent? > And how is it assured that SPIs remain unique between FAnew and HA? Because currently any handoff requires AAA interactions. So, the Home Agent will be contacted, and will re-use (or generate new) SPIs, which are returned to the new Foreign Agent. The draft states that once fast handoff becomes popularized, extensions to Diameter could be introduced. > If the AAAF communicates an already established set of session keys > K_FAold_MN and K_FAold_HA to the new foreign agent FAnew, it > may happen (maybe with a low probability) that the SPI corresponding > to K_FAold_HA is already used for another key between FAnew and HA. > > Am I missing something here? That functionality was removed from the protocol.... did you find references to text in the mobile ip draft that claims support for the AAAF distributing local keying information? > If such an "SPI-collision" would occur, how could this issue be > resolved? This is obviously a MIP issue, and one that they will have to resolve in the face of upcoming Context Transfer work in seamoby, because oFA will transfer its MIP SA to nFA. > P.S.: Please excuse me for coming into your discussion "out of > nowhere". We (at TKN, Technical University of Berlin, Germany) > are currently studying the Mobile IP related AAA internet > drafts in the context of a joint project with Siemens > Corporation. Special focus is on authentication performance > during handover. Ah, well handoff performance wasn't addressed in the application. There is text that states that once fast handoff (and/or context transfer) is completed, some Diameter extensions will be necessary. PatC From owner-aaa-wg@merit.edu Tue Jul 24 10:13:01 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19209 for ; Tue, 24 Jul 2001 10:13:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 187CB91273; Tue, 24 Jul 2001 10:12:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE75591274; Tue, 24 Jul 2001 10:12:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C209091273 for ; Tue, 24 Jul 2001 10:12:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 649235DDD6; Tue, 24 Jul 2001 10:14:52 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id D97805DDCB for ; Tue, 24 Jul 2001 10:14:51 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6OEDKi12049 for ; Tue, 24 Jul 2001 09:13:33 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 24 Jul 2001 09:13:17 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.1600); Tue, 24 Jul 2001 09:13:17 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: Internet Draft: AAA Local Security Association Date: Tue, 24 Jul 2001 09:13:16 -0500 Message-ID: <57A26D272F67A743952F6B4371B8F81108C1E9@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: Internet Draft: AAA Local Security Association Thread-Index: AcEUSjzLYr9PooAOEdWaKAAAhlNL6Q== From: To: X-OriginalArrivalTime: 24 Jul 2001 14:13:17.0350 (UTC) FILETIME=[C8E26460:01C1144A] Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA19209 Hello all, A new draft, titled, "AAA Local Security Association (LSA): The Temporary shared Key (TSK)" had been submitted last Friday. Abstract: This draft describes a mechanism to set up a Local Security Association (LSA) between a user and the visited network when the user is roaming. It defines all the required related funvtionalities such as the key generation, distribution and update procedures; it also describes the reasons and the benefits of the adoption of such LSA. The applicability of this draft is mainly for AAA Diameter and for URP (User Registration Protocol), but the mechanism can be adopted more in general in each case where the user (or mobile node) needs to establish a security association with a foreign domain while roaming. Before the IETF announcement, this document can also be found at the following address : http://people.nokia.net/~patil/draft-le-aaa-lsa-tsk-00.txt Comments are welcome, Regards, Franck From owner-aaa-wg@merit.edu Tue Jul 24 10:18:28 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19606 for ; Tue, 24 Jul 2001 10:18:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DD2191274; Tue, 24 Jul 2001 10:18:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5DC3F91275; Tue, 24 Jul 2001 10:18:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 73C8791274 for ; Tue, 24 Jul 2001 10:18:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E707B5DDD6; Tue, 24 Jul 2001 10:20:10 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by segue.merit.edu (Postfix) with ESMTP id B91B35DDCB for ; Tue, 24 Jul 2001 10:20:10 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) id 15P31N-0006wD-00; Tue, 24 Jul 2001 16:18:49 +0200 Received: from ee.tu-berlin.de (root@ftmail.ee.tu-berlin.de [130.149.49.250]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6OEImh18140; Tue, 24 Jul 2001 16:18:48 +0200 Message-ID: <3B5D8413.3230159D@ee.tu-berlin.de> Date: Tue, 24 Jul 2001 16:20:03 +0200 From: Guenter Schaefer X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: Pat Calhoun Cc: Martin.Julien@ece.ericsson.se, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Text for Issue 91 References: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> <20010724054426.F10225@charizard.diameter.org> <3B5D7729.CB1E5134@ee.tu-berlin.de> <20010724063723.I10225@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear Mrs. Calhoun, thank you very much for your quick clarification. Pat Calhoun wrote: > > That functionality was removed from the protocol.... did you find > references to text in the mobile ip draft that claims support for > the AAAF distributing local keying information? My confusion maybe comes from the fact, that I was working with an already outdated version of the draft (draft-ietf-aaa-diameter-mobileip-06.txt). Section 2.1 was stating: "If the MIP-Previous-FA-Host AVP is found in the request, the Diameter client requests that the server return the registration key that was assigned to the previous Foreign Agent for use with the Mobile Node and Home Agent. The registration key is identified through the use of the User-Name AVP." I have just checked the latest version available at the IETF web-page (draft-ietf-aaa-diameter-mobileip-07.txt). This passage is still there. However, I currently can not see any other reason for the MIP-Previous-FA-Host AVP than to re-use an existing security association between oFA-HA for nFA-HA. So if the idea of speeding up local handovers has been postponed for further study, maybe all references and explanations regarding the MIP-Previous-FA-Host AVP are superfluous (e.g. section 4.5). With best regards, Guenter Schaefer ------------------------------------------------------------------------ Guenter Schaefer, Institute of Telecommunication Systems, Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Tue Jul 24 10:33:17 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20791 for ; Tue, 24 Jul 2001 10:33:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00D2D91276; Tue, 24 Jul 2001 10:33:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C0C1391278; Tue, 24 Jul 2001 10:33:19 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFACD91276 for ; Tue, 24 Jul 2001 10:33:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FA575DDD6; Tue, 24 Jul 2001 10:35:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 15A6C5DDCB for ; Tue, 24 Jul 2001 10:35:08 -0400 (EDT) Received: (qmail 27329 invoked by uid 500); 24 Jul 2001 14:22:50 -0000 Date: Tue, 24 Jul 2001 07:22:50 -0700 From: Pat Calhoun To: Guenter Schaefer Cc: Pat Calhoun , Martin.Julien@ece.ericsson.se, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Proposed Text for Issue 91 Message-ID: <20010724072250.K10225@charizard.diameter.org> Mail-Followup-To: Guenter Schaefer , Pat Calhoun , Martin.Julien@ece.ericsson.se, aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA02@eestqnt104.es.eu.ericsson.se> <20010724054426.F10225@charizard.diameter.org> <3B5D7729.CB1E5134@ee.tu-berlin.de> <20010724063723.I10225@charizard.diameter.org> <3B5D8413.3230159D@ee.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5D8413.3230159D@ee.tu-berlin.de>; from schaefer@ee.tu-berlin.de on Tue, Jul 24, 2001 at 04:20:03PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 24, 2001 at 04:20:03PM +0200, Guenter Schaefer wrote: > Dear Mrs. Calhoun, hmmmm... wrong gender :( > Pat Calhoun wrote: > > > > That functionality was removed from the protocol.... did you find > > references to text in the mobile ip draft that claims support for > > the AAAF distributing local keying information? > > My confusion maybe comes from the fact, that I was working with > an already outdated version of the draft > (draft-ietf-aaa-diameter-mobileip-06.txt). Ah, then you should be reviewing -07. > > Section 2.1 was stating: > > "If the MIP-Previous-FA-Host AVP is found in the request, the Diameter > client requests that the server return the registration key that was > assigned to the previous Foreign Agent for use with the Mobile Node > and Home Agent. The registration key is identified through the use of > the User-Name AVP." > > I have just checked the latest version available at the IETF web-page > (draft-ietf-aaa-diameter-mobileip-07.txt). This passage is > still there. However, I currently can not see any other reason > for the MIP-Previous-FA-Host AVP than to re-use an existing > security association between oFA-HA for nFA-HA. > > So if the idea of speeding up local handovers has been postponed > for further study, maybe all references and explanations regarding > the MIP-Previous-FA-Host AVP are superfluous (e.g. section > 4.5). Thanks for the catch. So, the passage in 2.1 needs to be removed, as well as the second paragraphs in sections 4.5 and 4.6. These should have been removed, but somehow were missed. > With best regards, Thanks for the info, PatC From owner-aaa-wg@merit.edu Tue Jul 24 11:11:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23613 for ; Tue, 24 Jul 2001 11:11:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E2EBF912AE; Tue, 24 Jul 2001 11:11:20 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AE7B6912BE; Tue, 24 Jul 2001 11:11:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9A5E0912AE for ; Tue, 24 Jul 2001 11:11:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31BEE5DDDE; Tue, 24 Jul 2001 11:13:15 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 66E895DDE2 for ; Tue, 24 Jul 2001 11:13:14 -0400 (EDT) Received: (qmail 28459 invoked by uid 500); 24 Jul 2001 15:00:56 -0000 Date: Tue, 24 Jul 2001 08:00:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Re: Diameter interop testing event (bake off) Message-ID: <20010724080055.O10225@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk Tony, Thanks for putting this together. I've taken a brief look at the web page, and the only issue that could arise is the fact that a list of participants is available. Typically, this information isn't disclosed to folks that didn't attend the interop event. my 2 cents, PatC >All, > >Here is the official invitation to the next Diameter interoperability >testing event (bake off). > > > * Location: Ericsson Research, 2100 Shattuck Ave, Berkeley, > California. > > * Date: The first week of October (10/1/01-10/5/01). > > * No Fee, but the registration is binding. > >Please find all additional information and how to register at the link >below. > >http://standards.ericsson.net/diameter-bake-off > >/Tony From owner-aaa-wg@merit.edu Tue Jul 24 11:36:09 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25395 for ; Tue, 24 Jul 2001 11:36:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5F6391203; Tue, 24 Jul 2001 11:36:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 97FB2912BE; Tue, 24 Jul 2001 11:36:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 899F291203 for ; Tue, 24 Jul 2001 11:36:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 305F05DDCB; Tue, 24 Jul 2001 11:38:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1CEA05DDB4 for ; Tue, 24 Jul 2001 11:38:07 -0400 (EDT) Received: from Interlinknetworks.com (pm552-05.dialip.mich.net [198.110.22.159]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 23A9B7D for ; Tue, 24 Jul 2001 11:36:59 -0400 (EDT) Message-ID: <3B5D95E2.61FC5F84@Interlinknetworks.com> Date: Tue, 24 Jul 2001 08:36:02 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit If a proxy or relay agent hides the topology by removing the Route-Record AVPs, how does a home-server produce the list of Source-Route AVPs which he needs to subsequently send a reverse-request? Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: 6.1.9 Relaying and Proxying Server-Initiated Requests Server-initiated messages MUST include the Source-Route AVPs, whose contents are identical to the Record-Route AVPs received in requests from the access device for the given session, but in the reverse order. 6.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request. From owner-aaa-wg@merit.edu Tue Jul 24 12:37:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00063 for ; Tue, 24 Jul 2001 12:37:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E7D912EF; Tue, 24 Jul 2001 12:36:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E4C2912ED; Tue, 24 Jul 2001 12:36:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06ADC9127D for ; Tue, 24 Jul 2001 12:36:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CB1A75DDDB; Tue, 24 Jul 2001 12:38:39 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 86FBE5DDAC for ; Tue, 24 Jul 2001 12:38:39 -0400 (EDT) Received: (qmail 29176 invoked by uid 500); 24 Jul 2001 16:26:21 -0000 Date: Tue, 24 Jul 2001 09:26:21 -0700 From: Pat Calhoun To: David Spence Cc: AAA Working Group Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs Message-ID: <20010724092621.Q10225@charizard.diameter.org> Mail-Followup-To: David Spence , AAA Working Group References: <3B5D95E2.61FC5F84@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5D95E2.61FC5F84@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Tue, Jul 24, 2001 at 08:36:02AM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 24, 2001 at 08:36:02AM -0700, David Spence wrote: > If a proxy or relay agent hides the topology by removing the Route-Record > AVPs, how does a home-server produce the list of Source-Route > AVPs which he needs to subsequently send a reverse-request? I believe that some additional text will be needed in section 6.3 below that states that stateful proxies that hide topology MUST keep the Record-Route path in case it receives a server-initiated request. Does that work? PatC > > Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: > > 6.1.9 Relaying and Proxying Server-Initiated Requests > > Server-initiated messages MUST include the Source-Route AVPs, whose > contents are identical to the Record-Route AVPs received in requests > from the access device for the given session, but in the reverse > order. > > 6.3 Hiding Network Topology > > A Relay or Proxy agent routing messages outside of their > administrative domain MAY need to hide the internal Diameter > topology. This is done by removing all Route-Record AVPs in a > request. From owner-aaa-wg@merit.edu Tue Jul 24 13:35:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04923 for ; Tue, 24 Jul 2001 13:35:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE9029127C; Tue, 24 Jul 2001 13:35:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C5479127D; Tue, 24 Jul 2001 13:35:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 55C3C9127C for ; Tue, 24 Jul 2001 13:35:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 27FFF5DD99; Tue, 24 Jul 2001 13:37:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id AC39A5DD8C for ; Tue, 24 Jul 2001 13:37:48 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6OHZu525832; Tue, 24 Jul 2001 12:35:56 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6OHZtA28371; Tue, 24 Jul 2001 12:35:56 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA22539; Tue, 24 Jul 2001 12:35:54 -0500 (CDT) Received: from ericsson.com (busam64.berkeley.us.am.ericsson.se [138.85.159.214]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA29083; Tue, 24 Jul 2001 12:35:51 -0500 (CDT) Message-ID: <3B5DB094.73F1644@ericsson.com> Date: Tue, 24 Jul 2001 10:29:56 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat.Calhoun@Sun.COM Cc: aaa-wg@merit.edu, kevin.purser@ericsson.com, diameter@diameter.org Subject: Re: [AAA-WG]: Diameter interop testing event (bake off) References: <200107241508.IAA06632@heliopolis.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Okay, I will go a head and remove it from the web page. Thanks, /Tony Patrice Calhoun wrote: > Tony, > > Thanks for putting this together. I've taken a brief look at the web page, > and the only issue that could arise is the fact that a list of participants > is available. Typically, this information isn't disclosed to folks that > didn't attend the interop event. > > my 2 cents, > > PatC > >All, > > > >Here is the official invitation to the next Diameter interoperability > >testing event (bake off). > > > > > > * Location: Ericsson Research, 2100 Shattuck Ave, Berkeley, > > California. > > > > * Date: The first week of October (10/1/01-10/5/01). > > > > * No Fee, but the registration is binding. > > > >Please find all additional information and how to register at the link > >below. > > > >http://standards.ericsson.net/diameter-bake-off > > > >/Tony > > > > > > > > From owner-aaa-wg@merit.edu Tue Jul 24 15:47:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15262 for ; Tue, 24 Jul 2001 15:47:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F63F91209; Tue, 24 Jul 2001 15:47:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0F7DE9126F; Tue, 24 Jul 2001 15:47:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1321E9127E for ; Tue, 24 Jul 2001 15:47:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E7215DDAC; Tue, 24 Jul 2001 15:49:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 923BA5DD8C for ; Tue, 24 Jul 2001 15:49:25 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6OJlX501045; Tue, 24 Jul 2001 14:47:33 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6OJlX207509; Tue, 24 Jul 2001 14:47:33 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA28825; Tue, 24 Jul 2001 14:47:33 -0500 (CDT) Received: from ericsson.com (busam64.berkeley.us.am.ericsson.se [138.85.159.214]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA00971; Tue, 24 Jul 2001 14:47:30 -0500 (CDT) Message-ID: <3B5DCF70.BC0A7F51@ericsson.com> Date: Tue, 24 Jul 2001 12:41:36 -0700 From: Tony Johansson X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Diameter interop testing event (bake off) References: <200107241508.IAA06632@heliopolis.eng.sun.com> <3B5DB094.73F1644@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit All, The Diameter bake-off web page is now updated! BR, Tony Johansson wrote: > Okay, I will go a head and remove it from the web page. > > Thanks, > > /Tony > > Patrice Calhoun wrote: > > > Tony, > > > > Thanks for putting this together. I've taken a brief look at the web page, > > and the only issue that could arise is the fact that a list of participants > > is available. Typically, this information isn't disclosed to folks that > > didn't attend the interop event. > > > > my 2 cents, > > > > PatC > > >All, > > > > > >Here is the official invitation to the next Diameter interoperability > > >testing event (bake off). > > > > > > > > > * Location: Ericsson Research, 2100 Shattuck Ave, Berkeley, > > > California. > > > > > > * Date: The first week of October (10/1/01-10/5/01). > > > > > > * No Fee, but the registration is binding. > > > > > >Please find all additional information and how to register at the link > > >below. > > > > > >http://standards.ericsson.net/diameter-bake-off > > > > > >/Tony > > > > > > > > > > > > From owner-aaa-wg@merit.edu Tue Jul 24 17:29:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24821 for ; Tue, 24 Jul 2001 17:29:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 57A079120A; Tue, 24 Jul 2001 17:29:05 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 257EC9127D; Tue, 24 Jul 2001 17:29:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 151D49120A for ; Tue, 24 Jul 2001 17:29:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44D685DDBB; Tue, 24 Jul 2001 17:31:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 828845DD8C for ; Tue, 24 Jul 2001 17:30:59 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA72183 for ; Tue, 24 Jul 2001 14:20:41 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 24 Jul 2001 14:20:41 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Filing issues Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk As we approach last call on the Diameter specifications, it is critical that we continue to track and resolve issues as they arise. WG last call means that this is your last opportunity as a WG to comment on the specifications. If you believe that the Diameter document needs to change in some way, then you MUST file an issue in order to enable your comments to be taken into consideration. At this stage of things, no issue is too small for consideration. That includes editorial suggestions, spelling mistakes, etc. If you want a change to be made, file an issue. Note that writing an individual submission IETF draft is NOT an effective mechanism for filing a Diameter document change request. Individual submissions are not part of the AAA WG charter, and since we are focussed on bringing the existing AAA WG work items to closure, we will not be promoting these drafts to WG work items in the near future. So if you want your ideas taken into consideration, please file an issue. In general, it is better to do this sooner rather than later; every day that passes will make it more difficult to implement your suggestion, even if it is a good idea. From owner-aaa-wg@merit.edu Tue Jul 24 17:50:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26655 for ; Tue, 24 Jul 2001 17:50:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 728449127D; Tue, 24 Jul 2001 17:50:38 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 446039127E; Tue, 24 Jul 2001 17:50:38 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1FCD59127D for ; Tue, 24 Jul 2001 17:50:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4D67A5DDC5; Tue, 24 Jul 2001 17:52:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id E4AD95DD8C for ; Tue, 24 Jul 2001 17:52:32 -0400 (EDT) Received: from ip190.zurich31.pub-ip.ch.psi.net (HELO jc.yahoo.com) (154.15.31.190) by smtp.mail.vip.sc5.yahoo.com with SMTP; 24 Jul 2001 21:51:02 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010724174249.00c5bac0@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Jul 2001 23:48:20 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: base draft 07 comments Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, A few comments on the base -07 draft... Mainly editorial stuff including typos etc. In 1.1: - second paragraph ("All data delivered by the protocol..."): "and AVPs which are explicitly excluded are not included": there isn't anything in the ABNF to state that AVPs are excluded. - last paragraph, "(known as a proxy)" is not consistent with other definitions in the draft. Should say "(known as a proxy or relay)". - also, that paragraph defines a server as either a proxy/relay or as a server. It should be called an agent, or the definition should be changed to only include the real "server" function. In 1.3: - "Accounting record" def is incomplete (ends with "or accounting events from several"). - the AVP definition is restrictive. It might include protocol-specific data (e.g. routing information), not only pure AAA data. - "Diameter node" suddenly mentions translation agents, while this is not listed in the "Diameter agent" definition - "Redirector": inconsistent use of "Redirect", "Redirector", "Re-direct"... [also throughout the draft]. - the definitions of "Upstream server" and "Downstream server", other than the fact that they are reversed ;-> are incorrect: it should be "nodes" and not servers, and the definition should be something "a node that is closer to the client [resp. home server] in the routing path, relative to a given node". It might be the client [resp. home server] itself, so it does not necessarily provide "routing services" towards it. In 2.0 - 5th paragraph ("Diameter proxies..."), "in addition"->"In addition" :-) - 8th paragraph ("Communication between Diameter peers..."): you mean nodes, not peers, right? - in the same paragraph, the last sentence implies that all messages are related to a session (those messages would actually be exchanged between a client and a server, not any random set of nodes/peers). This does not apply to all the base protocol messages such as CER/CEA, DWR/DWA, etc.). - in the last paragraph, the semantics of Authorization-Lifetime have not been updated In 2.1 - 3rd paragraph, "A Diameter node MAY initiate connections from any source port" *except TBD*? - same paragraph, "...MAY *be* any of a peer's valid IP addresses." - where did the 4th paragraph "A given Diameter process SHOULD use the same port number ..." come from? That's ugly and unnecessary, as the process identity will be communicated in CER/CEA. - 5th paragraph, there should be a provision for hosts marked "bad" for some reason. - 7th and last paragraph, there is a mix between the sockets API (ECONNREFUSED) and TCP/ICMP packet exchanges. Should probably replace "ECONNREFUSED (a reset from the transport)" with "a reset from the transport" (I think most TCP stacks interpret the ICMP error messages themselves and return ECONNREFUSED). Actually, this isn't that much the Diameter implementation itself, but the platform it is using. To be clarified. In 2.3.1: - 1st paragraph, "Defining a new AVP value is the best approach when a new application needs to make use of an existing Diameter application..." Isn't that recursive? :-( - last paragraph, "Furthermore, if the command code on which the AVP value is to be used would require a different set of mandatory AVPs be present *when the new AVP value is used*, the list of AVPs must accompany the request." (needs some rewording) - should reference something in 11.x, but I don't know what :-( In 2.3.2: - 1st paragraph, same application/application problem. - 2nd paragraph, why MUST it be one of the listed types? Since AVPs are opaque to those who don't use them and the AVP type is not included in the packet... - should reference 11.1.1 In 2.3.3 - should reference 11.3 In 2.4 - I guess the whole Acct-Application-Id thing with additional AVPs to support in the same Accounting messages invalidates the whole ABNF consistency thing... In 2.5: - I guess this is historical, but history in a not-yet-published RFC seems weird... Why not move the Mobile-IP application to 3? - I would also swap the E2E security app and NASREQ. The first one is more like an extension of the base draft while the second (like Mobile-IP) are real AAA apps. - oh, by the way, it's CMS, not E2E now :-) [also happens in other places in the draft] - 3rd paragraph, "Relay and redirect agents MUST advertise...": what should an agent that is a server for some requests (those for users in the local domain) and a relay/redirector for others (users in remote domains) advertise? In 2.6: - the Host identity received in CER/CEA MUST be saved! I guess there should actually be two values: one that is configured (or discovered using DNS, SLP...) until the connection is established, and then the official unique but consistent value advertised in CER/CEA. Actually, there might be several of the configured/discovered identities if the node finds out that multiple identities point to the same process. - as discussed previously, I don't think the role belongs here: a peer might be primary for a realm, secondary for another, alternate for yet another... In 2.7 - realm/domain inconsistencies (also throughout the draft), as already pointed out by Marta. - Application identifier: should clarify that accounting and auth messages might actually be sent to different servers - local action/proxy: "See section 6.1.8 for *proxying* guidelines." - local action/redirect: why home server? Should just be "agent"... - "Expiration time. Specifies the time which dynamically discovered a route table entry expire." -> "Expiration time. Specifies the time which *a* dynamically discovered route table entry expireS." ("a" moved, "s" added) - 2nd paragraph "It is important to note...", "proxies SHOULD NOT reorder AVPs": I would say they MUST NOT reorder AVPs of the same type. - last paragraph: "When a request is routed, the target server MUST have advertised the Application Identifier (see section 2.5) for the given message, or have advertised itself as a relay or proxy agent."... Mmmm. What if the local node has not connected to that agent (not server, btw) yet, so doesn't know if it actually advertises the said application? Also, what should it do if there's a mismatch here? In 2.8 - 1st paragraph, translation agents are not defined in 1.3 - 4th paragraph "A stateful agent...", Authorized-Lifetime -> Session-Timeout In 2.8.1 - 4th paragraph "The example provided...", the last part "which is routed back to NAS using Diameter routing AVPs" is no longer true -> "which is routed back to NAS using saved transaction state" In 2.8.2 - 2nd and 5th paragraphs may be a bit too strong: CMS can be applied on part of the AVPs only (those that would not be modified, e.g.). And CMS will most certainly apply to AVPs that are not modified (i.e. authorization answers and accounting requests) In 3.0 - "r(eserved) - this flag bit is..." -> "these flag bits are..." - Hop-by-Hop identifier, "The sender MUST ensure that the Hop-by-Hop identifier in a request is locally unique (to the sender)". This might be too strong: it actually needs to be unique on a per-connection basis only. - End-to-End identifier, I guess the method described should only be a recommendation, not part of the spec (which should state that it must be unique for a given Origin-Host ID for the lifetime of the message)? - same paragraph, should mention here that a server is supposed to answer the same thing it did upon reception of a duplicate, and not take any action that would affect state again? In 3.1 - should renumber everything so that we have something consistent and contiguous rather than this sparse table? In 3.2 - diameter-name = ALPHA *(ALPHA / DIGIT / "-") should probably be diameter-name = ALPHA *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) (I suppose we don't want command names ending with a dash?) In 5.3.*: - I guess we should add some AVPs to advertise the local values of the timers (Ti, Tr, Tw, Td...) so that incompatible values are detected immediately and the connection torn down with a nice log (a la OSPF IIRC - or is it IS-IS?) In 11.3: - All values, other than zero... -> All other values, except 0... That's it for today, I'll continue reading the new drafts tomorrow and keep you posted (and don't think there are no problems between 3.2 and 5.3 or between 5.3 and 11.3, those are just a few jumps I made while reading up to 3.2). On a different subject, something I've been thinking about some time ago, but didn't check against the docs: in a roaming environment, what is important to an ISP is not that the accounting data from the original client be signed by that client (it might not know the client at all, and doesn't care). What they care about is that the accounting data be signed by their roaming "peer" (partner), i.e. the one that will pay them. Actually, if the accounting data includes money (you know, $$$), proxies might change that amount on the way (to reflect margins of brokers), but it should nevertheless be signed at some point... Some AVPs might actually have multiple signatures, or be signed, then checked, then modified (old sig removed), and resigned multiple times on the way. Let me know what you think. Probably a few issues to open :-( Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Tue Jul 24 18:18:21 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27922 for ; Tue, 24 Jul 2001 18:18:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 999899127E; Tue, 24 Jul 2001 18:18:26 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B8259127F; Tue, 24 Jul 2001 18:18:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 46DFB9127E for ; Tue, 24 Jul 2001 18:18:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77C485DDD8; Tue, 24 Jul 2001 18:20:21 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id 568605DD8C for ; Tue, 24 Jul 2001 18:20:21 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA20882 for ; Tue, 24 Jul 2001 15:18:59 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA15182 for ; Tue, 24 Jul 2001 15:18:59 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3LL2TBMC>; Tue, 24 Jul 2001 17:18:59 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECF9D@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: aaa-wg@merit.edu Subject: [AAA-WG]: Clarification on ABNF Command specification Date: Tue, 24 Jul 2001 17:18:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk from -07, Section 3.2: fixed = [qual] "<" avp-spec ">" ; Defines the fixed position of an AVP required = [qual] "{" avp-spec "}" ; The AVP MUST be present optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. Fixed AVPs are implicitly required, correct? And from this, it appears that it may be legal for AVPs to appear in both the fixed and required sections. Is there a logical reason for any AVP to appear in both? -Brian From owner-aaa-wg@merit.edu Tue Jul 24 20:10:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02495 for ; Tue, 24 Jul 2001 20:10:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 88E329120D; Tue, 24 Jul 2001 20:10:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5AE0D9127F; Tue, 24 Jul 2001 20:10:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3835C9120D for ; Tue, 24 Jul 2001 20:10:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 868785DDDA; Tue, 24 Jul 2001 20:12:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 435DC5DDD8 for ; Tue, 24 Jul 2001 20:12:50 -0400 (EDT) Received: (qmail 32327 invoked by uid 500); 24 Jul 2001 23:58:13 -0000 Date: Tue, 24 Jul 2001 16:58:13 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Clarification on ABNF Command specification Message-ID: <20010724165813.V10225@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECF9D@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECF9D@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Tue, Jul 24, 2001 at 05:18:58PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 24, 2001 at 05:18:58PM -0500, Cain Brian-BCAIN1 wrote: > > from -07, Section 3.2: > fixed = [qual] "<" avp-spec ">" > ; Defines the fixed position of an AVP > > required = [qual] "{" avp-spec "}" > ; The AVP MUST be present > > optional = [qual] "[" avp-name "]" > ; The avp-name in the 'optional' rule cannot > ; evaluate to any AVP Name which is included > ; in a fixed or required rule. > > Fixed AVPs are implicitly required, correct? And from this, it appears that > it may be legal for AVPs to appear in both the fixed and required sections. > Is there a logical reason for any AVP to appear in both? A fixed AVP is required, but has a specific location in the packet. A required AVP must also be present, but may appear anywhere in the packet. PatC From owner-aaa-wg@merit.edu Wed Jul 25 02:32:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02069 for ; Wed, 25 Jul 2001 02:32:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15BDC91280; Wed, 25 Jul 2001 02:31:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D97FF91282; Wed, 25 Jul 2001 02:31:53 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 64A9991280 for ; Wed, 25 Jul 2001 02:31:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 320A35DDBA; Wed, 25 Jul 2001 02:33:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 1E85E5DD92 for ; Wed, 25 Jul 2001 02:33:42 -0400 (EDT) Received: from Interlinknetworks.com (pm552-19.dialip.mich.net [198.110.22.173]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 37F617C; Wed, 25 Jul 2001 02:32:33 -0400 (EDT) Message-ID: <3B5E67C9.52A9EC55@Interlinknetworks.com> Date: Tue, 24 Jul 2001 23:31:37 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: AAA Working Group Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs References: <3B5D95E2.61FC5F84@Interlinknetworks.com> <20010724092621.Q10225@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > On Tue, Jul 24, 2001 at 08:36:02AM -0700, David Spence wrote: > > If a proxy or relay agent hides the topology by removing the Route-Record > > AVPs, how does a home-server produce the list of Source-Route > > AVPs which he needs to subsequently send a reverse-request? > > I believe that some additional text will be needed in section 6.3 > below that states that stateful proxies that hide topology MUST keep > the Record-Route path in case it receives a server-initiated > request. > > Does that work? I don't think so. It works for stateful proxies, though it's more trouble to program. But sec. 6.3, below, doesn't specify that the agents removing the Route-Record AVPs must be stateful. And indeed they need not be stateful in order to successfully remove Route-Record AVPs from a request and still be able to process the answers. So non-stateful agents that remove Route-Record AVPs are still a problem. It occurs to me, however, that removing Route-Record AVPs causes another problem as well. It defeats the whole purpose of Route-Record AVPs, namely, to facilitate loop detection. If Route-Record AVPs are removed and the message somehow loops back through an agent downstream (closer to the client) than the one that removed the Route-Record AVPs, then that agent cannot detect a loop. Of course, you may argue that the agent that removed the Route-Record AVPs will detect the loop when the message gets back to him. But that is not necessarily the case because the agent to which he forwarded the request may also have deleted Route-Record AVPs. One solution to the problem, then, is to delete sec. 6.3, and not allow agents to remove Route-Record AVPs. A better solution, to my way of thinking, is to abandon the idea of routing server-initiated requests by using Source-Route AVPs and go back to routing them the same way client to server requests are routed. Given Bernard's request, I think I will post an issue for this problem. > > PatC > > > > Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: > > > > 6.1.9 Relaying and Proxying Server-Initiated Requests > > > > Server-initiated messages MUST include the Source-Route AVPs, whose > > contents are identical to the Record-Route AVPs received in requests > > from the access device for the given session, but in the reverse > > order. > > > > 6.3 Hiding Network Topology > > > > A Relay or Proxy agent routing messages outside of their > > administrative domain MAY need to hide the internal Diameter > > topology. This is done by removing all Route-Record AVPs in a > > request. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 02:47:34 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02337 for ; Wed, 25 Jul 2001 02:47:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 462DF91283; Wed, 25 Jul 2001 02:47:37 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19DBD91284; Wed, 25 Jul 2001 02:47:37 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 09C4F91283 for ; Wed, 25 Jul 2001 02:47:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E66805DDBA; Wed, 25 Jul 2001 02:49:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D21965DD92 for ; Wed, 25 Jul 2001 02:49:32 -0400 (EDT) Received: from Interlinknetworks.com (pm552-19.dialip.mich.net [198.110.22.173]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 2CDCF7C for ; Wed, 25 Jul 2001 02:48:24 -0400 (EDT) Message-ID: <3B5E6B80.C8804489@Interlinknetworks.com> Date: Tue, 24 Jul 2001 23:47:28 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Problem with removing Route-Record AVPs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Problem with removing Route-Record AVPs Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: July 24, 2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01594.html Document: Base Comment type: T Priority: S Section: 6.3 and 6.1.9 Rationale/Explanation of issue: If a proxy or relay agent hides the topology by removing the Route-Record AVPs, how does a home-server produce the list of Source-Route AVPs which he needs to subsequently send a reverse-request? Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: 6.1.9 Relaying and Proxying Server-Initiated Requests Server-initiated messages MUST include the Source-Route AVPs, whose contents are identical to the Record-Route AVPs received in requests from the access device for the given session, but in the reverse order. 6.3 Hiding Network Topology A Relay or Proxy agent routing messages outside of their administrative domain MAY need to hide the internal Diameter topology. This is done by removing all Route-Record AVPs in a request. Another problem with removing Route-Record AVPs is that it can prevent loop detection from working properly. Requested change: Delete section 6.3. Or because this section has been here for a while, it may be safer to change 6.3 to state that an agent MUST NOT remove Route-Record AVPs. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 02:55:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02516 for ; Wed, 25 Jul 2001 02:55:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B0D6591286; Wed, 25 Jul 2001 02:55:44 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A73A91287; Wed, 25 Jul 2001 02:55:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6C5D591286 for ; Wed, 25 Jul 2001 02:55:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4E6075DDC1; Wed, 25 Jul 2001 02:57:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 365E25DD92 for ; Wed, 25 Jul 2001 02:57:40 -0400 (EDT) Received: from Interlinknetworks.com (pm552-19.dialip.mich.net [198.110.22.173]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 50DB87C for ; Wed, 25 Jul 2001 02:56:31 -0400 (EDT) Message-ID: <3B5E6D67.58E8BF37@Interlinknetworks.com> Date: Tue, 24 Jul 2001 23:55:35 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: AAA Working Group Subject: [AAA-WG]: [issue] Change Record-Route to Route-Record Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Change Record-Route to Route-Record Submitter name: David Spence Submitter email address: DSpence@Interlinknetworks.com Date first submitted: July 24, 2001 Reference: Document: Base Comment type: E Priority: 1 Section: 6.1.9 Rationale/Explanation of issue: Section 6.1.9 refers to "Record-Route AVPs". This is incorrect. Requested change: Change the text string "Record-Route" in sec. 6.1.9 to "Route-Record". -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 02:59:03 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02604 for ; Wed, 25 Jul 2001 02:59:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 33E0691287; Wed, 25 Jul 2001 02:59:00 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0387191289; Wed, 25 Jul 2001 02:58:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DD74491287 for ; Wed, 25 Jul 2001 02:58:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D0DB65DDBA; Wed, 25 Jul 2001 03:00:55 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 9030C5DD92 for ; Wed, 25 Jul 2001 03:00:55 -0400 (EDT) Received: from Interlinknetworks.com (pm552-19.dialip.mich.net [198.110.22.173]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 756B07C; Wed, 25 Jul 2001 02:59:46 -0400 (EDT) Message-ID: <3B5E6E2A.6A0E3449@Interlinknetworks.com> Date: Tue, 24 Jul 2001 23:58:50 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun , AAA Working Group Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs References: <3B5D95E2.61FC5F84@Interlinknetworks.com> <20010724092621.Q10225@charizard.diameter.org> <3B5E67C9.52A9EC55@Interlinknetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I guess it's getting too late at night. If removing Route-Record AVPs truly defeats loop-detection, then the only single solution to both problems noted in my previous message is not to allow removal of Route-Record AVPs. David Spence wrote: > > Pat Calhoun wrote: > > > > On Tue, Jul 24, 2001 at 08:36:02AM -0700, David Spence wrote: > > > If a proxy or relay agent hides the topology by removing the Route-Record > > > AVPs, how does a home-server produce the list of Source-Route > > > AVPs which he needs to subsequently send a reverse-request? > > > > I believe that some additional text will be needed in section 6.3 > > below that states that stateful proxies that hide topology MUST keep > > the Record-Route path in case it receives a server-initiated > > request. > > > > Does that work? > > I don't think so. It works for stateful proxies, though it's more trouble > to program. But sec. 6.3, below, doesn't specify that the agents removing > the Route-Record AVPs must be stateful. And indeed they need not be > stateful in order to successfully remove Route-Record AVPs from a request > and still be able to process the answers. So non-stateful agents that > remove Route-Record AVPs are still a problem. > > It occurs to me, however, that removing Route-Record AVPs causes another > problem as well. It defeats the whole purpose of Route-Record AVPs, namely, > to facilitate loop detection. If Route-Record AVPs are removed and the > message somehow loops back through an agent downstream (closer to the > client) than the one that removed the Route-Record AVPs, then that agent > cannot detect a loop. Of course, you may argue that the agent that removed > the Route-Record AVPs will detect the loop when the message gets back to > him. But that is not necessarily the case because the agent to which he > forwarded the request may also have deleted Route-Record AVPs. > > One solution to the problem, then, is to delete sec. 6.3, and not allow > agents to remove Route-Record AVPs. A better solution, to my way of > thinking, is to abandon the idea of routing server-initiated requests by > using Source-Route AVPs and go back to routing them the same way client to > server requests are routed. > > Given Bernard's request, I think I will post an issue for this problem. > > > > > PatC > > > > > > Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: > > > > > > 6.1.9 Relaying and Proxying Server-Initiated Requests > > > > > > Server-initiated messages MUST include the Source-Route AVPs, whose > > > contents are identical to the Record-Route AVPs received in requests > > > from the access device for the given session, but in the reverse > > > order. > > > > > > 6.3 Hiding Network Topology > > > > > > A Relay or Proxy agent routing messages outside of their > > > administrative domain MAY need to hide the internal Diameter > > > topology. This is done by removing all Route-Record AVPs in a > > > request. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 10:14:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24110 for ; Wed, 25 Jul 2001 10:14:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7E1991296; Wed, 25 Jul 2001 09:49:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 771B491299; Wed, 25 Jul 2001 09:49:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 280F091296 for ; Wed, 25 Jul 2001 09:49:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E4DB5DDC6; Wed, 25 Jul 2001 09:51:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2C6675DD9D for ; Wed, 25 Jul 2001 09:51:14 -0400 (EDT) Received: (qmail 3450 invoked by uid 500); 25 Jul 2001 13:38:48 -0000 Date: Wed, 25 Jul 2001 06:38:48 -0700 From: Pat Calhoun To: David Spence Cc: Pat Calhoun , AAA Working Group Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs Message-ID: <20010725063848.X10225@charizard.diameter.org> Mail-Followup-To: David Spence , Pat Calhoun , AAA Working Group References: <3B5D95E2.61FC5F84@Interlinknetworks.com> <20010724092621.Q10225@charizard.diameter.org> <3B5E67C9.52A9EC55@Interlinknetworks.com> <3B5E6E2A.6A0E3449@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5E6E2A.6A0E3449@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Tue, Jul 24, 2001 at 11:58:50PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 24, 2001 at 11:58:50PM -0700, David Spence wrote: > I guess it's getting too late at night. If removing Route-Record AVPs truly > defeats loop-detection, then the only single solution to both problems noted > in my previous message is not to allow removal of Route-Record AVPs. Do you mean to hide the path? So, removing section 6.3 would solve the problem? PatC > > David Spence wrote: > > > > Pat Calhoun wrote: > > > > > > On Tue, Jul 24, 2001 at 08:36:02AM -0700, David Spence wrote: > > > > If a proxy or relay agent hides the topology by removing the Route-Record > > > > AVPs, how does a home-server produce the list of Source-Route > > > > AVPs which he needs to subsequently send a reverse-request? > > > > > > I believe that some additional text will be needed in section 6.3 > > > below that states that stateful proxies that hide topology MUST keep > > > the Record-Route path in case it receives a server-initiated > > > request. > > > > > > Does that work? > > > > I don't think so. It works for stateful proxies, though it's more trouble > > to program. But sec. 6.3, below, doesn't specify that the agents removing > > the Route-Record AVPs must be stateful. And indeed they need not be > > stateful in order to successfully remove Route-Record AVPs from a request > > and still be able to process the answers. So non-stateful agents that > > remove Route-Record AVPs are still a problem. > > > > It occurs to me, however, that removing Route-Record AVPs causes another > > problem as well. It defeats the whole purpose of Route-Record AVPs, namely, > > to facilitate loop detection. If Route-Record AVPs are removed and the > > message somehow loops back through an agent downstream (closer to the > > client) than the one that removed the Route-Record AVPs, then that agent > > cannot detect a loop. Of course, you may argue that the agent that removed > > the Route-Record AVPs will detect the loop when the message gets back to > > him. But that is not necessarily the case because the agent to which he > > forwarded the request may also have deleted Route-Record AVPs. > > > > One solution to the problem, then, is to delete sec. 6.3, and not allow > > agents to remove Route-Record AVPs. A better solution, to my way of > > thinking, is to abandon the idea of routing server-initiated requests by > > using Source-Route AVPs and go back to routing them the same way client to > > server requests are routed. > > > > Given Bernard's request, I think I will post an issue for this problem. > > > > > > > > PatC > > > > > > > > Pertinent sections of draft-ietf-aaa-diameter-07.txt follow: > > > > > > > > 6.1.9 Relaying and Proxying Server-Initiated Requests > > > > > > > > Server-initiated messages MUST include the Source-Route AVPs, whose > > > > contents are identical to the Record-Route AVPs received in requests > > > > from the access device for the given session, but in the reverse > > > > order. > > > > > > > > 6.3 Hiding Network Topology > > > > > > > > A Relay or Proxy agent routing messages outside of their > > > > administrative domain MAY need to hide the internal Diameter > > > > topology. This is done by removing all Route-Record AVPs in a > > > > request. > > > > -- > > David Spence email: DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: +1 734 821 1203 > > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > > Ann Arbor, MI 48108 > > U.S.A. > > -- > David Spence email: DSpence@Interlinknetworks.com > Interlink Networks, Inc. phone: +1 734 821 1203 > 775 Technology Drive, Suite 200 fax: +1 734 821 1235 > Ann Arbor, MI 48108 > U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 10:26:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25159 for ; Wed, 25 Jul 2001 10:26:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7975E91212; Wed, 25 Jul 2001 10:26:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 51A1391298; Wed, 25 Jul 2001 10:26:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4536B91212 for ; Wed, 25 Jul 2001 10:26:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA9415DDA5; Wed, 25 Jul 2001 10:28:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id A6B155DD91 for ; Wed, 25 Jul 2001 10:28:45 -0400 (EDT) Received: from Interlinknetworks.com (pm552-14.dialip.mich.net [198.110.22.168]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 35D447B; Wed, 25 Jul 2001 10:27:36 -0400 (EDT) Message-ID: <3B5ED720.7F412907@Interlinknetworks.com> Date: Wed, 25 Jul 2001 07:26:40 -0700 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pat Calhoun Cc: AAA Working Group Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07 -- Source-Route AVPs References: <3B5D95E2.61FC5F84@Interlinknetworks.com> <20010724092621.Q10225@charizard.diameter.org> <3B5E67C9.52A9EC55@Interlinknetworks.com> <3B5E6E2A.6A0E3449@Interlinknetworks.com> <20010725063848.X10225@charizard.diameter.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun wrote: > > On Tue, Jul 24, 2001 at 11:58:50PM -0700, David Spence wrote: > > I guess it's getting too late at night. If removing Route-Record AVPs truly > > defeats loop-detection, then the only single solution to both problems noted > > in my previous message is not to allow removal of Route-Record AVPs. > > Do you mean to hide the path? So, removing section 6.3 would solve the > problem? >... Yes. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: +1 734 821 1203 775 Technology Drive, Suite 200 fax: +1 734 821 1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-wg@merit.edu Wed Jul 25 10:43:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26931 for ; Wed, 25 Jul 2001 10:43:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E63491298; Wed, 25 Jul 2001 10:43:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE0C391299; Wed, 25 Jul 2001 10:43:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BE07791298 for ; Wed, 25 Jul 2001 10:43:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4DC745DD9D; Wed, 25 Jul 2001 10:45:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 7394D5DD8C for ; Wed, 25 Jul 2001 10:45:41 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PEiIN11617 for ; Wed, 25 Jul 2001 16:44:18 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 25 16:44:14 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 16:44:13 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA07@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Issue 97: Proxies keeping a session-state Date: Wed, 25 Jul 2001 16:41:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: July 25, 2001 Reference: Document: Base-07 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: It seems that the Source-Route AVP is mainly used to make sure that a server-initiated request goes through the same agents as the initial auth request from the client. The reason for that is that agents might be keeping a session state, in which case they need to be aware of what is being exchanged between the client and the server. However, the way it is defined now does not let us take advantage of it, especially when the client can not even make sure that the next message it sends to the server will go through the same agents, since the load-balancing in relays could occur. I guess this should be fixed so that the client can be assured that all the requests for the given session will go through the necessary proxies that keep a session-state. Requested change: A possible way of making sure that messages go through the same agents between the different requests from the client, and also the server- initiated requests from the server, would be to support another routing AVPs called Agent-Route AVP, which would be added in the first request to the server, and returned to the client in the answer message. Then, the second request from the client would include that AVP, for making sure that the message go through that agent. The server would also have to keep that AVP for server-initiated request towards the client. By doing so, we do not need the Source-Route AVP, and can come back to a more generic way of routing request. From owner-aaa-wg@merit.edu Wed Jul 25 11:33:38 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01648 for ; Wed, 25 Jul 2001 11:33:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1624B9129F; Wed, 25 Jul 2001 11:33:40 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D1D08912A0; Wed, 25 Jul 2001 11:33:39 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B9A2F9129F for ; Wed, 25 Jul 2001 11:33:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F1F55DD9D; Wed, 25 Jul 2001 11:35:36 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id B96D65DD8C for ; Wed, 25 Jul 2001 11:35:35 -0400 (EDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id IAA03282 for ; Wed, 25 Jul 2001 08:26:54 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id IAA10971 for ; Wed, 25 Jul 2001 08:34:12 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 10:34:12 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFA0@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Pat Calhoun'" , Cain Brian-BCAIN1 Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Clarification on ABNF Command specification Date: Wed, 25 Jul 2001 10:34:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > > On Tue, Jul 24, 2001 at 05:18:58PM -0500, Cain Brian-BCAIN1 wrote: > > > > from -07, Section 3.2: > > fixed = [qual] "<" avp-spec ">" > > ; Defines the fixed position of an AVP > > > > required = [qual] "{" avp-spec "}" > > ; The AVP MUST be present > > > > optional = [qual] "[" avp-name "]" > > ; The avp-name in the 'optional' > rule cannot > > ; evaluate to any AVP Name which > is included > > ; in a fixed or required rule. > > > > Fixed AVPs are implicitly required, correct? And from > this, it appears that > > it may be legal for AVPs to appear in both the fixed and > required sections. > > Is there a logical reason for any AVP to appear in both? > > A fixed AVP is required, but has a specific location in the packet. A > required AVP must also be present, but may appear anywhere in > the packet. Anywhere, as long as it's after those fixed at the beginning, and before those fixed at the end, right? And can the same AVP appear as both a fixed and required AVP in one Command/Grouped AVP? > PatC From owner-aaa-wg@merit.edu Wed Jul 25 11:46:25 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02885 for ; Wed, 25 Jul 2001 11:46:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8BDB912A3; Wed, 25 Jul 2001 11:46:08 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 76243912A4; Wed, 25 Jul 2001 11:46:08 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 43856912A3 for ; Wed, 25 Jul 2001 11:46:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E49755DD8D; Wed, 25 Jul 2001 11:48:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 63DFE5DD8C for ; Wed, 25 Jul 2001 11:48:04 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16814; Wed, 25 Jul 2001 08:46:39 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id RAA06168; Wed, 25 Jul 2001 17:46:37 +0200 (MET DST) Message-Id: <200107251546.RAA06168@ehdb03-home.Germany.Sun.COM> Date: Wed, 25 Jul 2001 17:46:37 +0200 (MEST) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Clarification on ABNF Command specification To: pcalhoun@diameter.org, Brian.Cain@motorola.com Cc: aaa-wg@merit.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q6WddEFQ5l6pQWQ95obYAA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc Sender: owner-aaa-wg@merit.edu Precedence: bulk Brian, > > > from -07, Section 3.2: > > > fixed = [qual] "<" avp-spec ">" > > > ; Defines the fixed position of an AVP > > > > > > required = [qual] "{" avp-spec "}" > > > ; The AVP MUST be present > > > > > > optional = [qual] "[" avp-name "]" > > > ; The avp-name in the 'optional' > > rule cannot > > > ; evaluate to any AVP Name which > > is included > > > ; in a fixed or required rule. > > > > > > Fixed AVPs are implicitly required, correct? And from > > this, it appears that > > > it may be legal for AVPs to appear in both the fixed and > > required sections. > > > Is there a logical reason for any AVP to appear in both? > > > > A fixed AVP is required, but has a specific location in the packet. A > > required AVP must also be present, but may appear anywhere in > > the packet. > > Anywhere, as long as it's after those fixed at the beginning, and before > those fixed at the end, right? diameter-message = header [ *fixed] [ *required] [ *optional] [ *fixed] Right, though the required AVPs come before the optional ones according to the grammar. > And can the same AVP appear as both a fixed and required AVP in one > Command/Grouped AVP? This is not forbidden by the grammar. The only rule which limits which AVPs may appear in a command message is: optional = [qual] "[" avp-name "]" ; The avp-name in the 'optional' rule cannot ; evaluate to any AVP Name which is included ; in a fixed or required rule. This rule prevents an 'optional' AVP from overriding a rule elsewhere. For instance: ::= 1*1{Foo-AVP} *[AVP] If you sent a with two Foo-AVPs this would violate the rule above. Erik From owner-aaa-wg@merit.edu Wed Jul 25 12:06:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05084 for ; Wed, 25 Jul 2001 12:06:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA785912A7; Wed, 25 Jul 2001 12:04:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8A260912AF; Wed, 25 Jul 2001 12:04:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B7762912A7 for ; Wed, 25 Jul 2001 12:04:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6623E5DDB8; Wed, 25 Jul 2001 12:06:41 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by segue.merit.edu (Postfix) with SMTP id D73225DD9D for ; Wed, 25 Jul 2001 12:06:40 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jul 2001 16:05:15 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010725165152.00c3b8e0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jul 2001 18:04:48 +0200 To: "Martin Julien (ECE)" From: Jacques Caron Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Cc: "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA07@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, At 16:41 25/07/01, Martin Julien (ECE) wrote: >Submitter name: Martin Julien >Submitter email address: martin.julien@ericsson.com >Date first submitted: July 25, 2001 >Reference: >Document: Base-07 >Comment type: T >Priority: 1 >Section: >Rationale/Explanation of issue: > >It seems that the Source-Route AVP is mainly used to make >sure that a server-initiated request goes through the same >agents as the initial auth request from the client. The >reason for that is that agents might be keeping a session >state, in which case they need to be aware of what is being >exchanged between the client and the server. However, the >way it is defined now does not let us take advantage of it, >especially when the client can not even make sure that the >next message it sends to the server will go through the >same agents, since the load-balancing in relays could occur. >I guess this should be fixed so that the client can be >assured that all the requests for the given session will >go through the necessary proxies that keep a session-state. I had already submitted something along those lines in issue 83: - If multiple hosts listed for a given realm (redirect, relay, proxy), use the same one for a given Session (either need to maintain Session state or to use some hash function based on Session-ID) unless error occurs (and then keep that one that works). >Requested change: > >A possible way of making sure that messages go through the same agents >between the different requests from the client, and also the server- >initiated requests from the server, would be to support another routing >AVPs called Agent-Route AVP, which would be added in the first request >to the server, and returned to the client in the answer message. Then, >the second request from the client would include that AVP, for making >sure that the message go through that agent. The server would also have >to keep that AVP for server-initiated request towards the client. > >By doing so, we do not need the Source-Route AVP, and can come back to >a more generic way of routing request. Let me try to understand what you mean exactly... - first request of a session is sent without Agent-Route by client - proxies/relays add Agent-Route records along the way (same thing as Route-Record?) - server stores Agent-Route list, sends it in answer - answers are routed back using saved transaction state, with the Agent-Route AVPs unchanged - client stores Agent-Route AVPs. Then, subsequent requests from the client for the same session will have the Agent-Route AVPs, and those will be used to route the request (no need for Route-Records, then?) And unsolicited requests from the server would have the Agent-Route AVPs also (but reversed). I see two issues: - duplication of info with Route-Record - how does a proxy/relay know whether the Agent-Route AVPs are to be used for routing, or for collection of the path? I would actually change this to be this way rather: - first request of a session is sent without Agent-Route by client - proxies/relays add Route-Record AVPs along the way, as usual - server stores Route-Record list, sends it in answer (AVP to be decided) - answers are routed back using saved transaction state, with the list unchanged - client stores the list Then, nodes sending requests for the same sesion use the list (in forward or reverse order) within Source-Route AVPs, and proxies use it to proxy/relay. Of course, the usual Alternate-Proxy forwarding rules apply. So the only change is actually to send the Route-Record list back to the origin so that it can be used to source-route subsequent requests. Proxies/relays should know that Route-Records in an Answer message are not to be changed. Note that if an intermediate node fails and alternate routing is used, the new route-record set should probably be used from then on. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jul 25 12:46:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09443 for ; Wed, 25 Jul 2001 12:46:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5E829912B3; Wed, 25 Jul 2001 12:45:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38466912B7; Wed, 25 Jul 2001 12:45:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E315F912B3 for ; Wed, 25 Jul 2001 12:45:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A21BC5DDA5; Wed, 25 Jul 2001 12:47:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id CBDEE5DD8C for ; Wed, 25 Jul 2001 12:47:39 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6PGkGO29643 for ; Wed, 25 Jul 2001 18:46:17 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Jul 25 18:46:16 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 18:46:12 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA09@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Cc: "Martin Julien (ECE)" Subject: [AAA-WG]: Issue 98: Peer role in Peer table? Date: Wed, 25 Jul 2001 18:46:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Martin Julien Submitter email address: martin.julien@ericsson.com Date first submitted: July 25, 2001 Reference: Document: Base-07 Comment type: T Priority: 1 Section: Rationale/Explanation of issue: In section 5.1 of Base-07, referring to peer connections, what is the difference between opening a connection to a primary or to a secondary peer? Is that data expected to be configurable or run-time dependent? My understanding is that it was intended to be configurable by the system admin. The thing is that I do not really see what the role of primary, secondary and alternate means? It is said that a connection should be openned with all primary and secondary peers, and optionnally with alternate ones. What is the real difference between them? Shouldn't we simply say that for a particular peer, a connection should be maintain or not? In fact, my confusion comes from the fact that I am not sure if the secondary peer refers to the Alternate-Peer AVP or not? The thing is that it is not possible to say if it is a secondary or alternate peer with that Alternate-Peer AVP. Could you please tell me what were your intentions with that Peer role exactly? Also, was the Alternate-Peer also good for routing answers or not?, can it be used for upstream requests from the client to the server when using the Destination-Host AVP? Requested change: Please clarify this so that it is clear. Regards, Martin From owner-aaa-wg@merit.edu Wed Jul 25 13:02:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10911 for ; Wed, 25 Jul 2001 13:01:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5006A912AF; Wed, 25 Jul 2001 12:43:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 177E4912B3; Wed, 25 Jul 2001 12:43:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F44E912AF for ; Wed, 25 Jul 2001 12:43:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C1335DD8C; Wed, 25 Jul 2001 12:45:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 9FACB5DDC0 for ; Wed, 25 Jul 2001 12:45:06 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PGhhN18925 for ; Wed, 25 Jul 2001 18:43:44 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Wed Jul 25 18:43:38 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 18:43:38 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA08@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Jacques Caron'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state Date: Wed, 25 Jul 2001 18:43:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, > >It seems that the Source-Route AVP is mainly used to make > >sure that a server-initiated request goes through the same > >agents as the initial auth request from the client. The > >reason for that is that agents might be keeping a session > >state, in which case they need to be aware of what is being > >exchanged between the client and the server. However, the > >way it is defined now does not let us take advantage of it, > >especially when the client can not even make sure that the > >next message it sends to the server will go through the > >same agents, since the load-balancing in relays could occur. > >I guess this should be fixed so that the client can be > >assured that all the requests for the given session will > >go through the necessary proxies that keep a session-state. > > I had already submitted something along those lines in issue 83: > - If multiple hosts listed for a given realm (redirect, > relay, proxy), use > the same one for a given Session (either need to maintain > Session state or > to use some hash function based on Session-ID) unless error > occurs (and > then keep that one that works). That is very interesting. Maybe something along those lines should be mentionned in the draft, especially with regards to selecting a consistent next-hop peer based on hashing of the session-id. I'd like to see that in the draft, since it would fix that problem. > >Requested change: > > > >A possible way of making sure that messages go through the > same agents > >between the different requests from the client, and also the server- > >initiated requests from the server, would be to support > another routing > >AVPs called Agent-Route AVP, which would be added in the > first request > >to the server, and returned to the client in the answer > message. Then, > >the second request from the client would include that AVP, for making > >sure that the message go through that agent. The server > would also have > >to keep that AVP for server-initiated request towards the client. > > > >By doing so, we do not need the Source-Route AVP, and can > come back to > >a more generic way of routing request. > > Let me try to understand what you mean exactly... > - first request of a session is sent without Agent-Route by client > - proxies/relays add Agent-Route records along the way (same thing as > Route-Record?) > - server stores Agent-Route list, sends it in answer > - answers are routed back using saved transaction state, with the > Agent-Route AVPs unchanged > - client stores Agent-Route AVPs. No, my intention was to add the Agent-Route AVP only for the proxies that need to keep a session-state. If a proxy or a relay does not keep a session-state, then no Agent-Route AVP should be added. In fact, I was thinking of using that AVP in the routing as the first routing option for request messages, followed by the Destination-Host check, and then the Destination-Realm one. However, your previous solution is much simpler to implement, and still provide some kind of load-balancing. > Then, subsequent requests from the client for the same > session will have > the Agent-Route AVPs, and those will be used to route the > request (no need > for Route-Records, then?) > And unsolicited requests from the server would have the > Agent-Route AVPs > also (but reversed). > > I see two issues: > - duplication of info with Route-Record > - how does a proxy/relay know whether the Agent-Route AVPs > are to be used > for routing, or for collection of the path? > > I would actually change this to be this way rather: > - first request of a session is sent without Agent-Route by client > - proxies/relays add Route-Record AVPs along the way, as usual > - server stores Route-Record list, sends it in answer (AVP to > be decided) > - answers are routed back using saved transaction state, with > the list > unchanged > - client stores the list > > Then, nodes sending requests for the same sesion use the list > (in forward > or reverse order) within Source-Route AVPs, and proxies use it to > proxy/relay. Of course, the usual Alternate-Proxy forwarding > rules apply. > > So the only change is actually to send the Route-Record list > back to the > origin so that it can be used to source-route subsequent requests. > Proxies/relays should know that Route-Records in an Answer > message are not > to be changed. > > Note that if an intermediate node fails and alternate routing > is used, the > new route-record set should probably be used from then on. Interesting, but still more complex than your previous suggestion. Martin > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Wed Jul 25 13:07:23 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11539 for ; Wed, 25 Jul 2001 13:07:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 27DE0912EA; Wed, 25 Jul 2001 13:04:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E76DF912B2; Wed, 25 Jul 2001 13:04:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6316D912EA for ; Wed, 25 Jul 2001 13:04:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2AE795DD9D; Wed, 25 Jul 2001 13:06:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by segue.merit.edu (Postfix) with SMTP id CED835DD8C for ; Wed, 25 Jul 2001 13:06:00 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jul 2001 17:04:37 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010725184743.00c4f9a0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jul 2001 19:03:41 +0200 To: "Martin Julien (ECE)" From: Jacques Caron Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" , "Martin Julien (ECE)" In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA08@eestqnt104.es.eu. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:43 25/07/01, Martin Julien (ECE) wrote: > > I had already submitted something along those lines in issue 83: > > - If multiple hosts listed for a given realm (redirect, > > relay, proxy), use > > the same one for a given Session (either need to maintain > > Session state or > > to use some hash function based on Session-ID) unless error > > occurs (and > > then keep that one that works). > >That is very interesting. Maybe something along those lines >should be mentionned in the draft, especially with regards >to selecting a consistent next-hop peer based on hashing of >the session-id. I'd like to see that in the draft, since it >would fix that problem. There's actually an issue, which is that if the set of peers that can serve a request change (one goes down, a new one is added...), then obviously the hashing changes, and requests might get sent to another peer. There must be some clever way to handle that, though, if I scratch my head a bit more :-) > > Let me try to understand what you mean exactly... > > - first request of a session is sent without Agent-Route by client > > - proxies/relays add Agent-Route records along the way (same thing as > > Route-Record?) > > - server stores Agent-Route list, sends it in answer > > - answers are routed back using saved transaction state, with the > > Agent-Route AVPs unchanged > > - client stores Agent-Route AVPs. > >No, my intention was to add the Agent-Route AVP only for the >proxies that need to keep a session-state. If a proxy or a >relay does not keep a session-state, then no Agent-Route AVP >should be added. Mmmm... This might not work. Imagine you have this: Client----Relay 1-------Relay 2------Proxy A------Relay 3-----Server | | +-----------Relay 4------Proxy B------Relay 5-------+ [stupid setup, but just for the example]. If only Proxy A says "please pick me rather than another proxy" (i.e. Proxy B), Relay 1 doesn't know that this means "go through Relay 2 rather than Relay 4". However, it looks a bit like one of the suggestions I had on the routing of unsolicited requests: >When a client sends a request to a server, it includes information on how >to establish a direct connection back (certificate...). >If at some point there is a breach in IP reachability, the proxy/relay >that acts as a gateway between the two routing domains includes an AVP >stating that unsolicited requests should go to it rather than to the >Origin-Host directly (possibly including certificate info of its own), and >it will send it to the client. This can possibly happen multiple times, of >course. It can also be used if a proxy wants to check/modify any request >that is sent to a client. The AVP might contain multiple DiameterIdenties >to provide redundancy. >If the request causes a change in the state of the session, the client >MUST send a regular request back to the server to update state in stateful >proxies (unless all these proxies add the "get it through me" AVP, which >might actually be the best solution). This actually means that you "bypass" some of the intermediate relays to go directly to the "significant" hops. Probably not a good idea. >However, your previous solution is much simpler to implement, >and still provide some kind of load-balancing. Well, in any case, load balancing occurs on the initial request in a session, and then subsequent requests should follow the same path (a bit like per-destination load balancing vs per-packet load-balancing on routers). And there is the issue above with "my solution". I think the solution below might actually be the simplest: >So the only change is actually to send the Route-Record list back to the >origin so that it can be used to source-route subsequent requests. >Proxies/relays should know that Route-Records in an Answer message are not >to be changed. It draws on the already-existing Route-Record & Source-route mechanism (with Alternates etc.) and requires just two changes: - server returns the full list of Route-Records in answer [it already saves it for unsolicited requests] - client saves it for future requests. Of course, the list from Route-Record AVPs are to be inserted as Source-Route AVPs in different orders depending on who is sending the request (client or server). Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jul 25 13:30:14 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14149 for ; Wed, 25 Jul 2001 13:30:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BDBBA91300; Wed, 25 Jul 2001 13:10:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 84B35912D2; Wed, 25 Jul 2001 13:10:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F16C8912B8 for ; Wed, 25 Jul 2001 13:10:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B51235DDB8; Wed, 25 Jul 2001 13:12:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 923175DD8C for ; Wed, 25 Jul 2001 13:12:13 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA15399 for ; Wed, 25 Jul 2001 10:10:51 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id KAA16971 for ; Wed, 25 Jul 2001 10:10:50 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19) id <3XDBYKGH>; Wed, 25 Jul 2001 12:10:50 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFA2@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Erik Guttman'" , pcalhoun@diameter.org, Cain Brian-BCAIN1 Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Clarification on ABNF Command specification Date: Wed, 25 Jul 2001 12:10:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] ... > Right, though the required AVPs come before the optional ones > according > to the grammar. Okay, what about an AVP that shows up in required with, e.g. 0 as minimum occurrences, and 5 as its maximum. Now, this AVP can show up any place in the required section, but must all of its occurrences be contiguous, or can they be scattered throughout the required AVPs? Command format: < A > 0*5 { B } { Q } An Actual instance of the given Command: A B B B Q B This would be valid, or invalid, given the format above? I think the text "The AVP MUST be present" is slightly ambiguous. Perhaps "All occurrences of the AVP MUST be present in one contiguous block" or "The occurrences of this AVP MUST show up anywhere within the required section, potentially non-contiguously", depending on the answer. Okay, that doesn't quite flow that well, but someone could come up with an equivalent, I imagine. -Brian From owner-aaa-wg@merit.edu Wed Jul 25 13:39:06 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15275 for ; Wed, 25 Jul 2001 13:39:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7B324912B6; Wed, 25 Jul 2001 13:39:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48D91912B7; Wed, 25 Jul 2001 13:39:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C4CD912B6 for ; Wed, 25 Jul 2001 13:39:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBEC45DD8D; Wed, 25 Jul 2001 13:41:00 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp013.mail.yahoo.com (smtp013.mail.yahoo.com [216.136.173.57]) by segue.merit.edu (Postfix) with SMTP id 7DDA45DD8C for ; Wed, 25 Jul 2001 13:41:00 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 25 Jul 2001 17:39:37 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010725192612.00cabd60@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jul 2001 19:35:43 +0200 To: Cain Brian-BCAIN1 From: Jacques Caron Subject: RE: [AAA-WG]: Clarification on ABNF Command specification Cc: "'Erik Guttman'" , pcalhoun@diameter.org, aaa-wg@merit.edu In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECFA2@IL27EXM10.cig.mot.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, A stupid suggestion: what about just putting AVPs in ascending numerical order, and assigning AVP codes in different ranges (e.g. 0x10000-0x1ffff for AVPs that must be at the beginning, 0x20000-0xfeffff for those anywhere in between, and 0xff0000-0xffffff for those that must be at the end)? Of course, there's the issue of Radius codes [though they could be remapped to somewhere else than the 0-255 range, by prepending them with some known prefix], and of Vendor-specific AVP codes. And also some AVPs might be fixed in some commands and not in others [though I guess those that must be at the start or at the end are presumably protocol-related rather than application-related?]. And honestly I'm less and less convinced about the whole ABNF thing. I would at least separate all the protocol-related AVPs (e.g. Route-Record, Source-Route...) from the command-code specific AVPs in some way. See also my comment about the additional accounting-application-specific AVPs in the same accounting messages as per 2.6 in a previous post... Jacques. At 19:10 25/07/01, Cain Brian-BCAIN1 wrote: > > -----Original Message----- > > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] >... > > Right, though the required AVPs come before the optional ones > > according > > to the grammar. > >Okay, what about an AVP that shows up in required with, e.g. 0 as minimum >occurrences, and 5 as its maximum. Now, this AVP can show up any place in >the required section, but must all of its occurrences be contiguous, or >can they be scattered throughout the required AVPs? > >Command format: > > < A > > 0*5 { B } > { Q } > >An Actual instance of the given Command: > >A >B >B >B >Q >B > >This would be valid, or invalid, given the format above? > >I think the text "The AVP MUST be present" is slightly ambiguous. Perhaps >"All occurrences of the AVP MUST be present in one contiguous block" or >"The occurrences of this AVP MUST show up anywhere within the required >section, potentially non-contiguously", depending on the answer. Okay, >that doesn't quite flow that well, but someone could come up with an >equivalent, I imagine. > >-Brian _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Wed Jul 25 15:30:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26815 for ; Wed, 25 Jul 2001 15:29:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 68196912CA; Wed, 25 Jul 2001 15:23:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 23129912CC; Wed, 25 Jul 2001 15:23:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 58779912CA for ; Wed, 25 Jul 2001 15:23:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4C86C5DD8D; Wed, 25 Jul 2001 15:25:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id E90DB5DD8C for ; Wed, 25 Jul 2001 15:25:04 -0400 (EDT) Received: (qmail 5766 invoked by uid 500); 25 Jul 2001 19:12:41 -0000 Date: Wed, 25 Jul 2001 12:12:41 -0700 From: Pat Calhoun To: Cain Brian-BCAIN1 Cc: "'Erik Guttman'" , pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Clarification on ABNF Command specification Message-ID: <20010725121241.N10225@charizard.diameter.org> Mail-Followup-To: Cain Brian-BCAIN1 , 'Erik Guttman' , pcalhoun@diameter.org, aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECFA2@IL27EXM10.cig.mot.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0ECFA2@IL27EXM10.cig.mot.com>; from Brian.Cain@motorola.com on Wed, Jul 25, 2001 at 12:10:49PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 25, 2001 at 12:10:49PM -0500, Cain Brian-BCAIN1 wrote: > > > -----Original Message----- > > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] > ... > > Right, though the required AVPs come before the optional ones > > according > > to the grammar. > > Okay, what about an AVP that shows up in required with, e.g. 0 as minimum occurrences, and 5 as its maximum. Now, this AVP can show up any place in the required section, but must all of its occurrences be contiguous, or can they be scattered throughout the required AVPs? > > Command format: > > < A > > 0*5 { B } > { Q } > > An Actual instance of the given Command: > > A > B > B > B > Q > B > > This would be valid, or invalid, given the format above? valid, given the above. The following, however, would be invalid Q A B B > I think the text "The AVP MUST be present" is slightly ambiguous. Perhaps "All occurrences of the AVP MUST be present in one contiguous block" or "The occurrences of this AVP MUST show up anywhere within the required section, potentially non-contiguously", depending on the answer. Okay, that doesn't quite flow that well, but someone could come up with an equivalent, I imagine. They don't have to be present in a contiguous block, and nowhere have we stated this. The only AVPs that have strict ordering are the ones with < >. All other AVPs may be present anywhere in a message. PatC From owner-aaa-wg@merit.edu Wed Jul 25 15:30:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26960 for ; Wed, 25 Jul 2001 15:30:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2AE64912C0; Wed, 25 Jul 2001 15:26:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EC6EF912C4; Wed, 25 Jul 2001 15:26:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C22DA912C0 for ; Wed, 25 Jul 2001 15:26:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B71EA5DD8D; Wed, 25 Jul 2001 15:28:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 1A8585DD8C for ; Wed, 25 Jul 2001 15:28:07 -0400 (EDT) Received: (qmail 5792 invoked by uid 500); 25 Jul 2001 19:15:44 -0000 Date: Wed, 25 Jul 2001 12:15:44 -0700 From: Pat Calhoun To: Jacques Caron Cc: Cain Brian-BCAIN1 , "'Erik Guttman'" , pcalhoun@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Clarification on ABNF Command specification Message-ID: <20010725121543.O10225@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Cain Brian-BCAIN1 , 'Erik Guttman' , pcalhoun@diameter.org, aaa-wg@merit.edu References: <35DBB8B7AC89D4118E98009027B1009B0ECFA2@IL27EXM10.cig.mot.c om> <4.3.2.7.2.20010725192612.00cabd60@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010725192612.00cabd60@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Wed, Jul 25, 2001 at 07:35:43PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 25, 2001 at 07:35:43PM +0200, Jacques Caron wrote: > Hi, > > A stupid suggestion: what about just putting AVPs in ascending numerical > order, and assigning AVP codes in different ranges (e.g. 0x10000-0x1ffff > for AVPs that must be at the beginning, 0x20000-0xfeffff for those anywhere > in between, and 0xff0000-0xffffff for those that must be at the end)? > > Of course, there's the issue of Radius codes [though they could be remapped > to somewhere else than the 0-255 range, by prepending them with some known > prefix], and of Vendor-specific AVP codes. Why has ordering now become important? We decided a long time ago (WG consensus, btw) that ordering was not important, with the exception of the AVPs in < >. > And also some AVPs might be fixed in some commands and not in others > [though I guess those that must be at the start or at the end are > presumably protocol-related rather than application-related?]. The ONLY AVP that I know of that we require to have any ordering is the Session-Id. This is merely for convenience to speed up the lookup process of the session control block. We could have gotten rid of it some time back, but didn't. > And honestly I'm less and less convinced about the whole ABNF thing. I > would at least separate all the protocol-related AVPs (e.g. Route-Record, > Source-Route...) from the command-code specific AVPs in some way. See also > my comment about the additional accounting-application-specific AVPs in the > same accounting messages as per 2.6 in a previous post... well, I have personally never seen WG consensus on this particular change request, nor an issue. I also must admit that re-architecting the specs for mere convenience is probably something that should have been done prior to the imminent WG last call :( PatC From owner-aaa-wg@merit.edu Wed Jul 25 15:32:41 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27236 for ; Wed, 25 Jul 2001 15:32:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 44937912C4; Wed, 25 Jul 2001 15:31:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FF03912C8; Wed, 25 Jul 2001 15:31:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9C43A912C4 for ; Wed, 25 Jul 2001 15:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B6C8D5DD91; Wed, 25 Jul 2001 15:33:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by segue.merit.edu (Postfix) with ESMTP id 69CA65DD9D for ; Wed, 25 Jul 2001 15:33:24 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA06784 for ; Wed, 25 Jul 2001 12:24:42 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id MAA22539 for ; Wed, 25 Jul 2001 12:24:35 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 14:32:01 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFA3@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Jacques Caron'" Cc: pcalhoun@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Clarification on ABNF Command specification Date: Wed, 25 Jul 2001 14:31:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Jacques Caron [mailto:jacques_m_caron@yahoo.com] > Subject: RE: [AAA-WG]: Clarification on ABNF Command specification > ... > And also some AVPs might be fixed in some commands and not in others > [though I guess those that must be at the start or at the end are > presumably protocol-related rather than application-related?]. Well, I think this kinda puts a nail in the coffin of your idea. I think it's best not to associate any particular AVP with the format of the command/grouped AVP it could/might/should be contained in. > And honestly I'm less and less convinced about the whole ABNF > thing. I > would at least separate all the protocol-related AVPs (e.g. > Route-Record, > Source-Route...) from the command-code specific AVPs in some > way. See also > my comment about the additional > accounting-application-specific AVPs in the > same accounting messages as per 2.6 in a previous post... I think I'd appreciate a division between protocol-impacting and non-protocol impacting AVPs. But, I'm content to go with it the way it is now. From Pat: >well, I have personally never seen WG consensus on this particular change >request, nor an issue. I also must admit that re-architecting the specs >for mere convenience is probably something that should have been done prior >to the imminent WG last call :( True. In order to prevent further delays, it may be best to let sleeping dogs lie on this one. -Brian From owner-aaa-wg@merit.edu Wed Jul 25 15:53:35 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29867 for ; Wed, 25 Jul 2001 15:53:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A57F5912CC; Wed, 25 Jul 2001 15:53:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77190912CB; Wed, 25 Jul 2001 15:53:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C37E8912CD for ; Wed, 25 Jul 2001 15:52:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B61B45DD91; Wed, 25 Jul 2001 15:54:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by segue.merit.edu (Postfix) with ESMTP id 676FE5DD8D for ; Wed, 25 Jul 2001 15:54:30 -0400 (EDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PJriI24111 for ; Wed, 25 Jul 2001 14:53:54 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 14:52:56 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: Issue 99: New AVPs to NASREQ for Basic/Digest support Date: Wed, 25 Jul 2001 14:51:52 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Issue 99: New AVPs to NASREQ for Basic/Digest support X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEVQ5jD3NrG3IZqRXu/tflAnTJzRw== From: "Sengodan Senthil (NRC/Boston)" To: , , "ext Bernard Aboba" , Cc: "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA29867 Submitter name: Srinivas, Chan, Sengodan, Costa-Requena Submitter email address: bindignavile.srinivas@nokia.com, tat.chan@nokia.com, senthil.sengodan@nokia.com, jose.costa-requena@nokia.com Date first submitted: July 25, 2001 Reference: http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t xt Document: Document Requiring change: nasreq Comment type: 'T'echnical Priority: '1' Section: 3.1 and Introducing New Section 4.0 Rationale/Explanation of issue: Three new AVPs are introduced in NASREQ in order to support Basic/Digest authentication. Detailed description is found in the individual draft submission http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t xt. Proposal: Section 3.1.1: Paragraph added before Message Format to read: "The Resource and Response AVPs (defined in Section 4.0) MAY be present in the AA-Request message when Basic or Digest authentication is to be used." Section 3.1.1: AAR Command modified to include [ Resource ] and [ Response ] AVPs. Section 3.1.2: Paragraph added before Message Format to read: "The Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer message when Basic or Digest authentication is to be used." Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs. Section 4.0 is introduced and includes the following text (while original Section 4.0 changes to 5.0 and so on): 4.0 Basic/Digest Authentication Support The Basic and Digest authentication schemes, described in [X], are two well-known authentication methods. This section describes the AVPs that are required for Basic/Digest authentication support within the Diameter protocol. As seen in Section 3.0, the Resource AVP and Response AVP MAY be used within the AA-Request Command, while the Challenge AVP MAY be uesd within the AA-Answer Command. 4.1 Resource AVP The Resource AVP (AVP Code xxx) is of type OctetString and is used to convey a resource. It MAY be used by a DIAMETER client to convey to the DIAMETER server the resource whose access needs authorization. 4.2 Challenge AVP The Challenge AVP (AVP Code xxx) is of type OctetString and is used to convey a challenge. It MAY be used by a DIAMETER server to convey a challenge to the DIAMETER client. 4.3 Response AVP The Response AVP (AVP Code xxx) is of type OctetString and is used to convey a response. It MAY be used by a DIAMETER client to convey a response to the DIAMETER server. Comments/Discussion (not part of proposed text): No separate command code has been proposed for Basic/Digest authentication, and the AAR and AAA commands have been modified to support the proposed AVPs. This implies that when a DIAMETER server receives an AAR command from a DIAMETER client, it cannot determine whether the authentication/authorization schemes are RADIUS based or Basic/Digest based just by looking at the command code. Instead, the AVPs have to be parsed to determine this. If this is seen as an issue, then a new command code may have to be introduced for the purpose of Basic/Digest authentication support. This would then be along the lines of a new command code being introduced for the purpose of EAP authentication support. From owner-aaa-wg@merit.edu Wed Jul 25 16:05:39 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01385 for ; Wed, 25 Jul 2001 16:05:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E07A912CE; Wed, 25 Jul 2001 16:05:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2E4D912CF; Wed, 25 Jul 2001 16:05:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E39A912D0 for ; Wed, 25 Jul 2001 16:05:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7B5A75DDB7; Wed, 25 Jul 2001 16:07:17 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 224425DDAF for ; Wed, 25 Jul 2001 16:07:16 -0400 (EDT) Received: (qmail 6534 invoked by uid 500); 25 Jul 2001 19:54:52 -0000 Date: Wed, 25 Jul 2001 12:54:52 -0700 From: Pat Calhoun To: "Sengodan Senthil (NRC/Boston)" Cc: aaa-wg@merit.edu, pcalhoun@diameter.org, ext Bernard Aboba , david@mitton.com, "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" Subject: [AAA-WG]: Re: Issue 99: New AVPs to NASREQ for Basic/Digest support Message-ID: <20010725125452.A6433@charizard.diameter.org> Mail-Followup-To: "Sengodan Senthil (NRC/Boston)" , aaa-wg@merit.edu, pcalhoun@diameter.org, ext Bernard Aboba , david@mitton.com, "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from senthil.sengodan@nokia.com on Wed, Jul 25, 2001 at 02:51:52PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Given where we are in the standardization process, I would prefer that we not add new features to the specifications. I believe that fixes to bugs in the current specs is acceptable, though. Having said that, I believe that the proposal to support Basic/Digest support is very important. However, I believe that it would be preferable to create a new Diameter application, and not require any changes to the NASREQ extension. So, personally, I'd prefer to reject this issue, and require a new I-D (which I believe already exists). Thanks, PatC On Wed, Jul 25, 2001 at 02:51:52PM -0500, Sengodan Senthil (NRC/Boston) wrote: > Submitter name: Srinivas, Chan, Sengodan, Costa-Requena > Submitter email address: bindignavile.srinivas@nokia.com, > tat.chan@nokia.com, senthil.sengodan@nokia.com, > jose.costa-requena@nokia.com > Date first submitted: July 25, 2001 > Reference: > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > xt > Document: Document Requiring change: nasreq > Comment type: 'T'echnical > Priority: '1' > Section: 3.1 and Introducing New Section 4.0 > Rationale/Explanation of issue: Three new AVPs are introduced in NASREQ > in order to support Basic/Digest authentication. Detailed description is > found in the individual draft submission > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > xt. > > Proposal: > Section 3.1.1: Paragraph added before Message Format to read: "The > Resource and Response AVPs (defined in Section 4.0) MAY be present in > the AA-Request message when Basic or Digest authentication is to be > used." > Section 3.1.1: AAR Command modified to include [ Resource ] and [ > Response ] AVPs. > Section 3.1.2: Paragraph added before Message Format to read: "The > Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer > message when Basic or Digest authentication is to be used." > Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs. > Section 4.0 is introduced and includes the following text (while > original Section 4.0 changes to 5.0 and so on): > 4.0 Basic/Digest Authentication Support > The Basic and Digest authentication schemes, described in [X], are two > well-known authentication methods. This section describes the AVPs that > are required for Basic/Digest authentication support within the Diameter > protocol. As seen in Section 3.0, the Resource AVP and Response AVP MAY > be used within the AA-Request Command, while the Challenge AVP MAY be > uesd within the AA-Answer Command. > 4.1 Resource AVP > The Resource AVP (AVP Code xxx) is of type OctetString and is used to > convey a resource. It MAY be used by a DIAMETER client to convey to the > DIAMETER server the resource whose access needs authorization. > 4.2 Challenge AVP > The Challenge AVP (AVP Code xxx) is of type OctetString and is used to > convey a challenge. It MAY be used by a DIAMETER server to convey a > challenge to the DIAMETER client. > 4.3 Response AVP > The Response AVP (AVP Code xxx) is of type OctetString and is used to > convey a response. It MAY be used by a DIAMETER client to convey a > response to the DIAMETER server. > > Comments/Discussion (not part of proposed text): > No separate command code has been proposed for Basic/Digest > authentication, and the AAR and AAA commands have been modified to > support the proposed AVPs. This implies that when a DIAMETER server > receives an AAR command from a DIAMETER client, it cannot determine > whether the authentication/authorization schemes are RADIUS based or > Basic/Digest based just by looking at the command code. Instead, the > AVPs have to be parsed to determine this. If this is seen as an issue, > then a new command code may have to be introduced for the purpose of > Basic/Digest authentication support. This would then be along the lines > of a new command code being introduced for the purpose of EAP > authentication support. > From owner-aaa-wg@merit.edu Wed Jul 25 16:17:27 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02919 for ; Wed, 25 Jul 2001 16:17:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CAB6E912CD; Wed, 25 Jul 2001 16:09:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 96231912CF; Wed, 25 Jul 2001 16:09:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8226A912CD for ; Wed, 25 Jul 2001 16:09:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 867C05DDB7; Wed, 25 Jul 2001 16:11:14 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 421CE5DDAF for ; Wed, 25 Jul 2001 16:11:14 -0400 (EDT) Received: (qmail 6608 invoked by uid 500); 25 Jul 2001 19:58:51 -0000 Date: Wed, 25 Jul 2001 12:58:51 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: A warning on my sun e-mail account Message-ID: <20010725125851.B6433@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, Folks occasionally send me e-mail to my Sun account. This is to request that people refrain from doing so, since it will be disabled on (or around) 8/3. Please continue using my diameter.org account. Back to your regularly scheduled program, PatC From owner-aaa-wg@merit.edu Wed Jul 25 16:24:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03585 for ; Wed, 25 Jul 2001 16:24:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64BF4912D0; Wed, 25 Jul 2001 16:24:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 38430912D2; Wed, 25 Jul 2001 16:24:57 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 07E15912D0 for ; Wed, 25 Jul 2001 16:24:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 00DC35DDC7; Wed, 25 Jul 2001 16:26:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by segue.merit.edu (Postfix) with ESMTP id 608A45DDC3 for ; Wed, 25 Jul 2001 16:26:53 -0400 (EDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6PKPXi28087 for ; Wed, 25 Jul 2001 15:25:33 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Wed, 25 Jul 2001 15:25:16 -0500 content-class: urn:content-classes:message Subject: [AAA-WG]: RE: Issue 99: New AVPs to NASREQ for Basic/Digest support Date: Wed, 25 Jul 2001 15:24:10 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Issue 99: New AVPs to NASREQ for Basic/Digest support X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcEVRTfluNPi4oE1EdWBSQBQi2X+DwAAgWMw From: "Sengodan Senthil (NRC/Boston)" To: "ext Pat Calhoun" Cc: , "ext Bernard Aboba" , , "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA03585 Pat, Sounds good. We could modify the individual I-D submission to reflect a new Diameter application. When do you foresee this as becoming a WG item? - Senthil > -----Original Message----- > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Wednesday, July 25, 2001 3:55 PM > To: Sengodan Senthil (NRC/Boston) > Cc: aaa-wg@merit.edu; pcalhoun@diameter.org; ext Bernard Aboba; > david@mitton.com; Chan Tat (NRC/Boston); Srinivas Bindignavile > (NRC/Boston); Costa-Requena Jose (NMP/Helsinki) > Subject: Re: Issue 99: New AVPs to NASREQ for Basic/Digest support > > > Given where we are in the standardization process, I would prefer that > we not add new features to the specifications. I believe that fixes > to bugs in the current specs is acceptable, though. > > Having said that, I believe that the proposal to support Basic/Digest > support is very important. However, I believe that it would > be preferable > to create a new Diameter application, and not require any > changes to the > NASREQ extension. > > So, personally, I'd prefer to reject this issue, and require a new > I-D (which I believe already exists). > > Thanks, > > PatC > On Wed, Jul 25, 2001 at 02:51:52PM -0500, Sengodan Senthil > (NRC/Boston) wrote: > > Submitter name: Srinivas, Chan, Sengodan, Costa-Requena > > Submitter email address: bindignavile.srinivas@nokia.com, > > tat.chan@nokia.com, senthil.sengodan@nokia.com, > > jose.costa-requena@nokia.com > > Date first submitted: July 25, 2001 > > Reference: > > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > xt > Document: Document Requiring change: nasreq > Comment type: 'T'echnical > Priority: '1' > Section: 3.1 and Introducing New Section 4.0 > Rationale/Explanation of issue: Three new AVPs are introduced in NASREQ > in order to support Basic/Digest authentication. Detailed description is > found in the individual draft submission > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > xt. > > Proposal: > Section 3.1.1: Paragraph added before Message Format to read: "The > Resource and Response AVPs (defined in Section 4.0) MAY be present in > the AA-Request message when Basic or Digest authentication is to be > used." > Section 3.1.1: AAR Command modified to include [ Resource ] and [ > Response ] AVPs. > Section 3.1.2: Paragraph added before Message Format to read: "The > Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer > message when Basic or Digest authentication is to be used." > Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs. > Section 4.0 is introduced and includes the following text (while > original Section 4.0 changes to 5.0 and so on): > 4.0 Basic/Digest Authentication Support > The Basic and Digest authentication schemes, described in [X], are two > well-known authentication methods. This section describes the AVPs that > are required for Basic/Digest authentication support within the Diameter > protocol. As seen in Section 3.0, the Resource AVP and Response AVP MAY > be used within the AA-Request Command, while the Challenge AVP MAY be > uesd within the AA-Answer Command. > 4.1 Resource AVP > The Resource AVP (AVP Code xxx) is of type OctetString and is used to > convey a resource. It MAY be used by a DIAMETER client to convey to the > DIAMETER server the resource whose access needs authorization. > 4.2 Challenge AVP > The Challenge AVP (AVP Code xxx) is of type OctetString and is used to > convey a challenge. It MAY be used by a DIAMETER server to convey a > challenge to the DIAMETER client. > 4.3 Response AVP > The Response AVP (AVP Code xxx) is of type OctetString and is used to > convey a response. It MAY be used by a DIAMETER client to convey a > response to the DIAMETER server. > > Comments/Discussion (not part of proposed text): > No separate command code has been proposed for Basic/Digest > authentication, and the AAR and AAA commands have been modified to > support the proposed AVPs. This implies that when a DIAMETER server > receives an AAR command from a DIAMETER client, it cannot determine > whether the authentication/authorization schemes are RADIUS based or > Basic/Digest based just by looking at the command code. Instead, the > AVPs have to be parsed to determine this. If this is seen as an issue, > then a new command code may have to be introduced for the purpose of > Basic/Digest authentication support. This would then be along the lines > of a new command code being introduced for the purpose of EAP > authentication support. > From owner-aaa-wg@merit.edu Wed Jul 25 16:31:31 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04275 for ; Wed, 25 Jul 2001 16:31:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5FDC912D3; Wed, 25 Jul 2001 16:31:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 890CA912D5; Wed, 25 Jul 2001 16:31:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0B8DF912D3 for ; Wed, 25 Jul 2001 16:31:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A0AE5DDC7; Wed, 25 Jul 2001 16:33:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 638315DDC6 for ; Wed, 25 Jul 2001 16:33:10 -0400 (EDT) Received: (qmail 6971 invoked by uid 500); 25 Jul 2001 20:20:46 -0000 Date: Wed, 25 Jul 2001 13:20:46 -0700 From: Pat Calhoun To: "Sengodan Senthil (NRC/Boston)" Cc: ext Pat Calhoun , aaa-wg@merit.edu, ext Bernard Aboba , david@mitton.com, "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" Subject: Re: [AAA-WG]: RE: Issue 99: New AVPs to NASREQ for Basic/Digest support Message-ID: <20010725132046.D6433@charizard.diameter.org> Mail-Followup-To: "Sengodan Senthil (NRC/Boston)" , ext Pat Calhoun , aaa-wg@merit.edu, ext Bernard Aboba , david@mitton.com, "Chan Tat (NRC/Boston)" , "Srinivas Bindignavile (NRC/Boston)" , "Costa-Requena Jose (NMP/Helsinki)" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from senthil.sengodan@nokia.com on Wed, Jul 25, 2001 at 03:24:10PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 25, 2001 at 03:24:10PM -0500, Sengodan Senthil (NRC/Boston) wrote: > Pat, > > Sounds good. We could modify the individual I-D submission to reflect a > new Diameter application. That would be the best approach. > When do you foresee this as becoming a WG > item? That is a question for the chairs to answer. PatC > > - Senthil > > > -----Original Message----- > > From: ext Pat Calhoun [mailto:pcalhoun@diameter.org] > > Sent: Wednesday, July 25, 2001 3:55 PM > > To: Sengodan Senthil (NRC/Boston) > > Cc: aaa-wg@merit.edu; pcalhoun@diameter.org; ext Bernard Aboba; > > david@mitton.com; Chan Tat (NRC/Boston); Srinivas Bindignavile > > (NRC/Boston); Costa-Requena Jose (NMP/Helsinki) > > Subject: Re: Issue 99: New AVPs to NASREQ for Basic/Digest support > > > > > > Given where we are in the standardization process, I would prefer that > > we not add new features to the specifications. I believe that fixes > > to bugs in the current specs is acceptable, though. > > > > Having said that, I believe that the proposal to support Basic/Digest > > support is very important. However, I believe that it would > > be preferable > > to create a new Diameter application, and not require any > > changes to the > > NASREQ extension. > > > > So, personally, I'd prefer to reject this issue, and require a new > > I-D (which I believe already exists). > > > > Thanks, > > > > PatC > > On Wed, Jul 25, 2001 at 02:51:52PM -0500, Sengodan Senthil > > (NRC/Boston) wrote: > > > Submitter name: Srinivas, Chan, Sengodan, Costa-Requena > > > Submitter email address: bindignavile.srinivas@nokia.com, > > > tat.chan@nokia.com, senthil.sengodan@nokia.com, > > > jose.costa-requena@nokia.com > > > Date first submitted: July 25, 2001 > > > Reference: > > > > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > > xt > > Document: Document Requiring change: nasreq > > Comment type: 'T'echnical > > Priority: '1' > > Section: 3.1 and Introducing New Section 4.0 > > Rationale/Explanation of issue: Three new AVPs are introduced in > NASREQ > > in order to support Basic/Digest authentication. Detailed description > is > > found in the individual draft submission > > > http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.t > > xt. > > > > Proposal: > > Section 3.1.1: Paragraph added before Message Format to read: "The > > Resource and Response AVPs (defined in Section 4.0) MAY be present in > > the AA-Request message when Basic or Digest authentication is to be > > used." > > Section 3.1.1: AAR Command modified to include [ Resource ] and [ > > Response ] AVPs. > > Section 3.1.2: Paragraph added before Message Format to read: "The > > Challenge AVP (defined in Section 4.0) MAY be present in the AA-Answer > > message when Basic or Digest authentication is to be used." > > Section 3.1.2: AAA Command modified to include [ Challenge ] AVPs. > > Section 4.0 is introduced and includes the following text (while > > original Section 4.0 changes to 5.0 and so on): > > 4.0 Basic/Digest Authentication Support > > The Basic and Digest authentication schemes, described in [X], are two > > well-known authentication methods. This section describes the AVPs > that > > are required for Basic/Digest authentication support within the > Diameter > > protocol. As seen in Section 3.0, the Resource AVP and Response AVP > MAY > > be used within the AA-Request Command, while the Challenge AVP MAY be > > uesd within the AA-Answer Command. > > 4.1 Resource AVP > > The Resource AVP (AVP Code xxx) is of type OctetString and is used to > > convey a resource. It MAY be used by a DIAMETER client to convey to > the > > DIAMETER server the resource whose access needs authorization. > > 4.2 Challenge AVP > > The Challenge AVP (AVP Code xxx) is of type OctetString and is used to > > convey a challenge. It MAY be used by a DIAMETER server to convey a > > challenge to the DIAMETER client. > > 4.3 Response AVP > > The Response AVP (AVP Code xxx) is of type OctetString and is used to > > convey a response. It MAY be used by a DIAMETER client to convey a > > response to the DIAMETER server. > > > > Comments/Discussion (not part of proposed text): > > No separate command code has been proposed for Basic/Digest > > authentication, and the AAR and AAA commands have been modified to > > support the proposed AVPs. This implies that when a DIAMETER server > > receives an AAR command from a DIAMETER client, it cannot determine > > whether the authentication/authorization schemes are RADIUS based or > > Basic/Digest based just by looking at the command code. Instead, the > > AVPs have to be parsed to determine this. If this is seen as an issue, > > then a new command code may have to be introduced for the purpose of > > Basic/Digest authentication support. This would then be along the > lines > > of a new command code being introduced for the purpose of EAP > > authentication support. > > From owner-aaa-wg@merit.edu Wed Jul 25 16:36:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04824 for ; Wed, 25 Jul 2001 16:36:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E07F1912EC; Wed, 25 Jul 2001 16:34:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99AC1912F0; Wed, 25 Jul 2001 16:34:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0976912EC for ; Wed, 25 Jul 2001 16:34:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C89C75DDC6; Wed, 25 Jul 2001 16:36:26 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 426F25DDAF for ; Wed, 25 Jul 2001 16:36:26 -0400 (EDT) Received: (qmail 7047 invoked by uid 500); 25 Jul 2001 20:24:02 -0000 Date: Wed, 25 Jul 2001 13:24:02 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 98: Peer role in Peer table? Message-ID: <20010725132402.E6433@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA09@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA09@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Wed, Jul 25, 2001 at 06:46:12PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk ok, so it sounds like some clarifications are required in the base spec. Just as an FYI, a primary/secondary is not necessarily a configurable thing. Peers come and go, and the primary is the peer with which one is communicating. The secondary is the "backup" should the connection with the primary becomes suspect. Alternates are other peers that one does not necessarily have an open connection with (but it could), which will eventually become primary/secondary as failures occur. I had a rather lengthy definition of the above proposed, but was asked to remove all the verbage by someone else :( PatC On Wed, Jul 25, 2001 at 06:46:12PM +0200, Martin Julien (ECE) wrote: > Submitter name: Martin Julien > Submitter email address: martin.julien@ericsson.com > Date first submitted: July 25, 2001 > Reference: > Document: Base-07 > Comment type: T > Priority: 1 > Section: > Rationale/Explanation of issue: > > In section 5.1 of Base-07, referring to peer connections, what > is the difference between opening a connection to a primary or > to a secondary peer? Is that data expected to be configurable > or run-time dependent? My understanding is that it was intended > to be configurable by the system admin. > > The thing is that I do not really see what the role of primary, > secondary and alternate means? It is said that a connection should > be openned with all primary and secondary peers, and optionnally > with alternate ones. What is the real difference between them? > Shouldn't we simply say that for a particular peer, a connection > should be maintain or not? > > In fact, my confusion comes from the fact that I am not sure > if the secondary peer refers to the Alternate-Peer AVP or not? > The thing is that it is not possible to say if it is a secondary > or alternate peer with that Alternate-Peer AVP. > > Could you please tell me what were your intentions with that > Peer role exactly? > > Also, was the Alternate-Peer also good for routing answers > or not?, can it be used for upstream requests from the client > to the server when using the Destination-Host AVP? > > > Requested change: > > Please clarify this so that it is clear. > > > Regards, > Martin From owner-aaa-wg@merit.edu Wed Jul 25 18:03:30 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13806 for ; Wed, 25 Jul 2001 18:03:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F3FCE912F0; Wed, 25 Jul 2001 18:03:28 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C087912F2; Wed, 25 Jul 2001 18:03:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DCE58912F0 for ; Wed, 25 Jul 2001 18:02:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E40875DD91; Wed, 25 Jul 2001 18:04:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A11335DD8C for ; Wed, 25 Jul 2001 18:04:35 -0400 (EDT) Received: (qmail 7836 invoked by uid 500); 25 Jul 2001 21:52:12 -0000 Date: Wed, 25 Jul 2001 14:52:12 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 95: Problem with removing Record-Route AVPs Message-ID: <20010725145211.G6433@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, There are a couple of fixes to this problem, and my inclination is just to remove section 6.3. This would eliminate the ability for a server to hide the internal AAA topology of a network (well, to be fair one can still do it, but it will be undocumented). Any objections, PatC From owner-aaa-wg@merit.edu Wed Jul 25 19:51:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22634 for ; Wed, 25 Jul 2001 19:51:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18D0F912FC; Wed, 25 Jul 2001 19:51:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE870912FD; Wed, 25 Jul 2001 19:51:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C663F912FC for ; Wed, 25 Jul 2001 19:51:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 10A665DD91; Wed, 25 Jul 2001 19:53:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 652C45DD8C for ; Wed, 25 Jul 2001 19:53:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id QAA73669 for ; Wed, 25 Jul 2001 16:43:19 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Wed, 25 Jul 2001 16:43:18 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda for IETF 51 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Based on the agenda requests that have been received, here is a preliminary shot at the agenda for IETF 51. Comments welcome. ================================================================== AAA WG Agenda IETF 51, London, UK Wednesday, August 8, 2001 1300 - 1500 PRELIMINARIES (5 minutes) Agenda bashing Blue sheets Minute takers DIAMETER ISSUES Open Diameter Issues (30 minutes) Pat Calhoun http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt 3G COMMENTS ON DIAMETER Diameter as a 3G Accounting Protocol (10 minutes) Thaddeus Kobylarz 3GPP Comments on Diameter EAP extensions (10 minutes) Peter Howard Ileana Leuca SUPPORT FOR MOBILE IPv6 Franck Le (10 minutes) Diameter support for Mobile IPv6 http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt Franck Le (10 minutes) AAA Local Security Association (LSA): The Temporary Shared Key (TSK) http://www.ietf.org/internet-drafts/draft-le-aaa-lsa-tsk-00.txt SUPPORT FOR SIP/HTTP AUTHENTICATION Jari Arkko (10 minutes) HTTP Authentication with EAP http://www.ietf.org/internet-drafts/draft-arkko-http-eap-basic-04.txt Baruch Sterman (10 minutes) Digest Authentication in SIP using RADIUS http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-00.txt Sengodan Senthil (10 minutes) Diameter support for Basic and Digest authentication http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt From owner-aaa-wg@merit.edu Wed Jul 25 22:54:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05903 for ; Wed, 25 Jul 2001 22:54:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 51AEF91221; Wed, 25 Jul 2001 22:54:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BD3291222; Wed, 25 Jul 2001 22:54:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 217B091221 for ; Wed, 25 Jul 2001 22:54:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CFD55DD9D; Wed, 25 Jul 2001 22:56:09 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 14A605DD91 for ; Wed, 25 Jul 2001 22:56:09 -0400 (EDT) Received: (qmail 10100 invoked by uid 500); 26 Jul 2001 02:54:45 -0000 Date: Wed, 25 Jul 2001 21:54:45 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: API Issue Message-ID: <20010725215445.L23963@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk With the changes in the diameter base protocol draft (-06 and -07), it opens up some possible changes in the API. In the old api, you would simply create a new message via: AAANewMessage(commandCode, vendorId, sessionId, extensionId, &msg); The problem now is, requests and answers share the same command code. So, I see two ways to solve this: a) AAANewMessage(commandCode, vendorId, requestFlag, session id . . . yatta or b) A function to set the request bit: AAASetMessageAsResponse(AAAMessage *msg) AAASetMessageAsAnswer(AAAMessage *msg) Any preferences? I'm leaning towards style B. -Dave From owner-aaa-wg@merit.edu Thu Jul 26 08:44:55 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09616 for ; Thu, 26 Jul 2001 08:44:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FDA891309; Thu, 26 Jul 2001 07:27:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCF4A9130A; Thu, 26 Jul 2001 07:27:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B55C391309 for ; Thu, 26 Jul 2001 07:27:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DEB665DDB8; Thu, 26 Jul 2001 07:29:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8D0015DDA6 for ; Thu, 26 Jul 2001 07:29:03 -0400 (EDT) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20575; Thu, 26 Jul 2001 04:27:38 -0700 (PDT) Received: from vayne (muc-isdn-1 [129.157.164.101]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id NAA25126; Thu, 26 Jul 2001 13:27:36 +0200 (MET DST) Date: Thu, 26 Jul 2001 11:06:52 +0200 (MET DST) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: Clarification on ABNF Command specification To: Pat Calhoun Cc: Cain Brian-BCAIN1 , "'Erik Guttman'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <20010725121241.N10225@charizard.diameter.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk > On Wed, Jul 25, 2001 at 12:10:49PM -0500, Cain Brian-BCAIN1 wrote: > > I think the text "The AVP MUST be present" is slightly ambiguous. > > Perhaps "All occurrences of the AVP MUST be present in one contiguous > > block" or "The occurrences of this AVP MUST show up anywhere within > > the required section, potentially non-contiguously", depending on the > > answer. Okay, that doesn't quite flow that well, but someone could > > come up with an equivalent, I imagine. > > They don't have to be present in a contiguous block, and nowhere > have we stated this. The only AVPs that have strict ordering are > the ones with < >. All other AVPs may be present anywhere in a > message. Brian, The intent is to allow radius-like flexibility while adding three constraints - 1: AVPs can be fixed at the beginning and end (order and number) 2: AVPs can be required in the middle (number not order) 3: AVPs can be stuck in optionally (no order or number restrictions as long as it doesn't conflict with numbering restrictions in the 'required' section). If this is ambiguous in the current text I will open an issue with suggested new text. Erik From owner-aaa-wg@merit.edu Thu Jul 26 10:44:44 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13693 for ; Thu, 26 Jul 2001 10:44:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C8CE9130C; Thu, 26 Jul 2001 09:47:29 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2BD639130D; Thu, 26 Jul 2001 09:46:20 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DE3D09130C for ; Thu, 26 Jul 2001 09:46:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 317DC5DDAE; Thu, 26 Jul 2001 09:48:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 95FC15DD91 for ; Thu, 26 Jul 2001 09:48:17 -0400 (EDT) Received: (qmail 31958 invoked by uid 500); 26 Jul 2001 13:46:53 -0000 Date: Thu, 26 Jul 2001 08:46:53 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: API Issue Message-ID: <20010726084652.T23963@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010725215445.L23963@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010725215445.L23963@newman.frascone.com>; from dave@frascone.com on Wed, Jul 25, 2001 at 09:54:45PM -0500 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk On Wed, Jul 25, 2001 at 09:54:45PM -0500, David Frascone wrote: > With the changes in the diameter base protocol draft (-06 and -07), it > opens up some possible changes in the API. > > In the old api, you would simply create a new message via: > > AAANewMessage(commandCode, vendorId, sessionId, extensionId, &msg); > > The problem now is, requests and answers share the same command code. So, > I see two ways to solve this: > > a) AAANewMessage(commandCode, vendorId, requestFlag, session id . . . yatta > > or > > b) A function to set the request bit: > > AAASetMessageAsResponse(AAAMessage *msg) ^^^^^^^^ I meant request, of course. Twas late. > AAASetMessageAsAnswer(AAAMessage *msg) > > > Any preferences? > > I'm leaning towards style B. > > -Dave > From owner-aaa-wg@merit.edu Thu Jul 26 10:44:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13710 for ; Thu, 26 Jul 2001 10:44:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B54F9130D; Thu, 26 Jul 2001 09:54:55 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CA6F9130E; Thu, 26 Jul 2001 09:54:55 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 26CC99130D for ; Thu, 26 Jul 2001 09:54:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 86DCC5DDAE; Thu, 26 Jul 2001 09:56:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D4B455DD91 for ; Thu, 26 Jul 2001 09:56:52 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id GAA74589 for ; Thu, 26 Jul 2001 06:46:23 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 06:46:23 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: My email address Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk My current ISP/email provider is in the process of going out of business. This has required me to get my domain rehosted, MX records changed, etc. It is conceivable that this process may not go smoothly, and that service will be interrupted for some period before I can once again receive email at aboba@internaut.com. If email bounces for some period of time, an alternative email address for me is bernarda@microsoft.com. From owner-aaa-wg@merit.edu Thu Jul 26 10:44:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13740 for ; Thu, 26 Jul 2001 10:44:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 43EC29122B; Thu, 26 Jul 2001 04:32:57 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9F1EA91229; Thu, 26 Jul 2001 04:31:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38E8991228 for ; Thu, 26 Jul 2001 04:31:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EC0895DDA8; Thu, 26 Jul 2001 04:33:25 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 16F455DD9D for ; Thu, 26 Jul 2001 04:33:25 -0400 (EDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6Q8W1N20637 for ; Thu, 26 Jul 2001 10:32:01 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Thu Jul 26 10:31:48 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:31:44 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA0A@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 98: Peer role in Peer table? Date: Thu, 26 Jul 2001 10:31:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, > ok, so it sounds like some clarifications are required in the base > spec. Just as an FYI, a primary/secondary is not necessarily > a configurable > thing. Peers come and go, and the primary is the peer with > which one is > communicating. The secondary is the "backup" should the > connection with > the primary becomes suspect. Alternates are other peers that > one does not > necessarily have an open connection with (but it could), > which will eventually > become primary/secondary as failures occur. I guess that it suggests that the DRT should return a list of servers, which should be looked into to find out whether one of them is primary and available? If not, then a secondary server is searched for. That means that load-balancing would occur only if several servers with the same role are defined for the DRT entry. Does that mean that the Diameter node needs to make sure that for all DRT entry, there is at least 2 servers available all the time, I guess that is what it comes down to, right? That would mean that when a Peer becomes suspect, then the DRT has to be looked into in order to find out which DRT entry is affected in order to possibly initiate a new connection to another host????? Also, when receiving the Alternate-peer AVPs in the CER/CEA, should one of them be defined as secondary, while the others as alternate?, unless they are already defined as primary or secondary, of course. The reason for this being that for routing based on Route-Record, Source-Route and Destination-Host, I guess it would also be nice to have to same kind on feature, no? So, as I see it, it is quite a lot of work to support this concept of connections, from a point of view of a Diameter agent and server, at least. Since I am not really sure up to what point agents are expected to have openned connections, I am wondering if this is really something important for Diameter nodes? Martin > I had a rather lengthy definition of the above proposed, but > was asked to > remove all the verbage by someone else :( > > PatC > On Wed, Jul 25, 2001 at 06:46:12PM +0200, Martin Julien (ECE) wrote: > > Submitter name: Martin Julien > > Submitter email address: martin.julien@ericsson.com > > Date first submitted: July 25, 2001 > > Reference: > > Document: Base-07 > > Comment type: T > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > In section 5.1 of Base-07, referring to peer connections, what > > is the difference between opening a connection to a primary or > > to a secondary peer? Is that data expected to be configurable > > or run-time dependent? My understanding is that it was intended > > to be configurable by the system admin. > > > > The thing is that I do not really see what the role of primary, > > secondary and alternate means? It is said that a connection should > > be openned with all primary and secondary peers, and optionnally > > with alternate ones. What is the real difference between them? > > Shouldn't we simply say that for a particular peer, a connection > > should be maintain or not? > > > > In fact, my confusion comes from the fact that I am not sure > > if the secondary peer refers to the Alternate-Peer AVP or not? > > The thing is that it is not possible to say if it is a secondary > > or alternate peer with that Alternate-Peer AVP. > > > > Could you please tell me what were your intentions with that > > Peer role exactly? > > > > Also, was the Alternate-Peer also good for routing answers > > or not?, can it be used for upstream requests from the client > > to the server when using the Destination-Host AVP? > > > > > > Requested change: > > > > Please clarify this so that it is clear. > > > > > > Regards, > > Martin > From owner-aaa-wg@merit.edu Thu Jul 26 11:00:47 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14935 for ; Thu, 26 Jul 2001 11:00:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D808091211; Thu, 26 Jul 2001 09:17:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9BD81912C7; Thu, 26 Jul 2001 09:17:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E50B91211 for ; Thu, 26 Jul 2001 09:17:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E1DAA5DDCE; Thu, 26 Jul 2001 09:19:48 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 63ACD5DDA9 for ; Thu, 26 Jul 2001 09:19:48 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f6QDFrO09368; Thu, 26 Jul 2001 09:15:53 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from mailman(172.21.24.8) by ahab via smap (V2.1) id xma009365; Thu, 26 Jul 01 09:15:30 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f6QDI0j02580; Thu, 26 Jul 2001 09:18:00 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman via smap (V2.1) id xma002389; Thu, 26 Jul 01 09:16:40 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <3RZSJ11V>; Thu, 26 Jul 2001 09:16:39 -0400 Message-ID: From: Yiwen Jiang To: "'pcalhoun@diameter.org'" Cc: aaa-wg@merit.edu Subject: [AAA-WG]: clarification on Session connection vs. peer connection Date: Thu, 26 Jul 2001 09:16:34 -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-wg@merit.edu Precedence: bulk Hi Pat, I would like to ask a very fundamental (and possibily classified as stupid :) question regarding the session and peer connection. It is my understanding, that the session and peer connections are used for separate purposes: The session connection is used only between a Diameter client and a Diameter server to perform application related requests to the Diameter server. Every time a session is initiated by a Diameter client, a TCP connection is initiated to the Diameter server. (So there can be > 1 TCP connections between a Diameter client and Diameter server). If this Diameter server is not the home server, it will relay/proxy this request to a connecting server via peer-to-peer connections. In fact, the peer-to-peer connection is only used between peers to perform message relay/proxy services as well as fail over situations. Diameter ----------------> Diameter -----------------> Diameter Client Server 1 Server 2 session connection peer connection Is there any instances that the session based requests actually is initiated from a Diameter server to another Diameter server, without any action of the Diameter client? (I don't think so, but if you could confirm this, it would be great!) I would assume that a Diameter client is a separate application from a Diameter server even if they can be run on the same machine? Thank you very much for your help! Yiwen From owner-aaa-wg@merit.edu Thu Jul 26 11:39:13 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18406 for ; Thu, 26 Jul 2001 11:39:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 352049130B; Thu, 26 Jul 2001 09:31:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC5AF9130C; Thu, 26 Jul 2001 09:31:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4EE29130B for ; Thu, 26 Jul 2001 09:31:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D76C5DD91; Thu, 26 Jul 2001 09:33:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id A17725DDD4 for ; Thu, 26 Jul 2001 09:33:12 -0400 (EDT) Received: (qmail 9826 invoked by uid 500); 26 Jul 2001 13:20:46 -0000 Date: Thu, 26 Jul 2001 06:20:46 -0700 From: Pat Calhoun To: Guenter Schaefer Cc: AAA Mailinglist Subject: Re: [AAA-WG]: Inconsistency regarding Destination-Host AVP Message-ID: <20010726062046.K6433@charizard.diameter.org> Mail-Followup-To: Guenter Schaefer , AAA Mailinglist References: <3B5FDD50.DC20C3F2@ee.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3B5FDD50.DC20C3F2@ee.tu-berlin.de>; from schaefer@ee.tu-berlin.de on Thu, Jul 26, 2001 at 11:05:20AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Would you kindly open an issue for this inconsistency. I'll have it fixed up in the next version. (actually, if memory serves, you had other editorial issues, so you can bundle all of them into a single issue) Thanks, PatC On Thu, Jul 26, 2001 at 11:05:20AM +0200, Guenter Schaefer wrote: > Dear all, > > there is a minor inconsistency in the two drafts > > "draft-ietf-aaa-diameter-07.txt" and > > "draft-ietf-aaa-diameter-mobileip-07.txt" > > Section 6.6 in the base protocol specification states: > > "6.6 Destination-Host AVP > > The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. > This AVP MUST be present in all unsolicited agent initiated messages, > MAY be present in request messages, and MUST NOT be present in Answer > messages." > > However, in "draft-ietf-aaa-diameter-mobileip-07.txt" the Destination > Host AVP is specified to be mandatory in AMA and HAA messages > (sections 2.2 and 2.4). > > With kind regards, > > Guenter Schaefer > > ------------------------------------------------------------------------ > Guenter Schaefer, Institute of Telecommunication Systems, > Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, > Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Thu Jul 26 12:00:51 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19514 for ; Thu, 26 Jul 2001 12:00:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D0D9F9122C; Thu, 26 Jul 2001 05:03:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8FFBB912DA; Thu, 26 Jul 2001 05:03:02 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 965C69122C for ; Thu, 26 Jul 2001 05:02:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9DA0B5DDB2; Thu, 26 Jul 2001 05:04:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by segue.merit.edu (Postfix) with ESMTP id 709F25DD9D for ; Thu, 26 Jul 2001 05:04:45 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15Ph3B-0005KL-00; Thu, 26 Jul 2001 11:03:21 +0200 Received: from ee.tu-berlin.de (root@ftmail.ee.tu-berlin.de [130.149.49.250]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6Q93Kh26691 for ; Thu, 26 Jul 2001 11:03:20 +0200 Message-ID: <3B5FDD50.DC20C3F2@ee.tu-berlin.de> Date: Thu, 26 Jul 2001 11:05:20 +0200 From: Guenter Schaefer X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: AAA Mailinglist Subject: [AAA-WG]: Inconsistency regarding Destination-Host AVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, there is a minor inconsistency in the two drafts "draft-ietf-aaa-diameter-07.txt" and "draft-ietf-aaa-diameter-mobileip-07.txt" Section 6.6 in the base protocol specification states: "6.6 Destination-Host AVP The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MUST NOT be present in Answer messages." However, in "draft-ietf-aaa-diameter-mobileip-07.txt" the Destination Host AVP is specified to be mandatory in AMA and HAA messages (sections 2.2 and 2.4). With kind regards, Guenter Schaefer ------------------------------------------------------------------------ Guenter Schaefer, Institute of Telecommunication Systems, Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Thu Jul 26 12:29:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20689 for ; Thu, 26 Jul 2001 12:29:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7AF4091326; Thu, 26 Jul 2001 12:10:56 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A3AA91325; Thu, 26 Jul 2001 12:10:56 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6017591323 for ; Thu, 26 Jul 2001 12:10:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 07DF75DDCE; Thu, 26 Jul 2001 12:12:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by segue.merit.edu (Postfix) with ESMTP id A69625DDD6 for ; Thu, 26 Jul 2001 12:12:52 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id JAA22179 for ; Thu, 26 Jul 2001 09:11:28 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA22193 for ; Thu, 26 Jul 2001 09:04:00 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 11:11:27 -0500 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECFA8@IL27EXM10.cig.mot.com> From: Cain Brian-BCAIN1 To: "'Erik Guttman'" , Pat Calhoun Cc: Cain Brian-BCAIN1 , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Clarification on ABNF Command specification Date: Thu, 26 Jul 2001 11:11:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-aaa-wg@merit.edu Precedence: bulk > -----Original Message----- > From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] > Subject: Re: [AAA-WG]: Clarification on ABNF Command specification ... > Brian, > > The intent is to allow radius-like flexibility while adding three > constraints - > 1: AVPs can be fixed at the beginning and end (order and number) > 2: AVPs can be required in the middle (number not order) > 3: AVPs can be stuck in optionally (no order or number restrictions > as long as it doesn't conflict with numbering restrictions in the > 'required' section). > > If this is ambiguous in the current text I will open an issue with > suggested new text. In the interest of interoperability, it probably would not be a bad thing to explicitly state that the AVPs needn't be contiguous. "The AVP MUST be present" does seem to imply that "this AVP MUST occur at least min times, at most max times, anywhere in the required section, and all occurrences needn't be in a contiguous block," but the latter could be more helpful. It's not important to me that a change in the text be made, but if it's unclear to anyone else, maybe it's worth considering. On a side note, I noticed that we have a Result-Code AVP value defined for: > DIAMETER_AVP_OCCURS_TOO_MANY_TIMES 5010 but we don't have a "DIAMETER_AVP_OCCURS_TOO_FEW_TIMES" -- it looks like we should use "DIAMETER_MISSING_AVP" instead? Perhaps that needs to be made more explicit? The text for MISSING_AVP says "The request did not contain an AVP that is required" which does seem to imply "did not contain an AVP that is required, or as many occurrences of an AVP that are required", but again, maybe it's better to make it more explicit. Food for thought. > Erik From owner-aaa-wg@merit.edu Thu Jul 26 12:30:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20827 for ; Thu, 26 Jul 2001 12:30:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4F9999131F; Thu, 26 Jul 2001 12:10:34 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AD3F91320; Thu, 26 Jul 2001 12:10:34 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F107B9131F for ; Thu, 26 Jul 2001 12:10:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 96B7F5DDCE; Thu, 26 Jul 2001 12:12:32 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 0DC065DDC8 for ; Thu, 26 Jul 2001 12:12:32 -0400 (EDT) Received: (qmail 11243 invoked by uid 500); 26 Jul 2001 16:00:05 -0000 Date: Thu, 26 Jul 2001 09:00:05 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: clarification on Session connection vs. peer connec tion Message-ID: <20010726090004.P6433@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, Jul 26, 2001 at 11:22:14AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 26, 2001 at 11:22:14AM -0400, Yiwen Jiang wrote: > Hi Pat, > > Thanks very much for the mail... Just a few more questions. > > > I think that it is important to note that there is a huge > > distinction between > > a connection and a session. Let's consider the following diagram: > > > > +--------+ +-------+ +--------+ > > | Client | | Relay | | Server | > > +--------+ +-------+ +--------+ > > <----------> <----------> > > Connection A Connection B > > > > <------------------------------> > > Session x > > > > In the above example, Connection A is established between the > > Client and > > its local Relay. This connection is essentially a transport > > level connection, > > but we have some messages that are sent over that link for > > announcements > > and keepalive purposes (CER/CEA and DWR/DWA, respectively). > > You can think > > of a connection as a means to send messages to a peer. > So, in this picture, do you mean that client, relay, and server are all > classified as Diameter peers? I guess this is one of the confusion I have. Yes, a peer is a Diameter node that one is communicating directly with. > If Connection A is a peer-to-peer connection, then that implies that the > relay can actually initiate a connection to the client? but when would this > be the case? Isn't clients always initiate connection requests? It is possible for a relay to initiate a connection, since it may not know that its peer is a client. It is for this reason that we went out of our way to ensure that the peer state machine was designed to not allow multiple transport connections between two peers. > Does this mean, for example, a NASREQ client will start up, and before it > does anything, it will try to establish a peer-to-peer connection to an > imediate Diameter server before it can handle any user requests? that is correct. > Also, does this mean, that before the client start session x, it must start > a peer to peer connection first to the relay ? yes, but this is the same as your previous question (unless I misunderstood the previous question). > In Section 8.1, at the end > of the state machine, it indicated a "Discon" as a new state in case of a > few event, including the receiving of the ASR. But at the disconnect state, > (the last line), it indicated cleanup. Are you referring to disconnect the > peer connection? Or it must be the session "logical" disconnect then? No, the peer state machine is section 5.6, and has no relationship with the session state machine in 8.1. Disconnecting (or cleaning up) a session in no way implies that it affects the peer connection. > > > Every time a session is initiated by a Diameter client, a > > > TCP connection is initiated to the Diameter server. (So > > there can be > 1 TCP > > > connections between a Diameter client and Diameter server). > > > > If you use the logic above, then you'll realize that all sessions are > > "multiplexed" through a single connection. In fact, the > > protocol states that > > there should only be a single connection between two peers. > Yes. But I didn't realize that a Diameter client is classified as a "peer" > here... (contradictory terms in my mind, but maybe that is just my English. > :) The reason why we consider these peers is because server-initiated messages are allowed. In the RADIUS world, this isn't allowed, so clients and servers are fundamentally different. In Diameter, although they each have separate functions, each can initiate connections and messages. > > Yes, they could run on the same machine. It is also possible > > for a server > > to contact a server, but that would be a strange case. The > > one that comes to > > mind is an authorization server that sends a separate request to an > > authentication server. Server 1 is the authorization server, > > and when it > > receives the answer from server 2, it sends back the > > successful response to > > the client. Now, this is a strange case, and isn't the > > typical deployment, > > so if you find this confusing, please disregard it. > So is the difference between Diameter client and Diameter server only on who > initiates sessions ?? No. The main difference is that the server has access to the user database, and processes auth requests. The client doesn't, and processes auth answers. However, the client can process other types of request messages (e.g. abort session requests). Hope this is clearer, PatC From owner-aaa-wg@merit.edu Thu Jul 26 12:35:44 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21232 for ; Thu, 26 Jul 2001 12:35:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AC4A91231; Thu, 26 Jul 2001 12:35:24 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58A4591321; Thu, 26 Jul 2001 12:35:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 29C8B91231 for ; Thu, 26 Jul 2001 12:35:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CBCEF5DDCE; Thu, 26 Jul 2001 12:37:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 3598B5DDB2 for ; Thu, 26 Jul 2001 12:37:22 -0400 (EDT) Received: (qmail 11355 invoked by uid 500); 26 Jul 2001 16:24:55 -0000 Date: Thu, 26 Jul 2001 09:24:55 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 98: Peer role in Peer table? Message-ID: <20010726092454.U6433@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA0A@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA0A@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Thu, Jul 26, 2001 at 10:31:29AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk hmmm.... now I'm really upset that I was convinced to remove all of the verbage that I had originally proposed :( See my comments below. On Thu, Jul 26, 2001 at 10:31:29AM +0200, Martin Julien (ECE) wrote: > I guess that it suggests that the DRT should return a > list of servers, which should be looked into to find out > whether one of them is primary and available? If not, > then a secondary server is searched for. That means that > load-balancing would occur only if several servers with > the same role are defined for the DRT entry. Does that > mean that the Diameter node needs to make sure that > for all DRT entry, there is at least 2 servers available > all the time, I guess that is what it comes down to, right? A peer could be marked as primary, but this isn't really necessary. A DRT lookup could return multiple servers, and if they aren't marked with any form of priority, then some mechanism should be employed to determine which one should become primary. The same is done for the secondary. It is recommended that there be at least 2 possible servers for a given realm, but this isn't mandatory (of course, without it you have no failover capabilities). > > That would mean that when a Peer becomes suspect, then the > DRT has to be looked into in order to find out which DRT > entry is affected in order to possibly initiate a new > connection to another host????? Well, that's why you typically want a secondary up and available. So, if you have a secondary connection, should the primary become suspicious, you can start sending messages to the secondary right away. However, this is not a function of the routing table, but rather of the peer table. > Also, when receiving the Alternate-peer AVPs in the > CER/CEA, should one of them be defined as secondary, while > the others as alternate?, unless they are already defined > as primary or secondary, of course. The reason for this > being that for routing based on Route-Record, Source-Route > and Destination-Host, I guess it would also be nice to > have to same kind on feature, no? well, perhaps the language here is mixed up. Alternates, as defined in the CER/CEA is ONLY for server-initiated messages, and not for determining which peer is primary/secondary/alternate. > So, as I see it, it is quite a lot of work to support this > concept of connections, from a point of view of a Diameter > agent and server, at least. Since I am not really sure > up to what point agents are expected to have openned > connections, I am wondering if this is really something > important for Diameter nodes? Absolutely. However, if you prefer to not include any failover code in your implementation, then that's your perogative. PatC From owner-aaa-wg@merit.edu Thu Jul 26 13:20:37 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22157 for ; Thu, 26 Jul 2001 13:20:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F325B912E2; Thu, 26 Jul 2001 13:17:21 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A159E91328; Thu, 26 Jul 2001 13:17:07 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 08A1C912E2 for ; Thu, 26 Jul 2001 13:16:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ADCFA5DDCE; Thu, 26 Jul 2001 13:18:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 001E95DDA8 for ; Thu, 26 Jul 2001 13:18:41 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74764 for ; Thu, 26 Jul 2001 10:08:12 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:08:12 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-mobileip-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-mobileip-07.txt, "Diameter Mobile IPv4 Application". This document is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. After WG last call has passed, and WG comments have been incorporated, we will pass this document onto the IESG for consideration as an IETF Proposed Standard. From owner-aaa-wg@merit.edu Thu Jul 26 13:20:43 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22188 for ; Thu, 26 Jul 2001 13:20:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 40BD0912E7; Thu, 26 Jul 2001 13:17:35 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 37A1F91325; Thu, 26 Jul 2001 13:17:26 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EF9B3912E7 for ; Thu, 26 Jul 2001 13:16:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB6F65DDCE; Thu, 26 Jul 2001 13:18:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id F26955DDA8 for ; Thu, 26 Jul 2001 13:18:00 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74760 for ; Thu, 26 Jul 2001 10:07:31 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:07:31 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-nasreq-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-nasreq-07.txt, "Diameter NASREQ Application". This document is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. After WG last call has passed, and WG comments have been incorporated, we will pass this document onto the IESG for consideration as a Proposed Stanard. From owner-aaa-wg@merit.edu Thu Jul 26 13:20:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22235 for ; Thu, 26 Jul 2001 13:20:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18456912E1; Thu, 26 Jul 2001 13:18:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D3B3A912E6; Thu, 26 Jul 2001 13:18:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E974912E1 for ; Thu, 26 Jul 2001 13:18:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C2485DDCE; Thu, 26 Jul 2001 13:20:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 7FDB25DDA8 for ; Thu, 26 Jul 2001 13:20:39 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74771 for ; Thu, 26 Jul 2001 10:10:09 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:10:09 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-cms-sec-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-cms-sec-02.txt, "Diameter CMS Security Application". This document is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. After WG last call has passed, and WG comments have been incorporated, we will pass this document onto the IESG for consideration as a Proposed Standard. From owner-aaa-wg@merit.edu Thu Jul 26 13:21:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22373 for ; Thu, 26 Jul 2001 13:21:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C423912E6; Thu, 26 Jul 2001 13:21:59 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4DB6891323; Thu, 26 Jul 2001 13:21:59 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 112E6912E6 for ; Thu, 26 Jul 2001 13:21:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BFAA95DDCE; Thu, 26 Jul 2001 13:23:57 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp018.mail.yahoo.com (smtp018.mail.yahoo.com [216.136.174.115]) by segue.merit.edu (Postfix) with SMTP id 39F125DDA8 for ; Thu, 26 Jul 2001 13:23:57 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jul 2001 17:22:32 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010726190831.00c985d0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 19:19:34 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" In-Reply-To: <20010726095207.B6433@charizard.diameter.org> References: <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 18:52 26/07/01, Pat Calhoun wrote: >Why, exactly, is it necessary for the same path to be taken >for a given session? Doing so will reduce the reliability of >the protocol, since an agent that is no longer available wouldn't >be able to be used. If some mechanism is used to failover all >sessions to the unavailable server is designed, then you still >have to support the case where state was lost. > >So, this is just half a fix, IMHO. The real fix is to write something >to a backend database, no local memory, and that's no a protocol issue. Well, there are two cases: - two (or more) agents in a load-balanced/failover setup - two (or more) completely different paths via different administrative domains Let's consider this: ISP.NET client---ISP.NET proxy-----ROAMING1.NET proxy 1-----HOME.COM server | | +-------------ROAMING1.NET proxy 2---------+ | | +-------------ROAMING2.NET proxy 1---------+ | | +-------------ROAMING2.NET proxy 2---------+ The ISP.NET proxy can reach HOME.COM either via ROAMING1.net, or via ROAMING2.NET. And both have two proxies. Picking any of the two proxies of one or the other is OK (provided the two proxies keep "in sync" somehow). But sending some stuff to ROAMING1.NET and some other to ROAMING2.NET might not. > > > It draws on the already-existing Route-Record & Source-route > > > mechanism > > > (with Alternates etc.) and requires just two changes: > > > - server returns the full list of Route-Records in answer [it > > > already saves > > > it for unsolicited requests] > > > - client saves it for future requests. > >And I suppose the issue is that the Route-Records AVPs are removed at >each hop in the routing of the answer messages. We removed this :-) We might just want to make it explicit that Route-Records must be left unchanged (nothing added, nothing removed) when routing answers. >Right. I honestly don't understand the problem here. We are going out >of our way to add complexity to support a really bad model. Randy Bush >has stated time and time again, that we MUST NOT add complexity throughout >the protocol to support proxies. They are evil, and while the protocol >does support them, adding more complexity shouldn't be done. I don't think it adds that much complexity. The only changes are: 1. Server sends back the whole list of Route-Records it got in the answer 2. Explicitly state that relays/proxies don't touch Route-Records in answers 3. Client stores the list of Route-Records received in the latest answer for a session 4. Client uses this list as Source-Route AVPs in subsequent requests for the same session. 5. Explicitly state that proxies and relays ignore Destination-Host/Realm AVPs if Source-Route AVPs are present. And even though proxies might be evil, they are THE fundamental part of the whole global roaming architecture, don't you think? Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jul 26 13:26:52 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22612 for ; Thu, 26 Jul 2001 13:26:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00B3991323; Thu, 26 Jul 2001 13:26:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C212A91325; Thu, 26 Jul 2001 13:26:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9E0FF91323 for ; Thu, 26 Jul 2001 13:26:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5EFA15DDCE; Thu, 26 Jul 2001 13:28:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp014.mail.yahoo.com (smtp014.mail.yahoo.com [216.136.173.58]) by segue.merit.edu (Postfix) with SMTP id D113D5DDA8 for ; Thu, 26 Jul 2001 13:28:44 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jul 2001 17:27:20 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010725183424.00c83310@pop.fr.psi.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 19:27:07 +0200 To: aaa-wg@merit.edu From: Jacques Caron Subject: [AAA-WG]: Issue 100: Editorial comments on base-07 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron Submitter email address: jacques_m_caron@yahoo.com Date first submitted: July 25, 2001 Reference: Document: Base-07 Comment type: E Priority: 1 Section: throughout Rationale/Explanation of issue: In 3.0 - Commands flags, r(eserved): should state that an error must be generated if a packet is received with such a bit set to one. In 3.3: - 1st paragraph: "Diameter commands typically start with an object name". Not that sure :-) - 2nd paragraph: "The corresponding answer MUST contain either a positive or negative result code". What about multi-round trip messages, and redirects? In 4.0: - 1st paragraph: "Diameter AVPs carry specific authentication, accounting and authorization information, security information as well as configuration details..." They can also carry routing information (unless that's what is meant by "configuration details". In 4.1: - AVP Code: "The first 256 AVP numbers are reserved for backward compatibility with RADIUS". Even if Vendor-Id is non-zero? - AVP Flags, "Note that subsequent Diameter applications MAY define additional bits within the AVP Header, and an unrecognized bit SHOULD be considered an error". Didn't find an error number for that one in 7.1.x. - AVP Flags, 2nd paragraph, "If an unrecognized AVP with the 'M' bit set is received by a Diameter node..." replace node with "client, server or proxy". The client thing raises the issue stated in the 7.1.4/7.1.5 section about errors in answers, though. Also, it should not be only if the AVP is unrecognized, but also if the requested AVP or value is recognized, but the node does not accept it. - AVP Flags, 3rd paragraph, "In order to provide service to the user, the node at fault MUST re-issue...". The client might decide that if the server doesn't understand that AVP, it doesn't want to provide service to the user. Make that explicit rather than implicit. - AVP Flags, 4th paragraph, add a comma between "ABNF" and "is at fault". - AVP Flags, 5th paragraph, "AVPs with the 'M' bit cleared are informational only and a receiver that receives a message with such an AVP that is not supported MAY simply ignore the AVP." The AVP might be supported but not the value, and it could be ignored also, right? Same thing if the AVP and value are supported but the node does not want to honor that AVP or value. In 4.3, - the definitions for Float32, 64 and 128 are truncated: "'V' bit is enabled)." is missing. In 4.4, - 1st paragraph, "In addition to the AVP Base Data Formats" -> "In addition to *using* the AVP Base Data Formats". - 1st paragraph, "New AVP Derived Data Formats MUST be registered with IANA." How could they be registered? There is no "unique identifier" or anything of the sort. And since the AVP contents are actually opaque to those that are not involved, I don't quite see the need. They should just be defined in any application that uses them. Also, if they must indeed be registered, a section in 11.x is missing. - 3rd paragraph, "AVP Derived DATA Formats" -> "AVP Derived Data Formats" - IPAddress, what if an AVP must explicitly have an IPv4 or IPv6, and not "any of those"? - UTF8String, 1st paragraph, reference wrong [24] not [29] (it might be a good thing to actually check all refs) - UTF8String, 2nd and 8th paragraphs, no zeros mentionned twice - DiameterIdentity, get aaa-protocol and protocol at the bottom (in the same order they're used) - DiameterIdentity, 2nd paragraph "The following..." is indented one notch too much - DiameterIdentity, 3rd paragraph, "Since multiple...", why "per host"? It's rather "per process", or should be reworded to read "the DiameterIdentity of any process is guaranteed to be unique." - DiameterIdentity, 4th paragraph, "A Diameter node MAY advertise different identities...". Glurgs! Certainly not! It MUST be the same identity on all connections (unless the host is a gateway between two routing domains (e.g. private and public)). Otherwise there's no way to detect duplicate connections, loops, etc. consistently. Remember, the DiameterIdentity, as used in CER/CEA and Route-Records is just considered as an opaque and unique identifier. - DiameterIdentity, 5th paragraph, this is not needed in duplicate connection detection and loop avoidance, since the identifier is opaque. It can save time, however, when one gets an external reference to another host (via SLP, DNS, Redirect, Alternate-Host...) and one wants to check that this new host doesn't match one it already knows/already is connected to. But even if that's not done, a match would be detected upon connection to the new host when the CER/CEAs are exchanged and the "real" (unique) identity is discovered and can be matched against existing connections. - IPFilterRule, 2nd to last paragraph, "An access device that is unable to interpret or apply a deny rule MUST terminate the session." Shouldn't this be dependent on whether the M bit is set or not? Ditto for the second sentence (though it's probably not as important). - QOSFilterRule: I thought the idea was to reference an IPFilterRule to determine what traffic should be marked or metered? In 4.5: - 1st paragraph, swap the ' and the . in 'Grouped.' - 3rd paragraph, "All AVPs included in a Grouped AVP Every Grouped AVP defined...". Either something is missing before the Every, or the all before the Every is not needed. - in the ABNF spec, "header = """, how does one specify the Vendor-Id, if any? In 4.5.1: - in the paragraph starting with "The data for the optional AVPs...", why is is stated that "AVPs do not have to begin on 8 byte boundaries"? It is true, but I quite see why people would think it? In 4.6: - in the table, what if a flag is in neither column for a given AVP (e.g. P is often absent) - here also, what about renumbering everything in a contiguous space? - checking section references would be a good idea, but I'm way to lazy for that. In 5.0: - "This section describes how a Diameter nodes establish connections and communicate with peers." Either remove the "a" or move everything to singular. In 5.1: - 1st paragraph, specify that this "per realm" rather than globally? Though there is the issue of proxies that serve many many realms (with different peers), and dynamically learned realms/peers. In 5.2: - 4th paragraph "2. The Diameter implementation uses SLPv2...", swap ) and . in "agents.)". in 5.3: - 5th paragraph, "Since the CER/CEA messages...", replace "an upstream" with "a". Also specify the Result-Code to be used in the error message. In 6.8.1: - "The identity added in this AVP MUST be the same as the one sent in the Origin-Host of the Capabilities-Exchange-Request message". sent -> received. Capabilities-Exchange-Request -> Capabilities Exchange. In 7.1.2: - DIAMETER_LIMITED_SUCCESS: "When returned, the request was successfully completed, but additional processing is required by the application in order to provide service to the user." Gni? What is that? In 7.1.3: - DIAMETER_INVALID_ROUTE_RECORD is no longer needed. - DIAMETER_REDIRECT_INDICATION might be better off in the informational types? In 7.1.4/7.1.5: - I'm still not quite sure of the distinction between permanent and transient. e.g. DIAMETER_AUTHENTICATION_REJECTED [which is transient, so can be retried] means the request can be retried after asking the user for its password again. So it's not actually the same request, right? On the other hand, DIAMETER_AVP_UNSUPPORTED and DIAMETER_INVALID_AVP_VALUE [which are permanent, so shouldn't be retried] imply that you can retry by removing the AVP or changing the value [that's actually the "content-negociation" part of Diameter]. Actually, we might be better off with some category that includes anything that means neither Accepted nor Refused, but rather "more to come" (which would include both the multi-round-trip auths and other capabilities negociation messages). Also, what if an error is detected on the answer rather than the request? Ditto for capabilities negociation in that direction (e.g. if server says "please set this feature to that value for that user" and client or proxy want to say "don't know what you're talking about/don't want to do that"). That's it for today. More to come tomorrow... [let me know if you want me to split some of these to different issues, since some might be a bit more than just editorial changes]. I also have to repost my previous mail as an issue. Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jul 26 13:32:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23524 for ; Thu, 26 Jul 2001 13:32:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A612091327; Thu, 26 Jul 2001 13:09:58 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6240D9132B; Thu, 26 Jul 2001 13:09:58 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BFA9F91327 for ; Thu, 26 Jul 2001 13:09:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BC335DDCE; Thu, 26 Jul 2001 13:11:54 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id C8B595DDA8 for ; Thu, 26 Jul 2001 13:11:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74745; Thu, 26 Jul 2001 10:01:24 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:01:24 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Cc: aboba@internaut.com Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-07.txt, which is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. From owner-aaa-wg@merit.edu Thu Jul 26 13:35:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24108 for ; Thu, 26 Jul 2001 13:35:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A614A9122F; Thu, 26 Jul 2001 10:55:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6DF9F91313; Thu, 26 Jul 2001 10:55:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 473109122F for ; Thu, 26 Jul 2001 10:55:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B79E25DDA6; Thu, 26 Jul 2001 10:57:47 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 168B75DD91 for ; Thu, 26 Jul 2001 10:57:47 -0400 (EDT) Received: (qmail 10014 invoked by uid 500); 26 Jul 2001 14:45:20 -0000 Date: Thu, 26 Jul 2001 07:45:20 -0700 From: Pat Calhoun To: Yiwen Jiang Cc: "'pcalhoun@diameter.org'" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: clarification on Session connection vs. peer connection Message-ID: <20010726074520.L6433@charizard.diameter.org> Mail-Followup-To: Yiwen Jiang , "'pcalhoun@diameter.org'" , aaa-wg@merit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Thu, Jul 26, 2001 at 09:16:34AM -0400 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 26, 2001 at 09:16:34AM -0400, Yiwen Jiang wrote: > I would like to ask a very fundamental (and possibily classified as stupid > :) question regarding the session and peer connection. Let's see what I can do. > It is my understanding, that the session and peer connections are used for > separate purposes: The session connection is used only between a Diameter > client and a Diameter server to perform application related requests to the > Diameter server. I think that it is important to note that there is a huge distinction between a connection and a session. Let's consider the following diagram: +--------+ +-------+ +--------+ | Client | | Relay | | Server | +--------+ +-------+ +--------+ <----------> <----------> Connection A Connection B <------------------------------> Session x In the above example, Connection A is established between the Client and its local Relay. This connection is essentially a transport level connection, but we have some messages that are sent over that link for announcements and keepalive purposes (CER/CEA and DWR/DWA, respectively). You can think of a connection as a means to send messages to a peer. A session, on the other hand, is an application level thing. It is virtual, meaning that there is nothing at the transport layer that refers to a session. It is purely a Diameter thing. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session. To close the session, the client must sent a session termination message, or the server can initiate a session to be terminated as well, using a server-initiated message. > Every time a session is initiated by a Diameter client, a > TCP connection is initiated to the Diameter server. (So there can be > 1 TCP > connections between a Diameter client and Diameter server). If you use the logic above, then you'll realize that all sessions are "multiplexed" through a single connection. In fact, the protocol states that there should only be a single connection between two peers. > If this Diameter > server is not the home server, it will relay/proxy this request to a > connecting server via peer-to-peer connections. In fact, the peer-to-peer > connection is only used between peers to perform message relay/proxy > services as well as fail over situations. Well, peer-to-peer connections are used to transmit messages. An implementation MAY wish to process the message locally, relay or proxy the message to a peer. When a connection is suspicious, another peer is used. So, there should always be multiple possible peers, but it isn't necessary to have a nailed up transport connection with all peers. > > Diameter ----------------> Diameter -----------------> Diameter > Client Server 1 Server 2 > > session connection peer connection > > Is there any instances that the session based requests actually is initiated > from a Diameter server to another Diameter server, without any action of the > Diameter client? (I don't think so, but if you could confirm this, it would > be great!) I would assume that a Diameter client is a separate application > from a Diameter server even if they can be run on the same machine? Yes, they could run on the same machine. It is also possible for a server to contact a server, but that would be a strange case. The one that comes to mind is an authorization server that sends a separate request to an authentication server. Server 1 is the authorization server, and when it receives the answer from server 2, it sends back the successful response to the client. Now, this is a strange case, and isn't the typical deployment, so if you find this confusing, please disregard it. However, here's an example of the above. Server 1 is a Diameter server, and server 2 is a secureID server. Server 1 receives an EAP request, and forwards the secureID auth messages to server 2. Since current SecureID servers don't support Diameter, this isn't a real example, but is provided for illustrative purposes. > Thank you very much for your help! Well, I hope I did help, PatC From owner-aaa-wg@merit.edu Thu Jul 26 13:39:12 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24610 for ; Thu, 26 Jul 2001 13:39:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 94293912DE; Thu, 26 Jul 2001 13:07:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50B27912DB; Thu, 26 Jul 2001 13:07:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CA909132B for ; Thu, 26 Jul 2001 13:06:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 414B05DDC8; Thu, 26 Jul 2001 13:08:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by segue.merit.edu (Postfix) with SMTP id E78115DDA8 for ; Thu, 26 Jul 2001 13:08:57 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 26 Jul 2001 17:07:33 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010726185915.00d0e720@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 19:03:43 +0200 To: Pat Calhoun From: Jacques Caron Subject: Re: [AAA-WG]: clarification on Session connection vs. peer connection Cc: aaa-wg@merit.edu In-Reply-To: <20010726074520.L6433@charizard.diameter.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk At 16:45 26/07/01, Pat Calhoun wrote: > +--------+ +-------+ +--------+ > | Client | | Relay | | Server | > +--------+ +-------+ +--------+ > <----------> <----------> > Connection A Connection B > > <------------------------------> > Session x > >In the above example, Connection A is established between the Client and >its local Relay. This connection is essentially a transport level connection, >but we have some messages that are sent over that link for announcements >and keepalive purposes (CER/CEA and DWR/DWA, respectively). You can think >of a connection as a means to send messages to a peer. > >A session, on the other hand, is an application level thing. It is virtual, >meaning that there is nothing at the transport layer that refers to a >session. It is purely a Diameter thing. Each "user" of a service causes >an auth request to be sent, with a unique session identifier. Once accepted >by the server, both the client and the server are aware of the session. >To close the session, the client must sent a session termination message, >or the server can initiate a session to be terminated as well, using a >server-initiated message. I think something close to the above would be great somewhere early in the draft (somewhere in section 1 or 2), to clarify the notions of connections, sessions (though I'm not sure sessions is actually the right name here), peers, nodes, etc. Some additional definitions in 1.3 of the above concepts might not hurt either :-) BTW, I think this clearly reflects what I've been muttering about for a while about separating protocol from application-level stuff eheheh ;-> Nasty-Jacques. _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Thu Jul 26 13:42:32 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25130 for ; Thu, 26 Jul 2001 13:42:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2C8D912DD; Thu, 26 Jul 2001 13:14:12 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 884CA912DF; Thu, 26 Jul 2001 13:14:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 80859912DD for ; Thu, 26 Jul 2001 13:14:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3C9C65DDCE; Thu, 26 Jul 2001 13:16:11 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 845EB5DDA8 for ; Thu, 26 Jul 2001 13:16:10 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74756 for ; Thu, 26 Jul 2001 10:05:40 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:05:40 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-diameter-mobileip-07.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-diameter-mobileip-07.txt, "Diameter Mobile IPv4 Application". This document is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-daimeter-mobileip-07.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. After WG last call has passed, and WG comments have been incorporated, we will pass this document onto the IESG. From owner-aaa-wg@merit.edu Thu Jul 26 13:42:41 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25157 for ; Thu, 26 Jul 2001 13:42:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 22705912E0; Thu, 26 Jul 2001 13:03:49 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DBBE6912DF; Thu, 26 Jul 2001 13:03:48 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0367E912DC for ; Thu, 26 Jul 2001 13:02:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A47A65DDB2; Thu, 26 Jul 2001 13:04:35 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 2717E5DDA8 for ; Thu, 26 Jul 2001 13:04:35 -0400 (EDT) Received: (qmail 11977 invoked by uid 500); 26 Jul 2001 16:52:07 -0000 Date: Thu, 26 Jul 2001 09:52:07 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Jacques Caron'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Message-ID: <20010726095207.B6433@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Jacques Caron' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Thu, Jul 26, 2001 at 10:39:53AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Thu, Jul 26, 2001 at 10:39:53AM +0200, Martin Julien (ECE) wrote: > > At 18:43 25/07/01, Martin Julien (ECE) wrote: > > > > I had already submitted something along those lines in issue 83: > > > > - If multiple hosts listed for a given realm (redirect, > > > > relay, proxy), use > > > > the same one for a given Session (either need to maintain > > > > Session state or > > > > to use some hash function based on Session-ID) unless error > > > > occurs (and > > > > then keep that one that works). > > > > > >That is very interesting. Maybe something along those lines > > >should be mentionned in the draft, especially with regards > > >to selecting a consistent next-hop peer based on hashing of > > >the session-id. I'd like to see that in the draft, since it > > >would fix that problem. > > > > There's actually an issue, which is that if the set of peers > > that can serve > > a request change (one goes down, a new one is added...), then > > obviously the > > hashing changes, and requests might get sent to another peer. > > There must be > > some clever way to handle that, though, if I scratch my head > > a bit more :-) Why, exactly, is it necessary for the same path to be taken for a given session? Doing so will reduce the reliability of the protocol, since an agent that is no longer available wouldn't be able to be used. If some mechanism is used to failover all sessions to the unavailable server is designed, then you still have to support the case where state was lost. So, this is just half a fix, IMHO. The real fix is to write something to a backend database, no local memory, and that's no a protocol issue. > > > > > > Let me try to understand what you mean exactly... > > > > - first request of a session is sent without Agent-Route by client > > > > - proxies/relays add Agent-Route records along the way > > (same thing as > > > > Route-Record?) > > > > - server stores Agent-Route list, sends it in answer > > > > - answers are routed back using saved transaction state, with the > > > > Agent-Route AVPs unchanged > > > > - client stores Agent-Route AVPs. This sure sounds EXACTLY like the Route-Record AVP. > > > > > >No, my intention was to add the Agent-Route AVP only for the > > >proxies that need to keep a session-state. If a proxy or a > > >relay does not keep a session-state, then no Agent-Route AVP > > >should be added. > > > > Mmmm... This might not work. Imagine you have this: > > > > Client----Relay 1-------Relay 2------Proxy A------Relay 3-----Server > > | | > > +-----------Relay 4------Proxy B------Relay 5-------+ > > > > [stupid setup, but just for the example]. If only Proxy A > > says "please pick > > me rather than another proxy" (i.e. Proxy B), Relay 1 doesn't > > know that > > this means "go through Relay 2 rather than Relay 4". > > > > However, it looks a bit like one of the suggestions I had on > > the routing of > > unsolicited requests: > > >When a client sends a request to a server, it includes > > information on how > > >to establish a direct connection back (certificate...). > > >If at some point there is a breach in IP reachability, the > > proxy/relay > > >that acts as a gateway between the two routing domains > > includes an AVP > > >stating that unsolicited requests should go to it rather than to the > > >Origin-Host directly (possibly including certificate info of > > its own), and > > >it will send it to the client. This can possibly happen > > multiple times, of > > >course. It can also be used if a proxy wants to check/modify > > any request > > >that is sent to a client. The AVP might contain multiple > > DiameterIdenties > > >to provide redundancy. > > >If the request causes a change in the state of the session, > > the client > > >MUST send a regular request back to the server to update > > state in stateful > > >proxies (unless all these proxies add the "get it through > > me" AVP, which > > >might actually be the best solution). > > > > This actually means that you "bypass" some of the > > intermediate relays to go > > directly to the "significant" hops. Probably not a good idea. > > > > >However, your previous solution is much simpler to implement, > > >and still provide some kind of load-balancing. > > > > Well, in any case, load balancing occurs on the initial request in a > > session, and then subsequent requests should follow the same > > path (a bit > > like per-destination load balancing vs per-packet load-balancing on > > routers). And there is the issue above with "my solution". I > > think the > > solution below might actually be the simplest: > > > > >So the only change is actually to send the Route-Record list > > back to the > > >origin so that it can be used to source-route subsequent requests. > > >Proxies/relays should know that Route-Records in an Answer > > message are not > > >to be changed. > > > > It draws on the already-existing Route-Record & Source-route > > mechanism > > (with Alternates etc.) and requires just two changes: > > - server returns the full list of Route-Records in answer [it > > already saves > > it for unsolicited requests] > > - client saves it for future requests. And I suppose the issue is that the Route-Records AVPs are removed at each hop in the routing of the answer messages. > > Of course, the list from Route-Record AVPs are to be inserted as > > Source-Route AVPs in different orders depending on who is sending the > > request (client or server). > > I guess that the order the Route-Record AVPs is read through is > different for a request than for an answer, without necessary > changing the order in the message. That would mean that when > using those AVPs for routing, each node would have to go through > the list of routing AVPs to find its own identity, and then > follows the routing scheme. It seems to work, at the cost of > a slower routing process again. Right. I honestly don't understand the problem here. We are going out of our way to add complexity to support a really bad model. Randy Bush has stated time and time again, that we MUST NOT add complexity throughout the protocol to support proxies. They are evil, and while the protocol does support them, adding more complexity shouldn't be done. My 2 cents, PatC From owner-aaa-wg@merit.edu Thu Jul 26 13:42:45 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25180 for ; Thu, 26 Jul 2001 13:42:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3392591229; Thu, 26 Jul 2001 04:39:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEDE99122C; Thu, 26 Jul 2001 04:39:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D688A91229 for ; Thu, 26 Jul 2001 04:39:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE6135DDAD; Thu, 26 Jul 2001 04:41:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 4853E5DD9D for ; Thu, 26 Jul 2001 04:41:24 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6Q8e0O02363 for ; Thu, 26 Jul 2001 10:40:00 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Jul 26 10:39:59 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 10:39:55 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Jacques Caron'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state Date: Thu, 26 Jul 2001 10:39:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > At 18:43 25/07/01, Martin Julien (ECE) wrote: > > > I had already submitted something along those lines in issue 83: > > > - If multiple hosts listed for a given realm (redirect, > > > relay, proxy), use > > > the same one for a given Session (either need to maintain > > > Session state or > > > to use some hash function based on Session-ID) unless error > > > occurs (and > > > then keep that one that works). > > > >That is very interesting. Maybe something along those lines > >should be mentionned in the draft, especially with regards > >to selecting a consistent next-hop peer based on hashing of > >the session-id. I'd like to see that in the draft, since it > >would fix that problem. > > There's actually an issue, which is that if the set of peers > that can serve > a request change (one goes down, a new one is added...), then > obviously the > hashing changes, and requests might get sent to another peer. > There must be > some clever way to handle that, though, if I scratch my head > a bit more :-) > > > > Let me try to understand what you mean exactly... > > > - first request of a session is sent without Agent-Route by client > > > - proxies/relays add Agent-Route records along the way > (same thing as > > > Route-Record?) > > > - server stores Agent-Route list, sends it in answer > > > - answers are routed back using saved transaction state, with the > > > Agent-Route AVPs unchanged > > > - client stores Agent-Route AVPs. > > > >No, my intention was to add the Agent-Route AVP only for the > >proxies that need to keep a session-state. If a proxy or a > >relay does not keep a session-state, then no Agent-Route AVP > >should be added. > > Mmmm... This might not work. Imagine you have this: > > Client----Relay 1-------Relay 2------Proxy A------Relay 3-----Server > | | > +-----------Relay 4------Proxy B------Relay 5-------+ > > [stupid setup, but just for the example]. If only Proxy A > says "please pick > me rather than another proxy" (i.e. Proxy B), Relay 1 doesn't > know that > this means "go through Relay 2 rather than Relay 4". > > However, it looks a bit like one of the suggestions I had on > the routing of > unsolicited requests: > >When a client sends a request to a server, it includes > information on how > >to establish a direct connection back (certificate...). > >If at some point there is a breach in IP reachability, the > proxy/relay > >that acts as a gateway between the two routing domains > includes an AVP > >stating that unsolicited requests should go to it rather than to the > >Origin-Host directly (possibly including certificate info of > its own), and > >it will send it to the client. This can possibly happen > multiple times, of > >course. It can also be used if a proxy wants to check/modify > any request > >that is sent to a client. The AVP might contain multiple > DiameterIdenties > >to provide redundancy. > >If the request causes a change in the state of the session, > the client > >MUST send a regular request back to the server to update > state in stateful > >proxies (unless all these proxies add the "get it through > me" AVP, which > >might actually be the best solution). > > This actually means that you "bypass" some of the > intermediate relays to go > directly to the "significant" hops. Probably not a good idea. > > >However, your previous solution is much simpler to implement, > >and still provide some kind of load-balancing. > > Well, in any case, load balancing occurs on the initial request in a > session, and then subsequent requests should follow the same > path (a bit > like per-destination load balancing vs per-packet load-balancing on > routers). And there is the issue above with "my solution". I > think the > solution below might actually be the simplest: > > >So the only change is actually to send the Route-Record list > back to the > >origin so that it can be used to source-route subsequent requests. > >Proxies/relays should know that Route-Records in an Answer > message are not > >to be changed. > > It draws on the already-existing Route-Record & Source-route > mechanism > (with Alternates etc.) and requires just two changes: > - server returns the full list of Route-Records in answer [it > already saves > it for unsolicited requests] > - client saves it for future requests. > > Of course, the list from Route-Record AVPs are to be inserted as > Source-Route AVPs in different orders depending on who is sending the > request (client or server). I guess that the order the Route-Record AVPs is read through is different for a request than for an answer, without necessary changing the order in the message. That would mean that when using those AVPs for routing, each node would have to go through the list of routing AVPs to find its own identity, and then follows the routing scheme. It seems to work, at the cost of a slower routing process again. Martin > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Thu Jul 26 13:42:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25211 for ; Thu, 26 Jul 2001 13:42:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38E5F91320; Thu, 26 Jul 2001 12:16:25 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E60CE91325; Thu, 26 Jul 2001 12:16:24 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B185591320 for ; Thu, 26 Jul 2001 12:16:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 447FE5DDC8; Thu, 26 Jul 2001 12:18:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id DEF705DDC7 for ; Thu, 26 Jul 2001 12:18:21 -0400 (EDT) Received: (qmail 11303 invoked by uid 500); 26 Jul 2001 16:05:55 -0000 Date: Thu, 26 Jul 2001 09:05:55 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: API Issue Message-ID: <20010726090555.T6433@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010725215445.L23963@newman.frascone.com> <20010726084652.T23963@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010726084652.T23963@newman.frascone.com>; from dave@frascone.com on Thu, Jul 26, 2001 at 08:46:53AM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk Should we use the issues list to track API changes as well? BTW, there is another change required to the API. An application has no way to know when a session is termination. This could occur for the following reasons: 1. Internally generated due to authorization or session lifetime expiration. 2. Internally generated due to administrative reasons, or 3. server initiated Abort-Session-Request. So, perhaps when the AAAOpen() is called, the app should provide the callback function to receive disconnect indications? Thoughts? PatC On Thu, Jul 26, 2001 at 08:46:53AM -0500, David Frascone wrote: > On Wed, Jul 25, 2001 at 09:54:45PM -0500, David Frascone wrote: > > With the changes in the diameter base protocol draft (-06 and -07), it > > opens up some possible changes in the API. > > > > In the old api, you would simply create a new message via: > > > > AAANewMessage(commandCode, vendorId, sessionId, extensionId, &msg); > > > > The problem now is, requests and answers share the same command code. So, > > I see two ways to solve this: > > > > a) AAANewMessage(commandCode, vendorId, requestFlag, session id . . . yatta > > > > or > > > > b) A function to set the request bit: > > > > AAASetMessageAsResponse(AAAMessage *msg) > ^^^^^^^^ > > I meant request, of course. Twas late. > > > > AAASetMessageAsAnswer(AAAMessage *msg) > > > > > > Any preferences? > > > > I'm leaning towards style B. > > > > -Dave > > From owner-aaa-wg@merit.edu Thu Jul 26 13:42:50 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25234 for ; Thu, 26 Jul 2001 13:42:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F30AC912DC; Thu, 26 Jul 2001 13:12:06 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BC5B2912DD; Thu, 26 Jul 2001 13:12:05 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AC75B912DC for ; Thu, 26 Jul 2001 13:12:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 665C65DDD5; Thu, 26 Jul 2001 13:14:04 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A5A205DDCE for ; Thu, 26 Jul 2001 13:14:03 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id KAA74749; Thu, 26 Jul 2001 10:03:34 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 10:03:33 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Cc: aboba@internaut.com Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-transport-04.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is to announce AAA WG last call on draft-ietf-aaa-transport-04.txt, "AAA Transport Profile". This document is under consideration as an IETF Proposed Standard. The document is now available on the IETF archive as: http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt Please post your last call comments to the AAA WG mailing list as well as to the authors in the issue format that we have been using, prior to August 20, 2001. After WG last call has passed, and WG comments have been incorporated, we will pass this document onto the IESG. From owner-aaa-wg@merit.edu Thu Jul 26 14:41:18 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25233 for ; Thu, 26 Jul 2001 13:42:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 182079122E; Thu, 26 Jul 2001 10:25:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE0C391311; Thu, 26 Jul 2001 10:25:09 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AD5FB9122E for ; Thu, 26 Jul 2001 10:25:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 290C55DDC7; Thu, 26 Jul 2001 10:27:08 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mail.zrz.tu-berlin.de (mail.zrz.TU-Berlin.DE [130.149.4.15]) by segue.merit.edu (Postfix) with ESMTP id EFABC5DD91 for ; Thu, 26 Jul 2001 10:27:07 -0400 (EDT) Received: from ftsu07.ee.tu-berlin.de ([130.149.49.87] helo=ftmail.ee.tu-berlin.de) by mail.zrz.tu-berlin.de with esmtp (exim-3.31) for id 15Pm5A-0006gg-00; Thu, 26 Jul 2001 16:25:44 +0200 Received: from ee.tu-berlin.de (root@ftmail.ee.tu-berlin.de [130.149.49.250]) by ftmail.ee.tu-berlin.de (8.11.3/8.11.3) with ESMTP id f6QEPhh00726 for ; Thu, 26 Jul 2001 16:25:43 +0200 Message-ID: <3B6028DE.3A0937AA@ee.tu-berlin.de> Date: Thu, 26 Jul 2001 16:27:42 +0200 From: Guenter Schaefer X-Mailer: Mozilla 4.08 [en] (WinNT; I) MIME-Version: 1.0 To: AAA Mailinglist Subject: [AAA-WG]: [issue] Editorial changes concerning AVPs Destination-Host, MIP-Previous-FA-Host, MIP-Previous-FA-Addr Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Subject: [issue] Editorial changes concerning Destination-Host, Submitter name: Guenter Schaefer Submitter email address: schaefer@ee.tu-berlin.de Date first submitted: July 26, 2001 Reference: http://www.merit.edu/mail.archives/aaa-wg/msg01631.html http://www.merit.edu/mail.archives/aaa-wg/msg01591.html Document: Diameter Base Specification (I) and Mobile IPv4 Application (II) Comment type: ? Priority: ? Section: 6.6, 6.2, 5.3.2, 5.4.2, 5.5.2 in (I), 2.2, 2.4 in (II) 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II) Rationale/Explanation of issue: - There is an inconsistency regarding the Destination-Host AVP in the Diameter base protocol (I) and the Mobile IPv4 application (II) ("draft-ietf-aaa-diameter-07.txt", "draft-ietf-aaa-diameter-mobileip-07.txt"). Sections 6.2 and 6.6 of the base protocol specify that the Destination Host AVP MUST NOT be present in answer messages. However, the base protocol requires this AVP in the DPA and DWA messages and lists it as optional for the CEA message. The Mobile IPv4 application requires this AVP in the AMA and HAA messages. [sections 6.6, 6.2 5.4.2, 5.5.2, 5.3.2 in (I), 2.2, 2.4, in (II)] - The Mobile IPv4 application still mentions the AVPs MIP-Previous-FA-Host and MIP-Previous-FA-Addr even though fast handoff support has been postponed for further study. [sections 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)] Requested change: 1. EITHER change section 6.6 in the diameter base specification to "6.6 Destination-Host AVP The Destination-Host AVP (AVP Code 293) is of type DiameterIdentity. This AVP MUST be present in all unsolicited agent initiated messages, MAY be present in request messages, and MAY be present in Answer messages." and change section 6.2 in the base specification accordingly, OR delete the Destination-Host AVP from - the DPA, DWA and CEA messages in the base specification [sections 5.4.2, 5.5.2, 5.3.2 in (I)] - the AMA and HAA messages in the Mobile IPv4 application [sections 2.2, 2.4 in (II)] 2. In the Mobile IPv4 application all paragraphs concerning the AVPs MIP-Previous-FA-Host and MIP-Previous-FA-Addr should be deleted in order to reflect postponing of fast handoff support for further study. [sections 1.4, 2.1, 4.0. 4.5, 4.6, 8.1, 8.2 in (II)] ------------------------------------------------------------------------ Guenter Schaefer, Institute of Telecommunication Systems, Technical University of Berlin, Einsteinufer 25, 10587 Berlin, Germany, Phone: +49 30 314 23836, Fax: - 23818, Email: schaefer@ee.tu-berlin.de From owner-aaa-wg@merit.edu Thu Jul 26 14:41:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25212 for ; Thu, 26 Jul 2001 13:42:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 199319131A; Thu, 26 Jul 2001 11:24:48 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB0E991330; Thu, 26 Jul 2001 11:24:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0D7C59131A for ; Thu, 26 Jul 2001 11:23:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93AAC5DD91; Thu, 26 Jul 2001 11:25:02 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id F137C5DDC7 for ; Thu, 26 Jul 2001 11:25:01 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f6QFL8h11345; Thu, 26 Jul 2001 11:21:08 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from mailman(172.21.24.8) by ahab via smap (V2.1) id xma011341; Thu, 26 Jul 01 11:20:59 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f6QFNSR15888; Thu, 26 Jul 2001 11:23:28 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman via smap (V2.1) id xma015768; Thu, 26 Jul 01 11:22:23 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <3RZSJ129>; Thu, 26 Jul 2001 11:22:23 -0400 Message-ID: From: Yiwen Jiang To: "'Pat Calhoun'" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: clarification on Session connection vs. peer connec tion Date: Thu, 26 Jul 2001 11:22:14 -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-wg@merit.edu Precedence: bulk Hi Pat, Thanks very much for the mail... Just a few more questions. > I think that it is important to note that there is a huge > distinction between > a connection and a session. Let's consider the following diagram: > > +--------+ +-------+ +--------+ > | Client | | Relay | | Server | > +--------+ +-------+ +--------+ > <----------> <----------> > Connection A Connection B > > <------------------------------> > Session x > > In the above example, Connection A is established between the > Client and > its local Relay. This connection is essentially a transport > level connection, > but we have some messages that are sent over that link for > announcements > and keepalive purposes (CER/CEA and DWR/DWA, respectively). > You can think > of a connection as a means to send messages to a peer. So, in this picture, do you mean that client, relay, and server are all classified as Diameter peers? I guess this is one of the confusion I have. If Connection A is a peer-to-peer connection, then that implies that the relay can actually initiate a connection to the client? but when would this be the case? Isn't clients always initiate connection requests? Does this mean, for example, a NASREQ client will start up, and before it does anything, it will try to establish a peer-to-peer connection to an imediate Diameter server before it can handle any user requests? Also, does this mean, that before the client start session x, it must start a peer to peer connection first to the relay ? In Section 8.1, at the end of the state machine, it indicated a "Discon" as a new state in case of a few event, including the receiving of the ASR. But at the disconnect state, (the last line), it indicated cleanup. Are you referring to disconnect the peer connection? Or it must be the session "logical" disconnect then? > A session, on the other hand, is an application level thing. > It is virtual, > meaning that there is nothing at the transport layer that refers to a > session. It is purely a Diameter thing. Each "user" of a > service causes > an auth request to be sent, with a unique session identifier. > Once accepted > by the server, both the client and the server are aware of > the session. > To close the session, the client must sent a session > termination message, > or the server can initiate a session to be terminated as well, using a > server-initiated message. Got it. > > > Every time a session is initiated by a Diameter client, a > > TCP connection is initiated to the Diameter server. (So > there can be > 1 TCP > > connections between a Diameter client and Diameter server). > > If you use the logic above, then you'll realize that all sessions are > "multiplexed" through a single connection. In fact, the > protocol states that > there should only be a single connection between two peers. Yes. But I didn't realize that a Diameter client is classified as a "peer" here... (contradictory terms in my mind, but maybe that is just my English. :) > Well, peer-to-peer connections are used to transmit messages. > An implementation > MAY wish to process the message locally, relay or proxy the > message to a > peer. When a connection is suspicious, another peer is used. > So, there should > always be multiple possible peers, but it isn't necessary to have a > nailed up transport connection with all peers. I see. > > > > Diameter ----------------> Diameter -----------------> Diameter > > Client Server 1 > Server 2 > > > > session connection peer connection > > > > Is there any instances that the session based requests > actually is initiated > > from a Diameter server to another Diameter server, without > any action of the > > Diameter client? (I don't think so, but if you could > confirm this, it would > > be great!) I would assume that a Diameter client is a > separate application > > from a Diameter server even if they can be run on the same machine? > > Yes, they could run on the same machine. It is also possible > for a server > to contact a server, but that would be a strange case. The > one that comes to > mind is an authorization server that sends a separate request to an > authentication server. Server 1 is the authorization server, > and when it > receives the answer from server 2, it sends back the > successful response to > the client. Now, this is a strange case, and isn't the > typical deployment, > so if you find this confusing, please disregard it. So is the difference between Diameter client and Diameter server only on who initiates sessions ?? > > However, here's an example of the above. Server 1 is a > Diameter server, > and server 2 is a secureID server. Server 1 receives an EAP > request, and > forwards the secureID auth messages to server 2. Since > current SecureID > servers don't support Diameter, this isn't a real example, > but is provided > for illustrative purposes. Yes. I understand what you mean. From owner-aaa-wg@merit.edu Thu Jul 26 15:48:08 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07112 for ; Thu, 26 Jul 2001 15:48:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8AD4A9127B; Thu, 26 Jul 2001 15:48:11 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58B6B9128D; Thu, 26 Jul 2001 15:48:11 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CCA09127B for ; Thu, 26 Jul 2001 15:47:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E25E95DDAE; Thu, 26 Jul 2001 15:49:05 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 902A65DD9D for ; Thu, 26 Jul 2001 15:49:05 -0400 (EDT) Received: (qmail 12962 invoked by uid 500); 26 Jul 2001 19:36:37 -0000 Date: Thu, 26 Jul 2001 12:36:37 -0700 From: Pat Calhoun To: Jacques Caron Cc: Pat Calhoun , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Message-ID: <20010726123637.F6433@charizard.diameter.org> Mail-Followup-To: Jacques Caron , Pat Calhoun , "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> <577066326047D41180AC00508B955DDA04D1AA0B@eestqnt104.es.eu.ericsson.se> <20010726095207.B6433@charizard.diameter.org> <4.3.2.7.2.20010726190831.00c985d0@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20010726190831.00c985d0@pop.mail.yahoo.com>; from jacques_m_caron@yahoo.com on Thu, Jul 26, 2001 at 07:19:34PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk I'd like to get a rough idea from the WG on whether they believe this is a valid approach. Anyone else agree, disagree, don't care? PatC On Thu, Jul 26, 2001 at 07:19:34PM +0200, Jacques Caron wrote: > At 18:52 26/07/01, Pat Calhoun wrote: > >Why, exactly, is it necessary for the same path to be taken > >for a given session? Doing so will reduce the reliability of > >the protocol, since an agent that is no longer available wouldn't > >be able to be used. If some mechanism is used to failover all > >sessions to the unavailable server is designed, then you still > >have to support the case where state was lost. > > > >So, this is just half a fix, IMHO. The real fix is to write something > >to a backend database, no local memory, and that's no a protocol issue. > > Well, there are two cases: > - two (or more) agents in a load-balanced/failover setup > - two (or more) completely different paths via different administrative domains > > Let's consider this: > > ISP.NET client---ISP.NET proxy-----ROAMING1.NET proxy 1-----HOME.COM server > | | > +-------------ROAMING1.NET proxy 2---------+ > | | > +-------------ROAMING2.NET proxy 1---------+ > | | > +-------------ROAMING2.NET proxy 2---------+ > > The ISP.NET proxy can reach HOME.COM either via ROAMING1.net, or via > ROAMING2.NET. And both have two proxies. Picking any of the two proxies of > one or the other is OK (provided the two proxies keep "in sync" somehow). > But sending some stuff to ROAMING1.NET and some other to ROAMING2.NET might > not. > > > > > It draws on the already-existing Route-Record & Source-route > > > > mechanism > > > > (with Alternates etc.) and requires just two changes: > > > > - server returns the full list of Route-Records in answer [it > > > > already saves > > > > it for unsolicited requests] > > > > - client saves it for future requests. > > > >And I suppose the issue is that the Route-Records AVPs are removed at > >each hop in the routing of the answer messages. > > We removed this :-) We might just want to make it explicit that > Route-Records must be left unchanged (nothing added, nothing removed) when > routing answers. > > >Right. I honestly don't understand the problem here. We are going out > >of our way to add complexity to support a really bad model. Randy Bush > >has stated time and time again, that we MUST NOT add complexity throughout > >the protocol to support proxies. They are evil, and while the protocol > >does support them, adding more complexity shouldn't be done. > > I don't think it adds that much complexity. The only changes are: > 1. Server sends back the whole list of Route-Records it got in the answer > 2. Explicitly state that relays/proxies don't touch Route-Records in answers > 3. Client stores the list of Route-Records received in the latest answer > for a session > 4. Client uses this list as Source-Route AVPs in subsequent requests for > the same session. > 5. Explicitly state that proxies and relays ignore Destination-Host/Realm > AVPs if Source-Route AVPs are present. > > And even though proxies might be evil, they are THE fundamental part of the > whole global roaming architecture, don't you think? > > Jacques. > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > From owner-aaa-wg@merit.edu Thu Jul 26 16:20:57 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09447 for ; Thu, 26 Jul 2001 16:20:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABB95912E5; Thu, 26 Jul 2001 16:21:04 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F3D29132B; Thu, 26 Jul 2001 16:21:04 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4EDAD912E5 for ; Thu, 26 Jul 2001 16:21:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 463565DDB0; Thu, 26 Jul 2001 16:23:03 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D34225DD9D for ; Thu, 26 Jul 2001 16:23:02 -0400 (EDT) Received: (qmail 13101 invoked by uid 500); 26 Jul 2001 20:10:35 -0000 Date: Thu, 26 Jul 2001 13:10:35 -0700 From: Pat Calhoun To: "Marta Morant-Artazkotz (ECE)" Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments Message-ID: <20010726131035.L6433@charizard.diameter.org> Mail-Followup-To: "Marta Morant-Artazkotz (ECE)" , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA05D1C536@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA05D1C536@eestqnt104.es.eu.ericsson.se>; from Marta.Morant-Artazkotz@ece.ericsson.se on Tue, Jul 24, 2001 at 03:14:11PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry for the latency. See my response below. For any outstanding issues, please file an official issue and I'll have the changes taken care of in the next release. PatC On Tue, Jul 24, 2001 at 03:14:11PM +0200, Marta Morant-Artazkotz (ECE) wrote: > Hi, > - First of all, as a general comment, IMHO any reference to the "Domain Routing Table" should be change to "Realm Routing Table" and any reference to "domain" while talking about the key of this table should be changed to "realm". Those concepts are piggybacked, as the NAI rfc2486 states: "administration of the NAI realm namespace will piggyback on the administration of the DNS namespace", but they are not neccessary identical. ok, consistency would be a good thing, and the use of realm instead of domain can be made, assuming no one objects. This is really simply an editorial issue, so I don't expect any push back. > > - Status attribute of a Diameter peer > This attribute of a Diameter peer, an entry in the Peer Table, is described in section 2.6 to have the values listed in section 5.6 where the peer state machine is described. According to the description of peer connections made in sectio 5.1, I miss the "suspicious" state to describe a connection that might be broken but on which failover procedures has not been applied yet. IMHO, the values of the status in the Peer Control Block described section 5.5.3 should be added in the possible state values in the peer state machine. Per peer, there should be an entry in a table as described in 2.6, adding the state values in 5.5.3 to status and the flag and the related pending request queue. Yes, the values should be added, but as a separate field. We don't want to mix the state machine states with the peer status. I'll have to come up with some clever name :( > > - Oigin-State-Id AVP > In 8.16, page 94, it is stated that this AVP may be includeded in any Diameter message. IMHO, that means that [ Origin-State-Id ] should appear in all ABNF Diameter message definitions. In this draft, it does not appear in the Device Watchdog messages, nor *[ AVP ], perhaps attempting to make those messages simpler. The Device-Watchdog messages doesn't need this AVP, since a reboot will cause a loss of the transport connection, which will cause a subsequent reconnect, capabilities exchange, etc. It is useful in situations where there is a peer between two communicating nodes. > > - Session-Id AVP > In 7.2, page 79, there is the ABNF definition of the protocol-related error answer message with the line < Session-Id >. For request of the type per peer, non proxiable messages (the others are Capabilities Exchange and Device Watchdog messages), the aswer must not include the Session-Id AVP, must it? The anwer must contain Session-Id AVP only if it was included in the request, as it is satated in 5.2, page 44: "if the Session-Id is present in the request, it MUST be included in the answer". IMHO, this AVP should be left optional in the ABNF definition. Well, it simply means that if a command requires it in the request, then it MUST be present in the response. The non-proxiable messages you refer to above don't require the Session-Id because they aren't "session" related messages, but rather messages that are used for connection management. > > - Error-Reporting-Host AVP, > In 7.1, page 74, it is stated that "a non-successful Result-Code AVP (one containing a non 2xxx value) MUST include the Error-Reporting-Host AVP if the host setting the Result-Code AVP is different from the identity encoded in the Origin-Host AVP. IMHO, that means that this AVP should be included in any answer message. I miss it in the STA and ASA ABNF definitions in the base protocol draft. hmmmm... not at all. It means that if an intermediate proxy wants to change the Result-Code AVP (because of a locally generated auth failure), then it MUST inserts its identity in the Error-Reporting-Host AVP. This allows the access device and/or server to know who caused the failure. Thanks, PatC From owner-aaa-wg@merit.edu Thu Jul 26 16:38:53 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10527 for ; Thu, 26 Jul 2001 16:38:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BD6649132F; Thu, 26 Jul 2001 16:38:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8EB0391330; Thu, 26 Jul 2001 16:38:50 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 871D09132F for ; Thu, 26 Jul 2001 16:38:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7EE0B5DDD5; Thu, 26 Jul 2001 16:40:49 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D37375DDC9 for ; Thu, 26 Jul 2001 16:40:48 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA76738 for ; Thu, 26 Jul 2001 13:30:18 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 13:30:17 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Updated agenda for IETF 51 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Based on some recent changes, here is an updated agenda for IETF 51. If there are additional agenda items, please get these in NOW. ================================================================== AAA WG Agenda IETF 51, London, UK Wednesday, August 8, 2001 1300 - 1500 PRELIMINARIES (5 minutes) Agenda bashing Blue sheets Minute takers Document status DIAMETER ISSUES Open Diameter Issues (30 minutes) Pat Calhoun Documents now in AAA WG last call: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt 3G COMMENTS ON DIAMETER Diameter as a 3G Accounting Protocol (10 minutes) Thaddeus Kobylarz SUPPORT FOR MOBILE IPv6 Franck Le (10 minutes) Diameter support for Mobile IPv6 http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt Franck Le (10 minutes) AAA Local Security Association (LSA): The Temporary Shared Key (TSK) http://www.ietf.org/internet-drafts/draft-le-aaa-lsa-tsk-00.txt SUPPORT FOR SIP/HTTP AUTHENTICATION Jari Arkko (10 minutes) HTTP Authentication with EAP http://www.arkko.com/draft-torvinen-http-eap-00.txt Baruch Sterman (10 minutes) Digest Authentication in SIP using RADIUS http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-00.txt Sengodan Senthil (10 minutes) Diameter support for Basic and Digest authentication http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt WRAPUP Where do we go from here? (IESG, Chairs) (10 minutes) From owner-aaa-wg@merit.edu Thu Jul 26 19:05:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20390 for ; Thu, 26 Jul 2001 19:05:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B5EC9121F; Thu, 26 Jul 2001 19:05:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0B54891227; Thu, 26 Jul 2001 19:05:46 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8BC09121F for ; Thu, 26 Jul 2001 19:05:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0451A5DDD5; Thu, 26 Jul 2001 19:07:46 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id A4EF55DDC8 for ; Thu, 26 Jul 2001 19:07:45 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26398; Thu, 26 Jul 2001 16:06:19 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09921; Thu, 26 Jul 2001 16:05:58 -0700 (PDT) From: James Kempf Message-Id: <200107262305.QAA09921@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 16:02:25 -0700 To: "David Frascone" , Reply-To: Subject: Re: [AAA-WG]: API Issue X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Dave, >On Wed, Jul 25, 2001 at 09:54:45PM -0500, David Frascone wrote: >> With the changes in the diameter base protocol draft (-06 and -07), it >> opens up some possible changes in the API. >> >> In the old api, you would simply create a new message via: >> >> AAANewMessage(commandCode, vendorId, sessionId, extensionId, &msg); >> >> The problem now is, requests and answers share the same command code. So, >> I see two ways to solve this: >> >> a) AAANewMessage(commandCode, vendorId, requestFlag, session id . . . yatta >> >> or >> >> b) A function to set the request bit: >> >> AAASetMessageAsResponse(AAAMessage *msg) > ^^^^^^^^ > >I meant request, of course. Twas late. > > >> AAASetMessageAsAnswer(AAAMessage *msg) >> >> >> Any preferences? >> >> I'm leaning towards style B. >> Sounds fine to me. I think the Java API should already handle this in the library. jak From owner-aaa-wg@merit.edu Thu Jul 26 19:06:57 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20501 for ; Thu, 26 Jul 2001 19:06:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A64AF91227; Thu, 26 Jul 2001 19:06:43 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7848A91262; Thu, 26 Jul 2001 19:06:43 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 392DE91227 for ; Thu, 26 Jul 2001 19:06:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 660985DDD4; Thu, 26 Jul 2001 19:08:42 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 14D8E5DDC8 for ; Thu, 26 Jul 2001 19:08:42 -0400 (EDT) Received: from heliopolis.eng.sun.com ([152.70.1.39]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26866; Thu, 26 Jul 2001 16:07:17 -0700 (PDT) Received: from heliopolis.eng.sun.com (pacrimapp2.Singapore.Sun.COM [129.158.124.41]) by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09955; Thu, 26 Jul 2001 16:06:56 -0700 (PDT) From: James Kempf Message-Id: <200107262306.QAA09955@heliopolis.eng.sun.com> Date: Thu, 26 Jul 2001 16:03:23 -0700 To: "Pat Calhoun" , Reply-To: Subject: Re: [AAA-WG]: API Issue X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat, >Should we use the issues list to track API changes as well? > >BTW, there is another change required to the API. An application has no way >to know when a session is termination. This could occur for the following >reasons: > >1. Internally generated due to authorization or session lifetime expiration. >2. Internally generated due to administrative reasons, or >3. server initiated Abort-Session-Request. > >So, perhaps when the AAAOpen() is called, the app should provide the >callback function to receive disconnect indications? > I agree that a callback should be provided. The Java API takes care of this via the unsolicited message handler. jak From owner-aaa-wg@merit.edu Fri Jul 27 03:33:28 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28436 for ; Fri, 27 Jul 2001 03:33:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0E6FD91226; Fri, 27 Jul 2001 03:33:30 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CC7BA91232; Fri, 27 Jul 2001 03:33:29 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9993F91226 for ; Fri, 27 Jul 2001 03:33:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 640E05DDC4; Fri, 27 Jul 2001 03:35:29 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id AEE0B5DDB6 for ; Fri, 27 Jul 2001 03:35:28 -0400 (EDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6R7Y3N00171 for ; Fri, 27 Jul 2001 09:34:03 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Jul 27 09:34:00 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 09:33:59 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA11@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , Jacques Caron Cc: "Martin Julien (ECE)" , "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state Date: Fri, 27 Jul 2001 09:33:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, I must say that my opinion on this whole issue is that I much more preferred the former way of routing messages using the Destination-Realm and Destination-Host, especially for server-initiated messages. I liked it and thought it was plenty enough for our needs at this point. The problem was that the Source-Route AVPs were introduced in order to make sure that messages go through the same proxies during all the session. However, with the actual 07 draft, it is not possible to assure that all the requests from the client of the session will go through the same set of agents, which I think meant an incomplete solution for the problem that the Source-Route AVPS tried to solve. The real and fondamental question for this is: "Should the spec make sure that keeping Session-States in proxies is possible?" If you think it is important, the spec should support what Jacques has suggested. Otherwise, I would prefer coming back to the former and much simpler way of routing using Destination-Realm and Destination-Host AVPs, and that the spec does not mention that proxies might be expected to support session-state, unless with a propriatory solution. So, to be honest with you, we do not expect any of our agents up to now to be maintaining session states. I Hope it clarifies my point of view. Martin > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, July 26, 2001 9:37 PM > To: Jacques Caron > Cc: Pat Calhoun; Martin Julien (ECE); 'aaa-wg@merit.edu' > Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state > > > I'd like to get a rough idea from the WG on whether they believe this > is a valid approach. > > Anyone else agree, disagree, don't care? > > PatC > On Thu, Jul 26, 2001 at 07:19:34PM +0200, Jacques Caron wrote: > > At 18:52 26/07/01, Pat Calhoun wrote: > > >Why, exactly, is it necessary for the same path to be taken > > >for a given session? Doing so will reduce the reliability of > > >the protocol, since an agent that is no longer available wouldn't > > >be able to be used. If some mechanism is used to failover all > > >sessions to the unavailable server is designed, then you still > > >have to support the case where state was lost. > > > > > >So, this is just half a fix, IMHO. The real fix is to > write something > > >to a backend database, no local memory, and that's no a > protocol issue. > > > > Well, there are two cases: > > - two (or more) agents in a load-balanced/failover setup > > - two (or more) completely different paths via different > administrative domains > > > > Let's consider this: > > > > ISP.NET client---ISP.NET proxy-----ROAMING1.NET proxy > 1-----HOME.COM server > > | | > > +-------------ROAMING1.NET proxy 2---------+ > > | | > > +-------------ROAMING2.NET proxy 1---------+ > > | | > > +-------------ROAMING2.NET proxy 2---------+ > > > > The ISP.NET proxy can reach HOME.COM either via > ROAMING1.net, or via > > ROAMING2.NET. And both have two proxies. Picking any of the > two proxies of > > one or the other is OK (provided the two proxies keep "in > sync" somehow). > > But sending some stuff to ROAMING1.NET and some other to > ROAMING2.NET might > > not. > > > > > > > It draws on the already-existing Route-Record & Source-route > > > > > mechanism > > > > > (with Alternates etc.) and requires just two changes: > > > > > - server returns the full list of Route-Records in answer [it > > > > > already saves > > > > > it for unsolicited requests] > > > > > - client saves it for future requests. > > > > > >And I suppose the issue is that the Route-Records AVPs are > removed at > > >each hop in the routing of the answer messages. > > > > We removed this :-) We might just want to make it explicit that > > Route-Records must be left unchanged (nothing added, > nothing removed) when > > routing answers. > > > > >Right. I honestly don't understand the problem here. We > are going out > > >of our way to add complexity to support a really bad > model. Randy Bush > > >has stated time and time again, that we MUST NOT add > complexity throughout > > >the protocol to support proxies. They are evil, and while > the protocol > > >does support them, adding more complexity shouldn't be done. > > > > I don't think it adds that much complexity. The only changes are: > > 1. Server sends back the whole list of Route-Records it got > in the answer > > 2. Explicitly state that relays/proxies don't touch > Route-Records in answers > > 3. Client stores the list of Route-Records received in the > latest answer > > for a session > > 4. Client uses this list as Source-Route AVPs in subsequent > requests for > > the same session. > > 5. Explicitly state that proxies and relays ignore > Destination-Host/Realm > > AVPs if Source-Route AVPs are present. > > > > And even though proxies might be evil, they are THE > fundamental part of the > > whole global roaming architecture, don't you think? > > > > Jacques. > > > > > > _________________________________________________________ > > Do You Yahoo!? > > Get your free @yahoo.com address at http://mail.yahoo.com > > > From owner-aaa-wg@merit.edu Fri Jul 27 09:04:00 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14683 for ; Fri, 27 Jul 2001 09:04:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EEE491332; Fri, 27 Jul 2001 09:04:01 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D054F91334; Fri, 27 Jul 2001 09:04:00 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BC8A691332 for ; Fri, 27 Jul 2001 09:03:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15DEE5DDB2; Fri, 27 Jul 2001 09:06:01 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 7A64B5DD9E for ; Fri, 27 Jul 2001 09:06:00 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RD4ZO27865 for ; Fri, 27 Jul 2001 15:04:35 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 15:04:34 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 15:04:34 +0200 Message-ID: <577066326047D41180AC00508B955DDA05EAA077@eestqnt104.es.eu.ericsson.se> From: "Marta Morant-Artazkotz (ECE)" To: Pat Calhoun , "Marta Morant-Artazkotz (ECE)" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments Date: Fri, 27 Jul 2001 15:04:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi Pat, do not worry about the latency and thanks for your answer. Most of these comments were just editorial ones, things I missed in the ABNF definitios of the commnads. They are not very important while the concepts are clear but, as you say, it is nice to hace some consistency. Just as clarification, see enclosed commands. Best regards, Marta > -----Original Message----- > From: Pat Calhoun [mailto:pcalhoun@diameter.org] > Sent: Thursday, July 26, 2001 10:11 PM > To: Marta Morant-Artazkotz (ECE) > Cc: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments > > > Sorry for the latency. See my response below. For any > outstanding issues, > please file an official issue and I'll have the changes taken > care of in > the next release. > > PatC > > On Tue, Jul 24, 2001 at 03:14:11PM +0200, Marta > Morant-Artazkotz (ECE) wrote: > > Hi, > > - First of all, as a general comment, IMHO any reference to > the "Domain Routing Table" should be change to "Realm Routing > Table" and any reference to "domain" while talking about the > key of this table should be changed to "realm". Those > concepts are piggybacked, as the NAI rfc2486 states: > "administration of the NAI realm namespace will piggyback on > the administration of the DNS namespace", but they are not > neccessary identical. > > ok, consistency would be a good thing, and the use of realm > instead of domain > can be made, assuming no one objects. This is really simply > an editorial > issue, so I don't expect any push back. > > > > > - Status attribute of a Diameter peer > > This attribute of a Diameter peer, an entry in the Peer > Table, is described in section 2.6 to have the values listed > in section 5.6 where the peer state machine is described. > According to the description of peer connections made in > sectio 5.1, I miss the "suspicious" state to describe a > connection that might be broken but on which failover > procedures has not been applied yet. IMHO, the values of the > status in the Peer Control Block described section 5.5.3 > should be added in the possible state values in the peer > state machine. Per peer, there should be an entry in a table > as described in 2.6, adding the state values in 5.5.3 to > status and the flag and the related pending request queue. > > Yes, the values should be added, but as a separate field. We > don't want to mix > the state machine states with the peer status. I'll have to > come up with > some clever name :( > > > > > - Oigin-State-Id AVP > > In 8.16, page 94, it is stated that this AVP may be > includeded in any Diameter message. IMHO, that means that [ > Origin-State-Id ] should appear in all ABNF Diameter message > definitions. In this draft, it does not appear in the Device > Watchdog messages, nor *[ AVP ], perhaps attempting to make > those messages simpler. > > The Device-Watchdog messages doesn't need this AVP, since a > reboot will cause > a loss of the transport connection, which will cause a > subsequent reconnect, > capabilities exchange, etc. It is useful in situations where > there is a peer > between two communicating nodes. > > > > > - Session-Id AVP > > In 7.2, page 79, there is the ABNF definition of the > protocol-related error answer message with the line < > Session-Id >. For request of the type per peer, non proxiable > messages (the others are Capabilities Exchange and Device > Watchdog messages), the aswer must not include the Session-Id > AVP, must it? The anwer must contain Session-Id AVP only if > it was included in the request, as it is satated in 5.2, page > 44: "if the Session-Id is present in the request, it MUST be > included in the answer". IMHO, this AVP should be left > optional in the ABNF definition. > > Well, it simply means that if a command requires it in the > request, then it > MUST be present in the response. The non-proxiable messages > you refer to > above don't require the Session-Id because they aren't > "session" related > messages, but rather messages that are used for connection management. I agree. Because there are some request whose answers should have Session-Id and other that do not, I think Session-Id AVP should appear as optional in the ABNF definition of the protocol-related error message (a message that could be answer to any message, as I undertand it). I miss it there. > > - Error-Reporting-Host AVP, > > In 7.1, page 74, it is stated that "a non-successful > Result-Code AVP (one containing a non 2xxx value) MUST > include the Error-Reporting-Host AVP if the host setting the > Result-Code AVP is different from the identity encoded in the > Origin-Host AVP. IMHO, that means that this AVP should be > included in any answer message. I miss it in the STA and ASA > ABNF definitions in the base protocol draft. > > hmmmm... not at all. It means that if an intermediate proxy wants to > change the Result-Code AVP (because of a locally generated > auth failure), > then it MUST inserts its identity in the Error-Reporting-Host > AVP. This allows > the access device and/or server to know who caused the failure. I agree. Because intermediate proxies may change the Result-Code AVP and then insert the Error-Reporting-Host AVP, I think Error-Reporting-Host AVP should appear as optional in the ABNF definition of any answer message. I miss it in the STA and ASA messages. > > Thanks, > > PatC > From owner-aaa-wg@merit.edu Fri Jul 27 09:32:54 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17016 for ; Fri, 27 Jul 2001 09:32:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8B52091335; Fri, 27 Jul 2001 09:30:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0D2C991336; Fri, 27 Jul 2001 09:30:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E710591335 for ; Fri, 27 Jul 2001 09:30:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 455A35DDB2; Fri, 27 Jul 2001 09:32:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by segue.merit.edu (Postfix) with SMTP id AEF075DD9E for ; Fri, 27 Jul 2001 09:32:29 -0400 (EDT) Received: from pc188.etc.psi.com (HELO jc.yahoo.com) (195.94.40.188) by smtp.mail.vip.sc5.yahoo.com with SMTP; 27 Jul 2001 13:31:03 -0000 X-Apparently-From: Message-Id: <4.3.2.7.2.20010727140452.00c2bed0@pop.mail.yahoo.com> X-Sender: jacques_m_caron@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 27 Jul 2001 14:36:22 +0200 To: "Fredrik Johansson" From: Jacques Caron Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state Cc: "Martin Julien (ECE)" , "'Pat Calhoun'" , In-Reply-To: References: <577066326047D41180AC00508B955DDA04D1AA11@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi, I agree with Martin on the fact that either the same path must be taken in both directions, or there should be no provision for that at all. However, even though I have no particular idea about what applications might need proxies to keep session state, that's a stated requirement for proxies, as far as I understand it. And seeing what happens in e.g. HTTP load balancers etc, there clearly is a need to have persistency to a given host (I do agree it's stupid and that people should rely on a common back-end, but there are many issues with that, including performance, etc.). Many people might be OK with two hosts not being "in sync" (via a back-end database or the exchange of "mirroring" information), and lose state in case of a host failure only (it's a matter of how much you are willing to "lose" in the event of a failure vs how much it costs to implement a given level of redundancy). And then we need to make sure the path is kept. This simply means that the first request in a session is Destination-Realm/Host-routed, while all the subsequent ones are Source-Routed onto the path captured on this first request. Note also that there are already provisions for hosts going down (Alternate-Host AVPs). Finally, I think there is (was?) already something very similar with the use of Destination-Host in subsequent requests for the same session, actually. We're just extending and generalizing that to all hops on the path rather than just the last one. Jacques. At 13:41 27/07/01, Fredrik Johansson wrote: >Hi all, > >I agree with Martin. I prefer to go back to the old way of routing. Why >should it be different in the backward direction than in the forward >direction? It would make the protocol a lot simpler if we route on >destination-host and realm in both directions. And also less vulnerable to >host going down. > >my 2c > >/Fredrik > > >-----Original Message----- > >From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of > >Martin Julien (ECE) > >Sent: den 27 juli 2001 09:34 > >To: 'Pat Calhoun'; Jacques Caron > >Cc: Martin Julien (ECE); 'aaa-wg@merit.edu' > >Subject: RE: [AAA-WG]: Issue 97: Proxies keeping a session-state > > > > > >Hi Pat, > > > >I must say that my opinion on this whole issue is that I much more > >preferred the former way of routing messages using the Destination-Realm > >and Destination-Host, especially for server-initiated messages. I > >liked it and thought it was plenty enough for our needs at this > >point. > > > >The problem was that the Source-Route AVPs were introduced > >in order to make sure that messages go through the same proxies > >during all the session. However, with the actual 07 draft, it is > >not possible to assure that all the requests from the client of > >the session will go through the same set of agents, which I think > >meant an incomplete solution for the problem that the Source-Route > >AVPS tried to solve. > > > >The real and fondamental question for this is: "Should the spec > >make sure that keeping Session-States in proxies is possible?" > >If you think it is important, the spec should support > >what Jacques has suggested. Otherwise, I would prefer coming back > >to the former and much simpler way of routing using > >Destination-Realm and Destination-Host AVPs, and that the spec > >does not mention that proxies might be expected to support > >session-state, unless with a propriatory solution. > > > >So, to be honest with you, we do not expect any of our agents up > >to now to be maintaining session states. > > > >I Hope it clarifies my point of view. > >Martin > > > >> -----Original Message----- > >> From: Pat Calhoun [mailto:pcalhoun@diameter.org] > >> Sent: Thursday, July 26, 2001 9:37 PM > >> To: Jacques Caron > >> Cc: Pat Calhoun; Martin Julien (ECE); 'aaa-wg@merit.edu' > >> Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state > >> > >> > >> I'd like to get a rough idea from the WG on whether they believe this > >> is a valid approach. > >> > >> Anyone else agree, disagree, don't care? > >> > >> PatC > >> On Thu, Jul 26, 2001 at 07:19:34PM +0200, Jacques Caron wrote: > >> > At 18:52 26/07/01, Pat Calhoun wrote: > >> > >Why, exactly, is it necessary for the same path to be taken > >> > >for a given session? Doing so will reduce the reliability of > >> > >the protocol, since an agent that is no longer available wouldn't > >> > >be able to be used. If some mechanism is used to failover all > >> > >sessions to the unavailable server is designed, then you still > >> > >have to support the case where state was lost. > >> > > > >> > >So, this is just half a fix, IMHO. The real fix is to > >> write something > >> > >to a backend database, no local memory, and that's no a > >> protocol issue. > >> > > >> > Well, there are two cases: > >> > - two (or more) agents in a load-balanced/failover setup > >> > - two (or more) completely different paths via different > >> administrative domains > >> > > >> > Let's consider this: > >> > > >> > ISP.NET client---ISP.NET proxy-----ROAMING1.NET proxy > >> 1-----HOME.COM server > >> > | | > >> > +-------------ROAMING1.NET proxy 2---------+ > >> > | | > >> > +-------------ROAMING2.NET proxy 1---------+ > >> > | | > >> > +-------------ROAMING2.NET proxy 2---------+ > >> > > >> > The ISP.NET proxy can reach HOME.COM either via > >> ROAMING1.net, or via > >> > ROAMING2.NET. And both have two proxies. Picking any of the > >> two proxies of > >> > one or the other is OK (provided the two proxies keep "in > >> sync" somehow). > >> > But sending some stuff to ROAMING1.NET and some other to > >> ROAMING2.NET might > >> > not. > >> > > >> > > > > It draws on the already-existing Route-Record & Source-route > >> > > > > mechanism > >> > > > > (with Alternates etc.) and requires just two changes: > >> > > > > - server returns the full list of Route-Records in answer [it > >> > > > > already saves > >> > > > > it for unsolicited requests] > >> > > > > - client saves it for future requests. > >> > > > >> > >And I suppose the issue is that the Route-Records AVPs are > >> removed at > >> > >each hop in the routing of the answer messages. > >> > > >> > We removed this :-) We might just want to make it explicit that > >> > Route-Records must be left unchanged (nothing added, > >> nothing removed) when > >> > routing answers. > >> > > >> > >Right. I honestly don't understand the problem here. We > >> are going out > >> > >of our way to add complexity to support a really bad > >> model. Randy Bush > >> > >has stated time and time again, that we MUST NOT add > >> complexity throughout > >> > >the protocol to support proxies. They are evil, and while > >> the protocol > >> > >does support them, adding more complexity shouldn't be done. > >> > > >> > I don't think it adds that much complexity. The only changes are: > >> > 1. Server sends back the whole list of Route-Records it got > >> in the answer > >> > 2. Explicitly state that relays/proxies don't touch > >> Route-Records in answers > >> > 3. Client stores the list of Route-Records received in the > >> latest answer > >> > for a session > >> > 4. Client uses this list as Source-Route AVPs in subsequent > >> requests for > >> > the same session. > >> > 5. Explicitly state that proxies and relays ignore > >> Destination-Host/Realm > >> > AVPs if Source-Route AVPs are present. > >> > > >> > And even though proxies might be evil, they are THE > >> fundamental part of the > >> > whole global roaming architecture, don't you think? > >> > > >> > Jacques. > >> > > >> > > >> > _________________________________________________________ > >> > Do You Yahoo!? > >> > Get your free @yahoo.com address at http://mail.yahoo.com > >> > > >> _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-aaa-wg@merit.edu Fri Jul 27 10:10:55 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19757 for ; Fri, 27 Jul 2001 10:10:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8C9591337; Fri, 27 Jul 2001 10:08:15 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7647791338; Fri, 27 Jul 2001 10:08:15 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9F33091337 for ; Fri, 27 Jul 2001 10:08:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0D9695DDC6; Fri, 27 Jul 2001 10:10:12 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id AA0405DDC3 for ; Fri, 27 Jul 2001 10:10:11 -0400 (EDT) Received: (qmail 16540 invoked by uid 500); 27 Jul 2001 13:57:40 -0000 Date: Fri, 27 Jul 2001 06:57:40 -0700 From: Pat Calhoun To: "Marta Morant-Artazkotz (ECE)" Cc: Pat Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-07.txt first comments Message-ID: <20010727065740.P13541@charizard.diameter.org> Mail-Followup-To: "Marta Morant-Artazkotz (ECE)" , Pat Calhoun , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA05EAA077@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA05EAA077@eestqnt104.es.eu.ericsson.se>; from Marta.Morant-Artazkotz@ece.ericsson.se on Fri, Jul 27, 2001 at 03:04:32PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > > Well, it simply means that if a command requires it in the > > request, then it > > MUST be present in the response. The non-proxiable messages > > you refer to > > above don't require the Session-Id because they aren't > > "session" related > > messages, but rather messages that are used for connection management. > > I agree. Because there are some request whose answers should have Session-Id and other that do not, I think Session-Id AVP should appear as optional in the ABNF definition of the protocol-related error message (a message that could be answer to any message, as I undertand it). I miss it there. I don't quite understand your point. The messages that do not include the Session-Id actually do not need it, so adding it as optional would cause confusion. > > hmmmm... not at all. It means that if an intermediate proxy wants to > > change the Result-Code AVP (because of a locally generated > > auth failure), > > then it MUST inserts its identity in the Error-Reporting-Host > > AVP. This allows > > the access device and/or server to know who caused the failure. > > I agree. Because intermediate proxies may change the Result-Code AVP and then insert the Error-Reporting-Host AVP, I think Error-Reporting-Host AVP should appear as optional in the ABNF definition of any answer message. I miss it in the STA and ASA messages. Ah, ok then this should be raised in an official issue. In fact, include all of your editorial changes in a single issue, and submit it. That's less work for both of us :) PatC From owner-aaa-wg@merit.edu Fri Jul 27 10:11:37 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19864 for ; Fri, 27 Jul 2001 10:11:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2221791338; Fri, 27 Jul 2001 10:11:41 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DF80A91339; Fri, 27 Jul 2001 10:11:40 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3166A91338 for ; Fri, 27 Jul 2001 10:11:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9616D5DDCB; Fri, 27 Jul 2001 10:13:40 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 06F7D5DDC6 for ; Fri, 27 Jul 2001 10:13:40 -0400 (EDT) Received: (qmail 16571 invoked by uid 500); 27 Jul 2001 14:01:08 -0000 Date: Fri, 27 Jul 2001 07:01:08 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , Jacques Caron , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Message-ID: <20010727070108.Q13541@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , Jacques Caron , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA11@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA11@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Jul 27, 2001 at 09:33:54AM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jul 27, 2001 at 09:33:54AM +0200, Martin Julien (ECE) wrote: > I must say that my opinion on this whole issue is that I much more > preferred the former way of routing messages using the Destination-Realm > and Destination-Host, especially for server-initiated messages. I > liked it and thought it was plenty enough for our needs at this > point. Me too, and I stated on the list that was my preference (and others in the design team). I sent a mail to the list, requesting that without the change I proposed, it would require additional configuration that doesn't existing in today's networks, and I didn't think this was much of an issue. I proposed text, and asked for folks to shoot it down, and no one did, so the text got included in the base spec :( > The problem was that the Source-Route AVPs were introduced > in order to make sure that messages go through the same proxies > during all the session. However, with the actual 07 draft, it is > not possible to assure that all the requests from the client of > the session will go through the same set of agents, which I think > meant an incomplete solution for the problem that the Source-Route > AVPS tried to solve. Well, the solution also allows for alternates to be used, should an agent no longer be reachable. > The real and fondamental question for this is: "Should the spec > make sure that keeping Session-States in proxies is possible?" Good question. > If you think it is important, the spec should support > what Jacques has suggested. Otherwise, I would prefer coming back > to the former and much simpler way of routing using > Destination-Realm and Destination-Host AVPs, and that the spec > does not mention that proxies might be expected to support > session-state, unless with a propriatory solution. Right, and proprietary hacks will always exist. The real question is how far out of our way do we need to go to support proxies. Randy says very little, other folks say all the way. > So, to be honest with you, we do not expect any of our agents up > to now to be maintaining session states. good :) PatC From owner-aaa-wg@merit.edu Fri Jul 27 10:12:27 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20032 for ; Fri, 27 Jul 2001 10:12:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11FBC91339; Fri, 27 Jul 2001 10:12:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D362E9133A; Fri, 27 Jul 2001 10:12:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB4F591339 for ; Fri, 27 Jul 2001 10:12:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1499F5DDC6; Fri, 27 Jul 2001 10:14:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 7BD9B5DDC3 for ; Fri, 27 Jul 2001 10:14:30 -0400 (EDT) Received: (qmail 16588 invoked by uid 500); 27 Jul 2001 14:01:59 -0000 Date: Fri, 27 Jul 2001 07:01:59 -0700 From: Pat Calhoun To: Fredrik Johansson Cc: "Martin Julien (ECE)" , "'Pat Calhoun'" , Jacques Caron , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Issue 97: Proxies keeping a session-state Message-ID: <20010727070159.R13541@charizard.diameter.org> Mail-Followup-To: Fredrik Johansson , "Martin Julien (ECE)" , 'Pat Calhoun' , Jacques Caron , aaa-wg@merit.edu References: <577066326047D41180AC00508B955DDA04D1AA11@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from fredrik@ipunplugged.com on Fri, Jul 27, 2001 at 01:41:06PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk > I agree with Martin. I prefer to go back to the old way of routing. Why > should it be different in the backward direction than in the forward > direction? It would make the protocol a lot simpler if we route on > destination-host and realm in both directions. And also less vulnerable to > host going down. Well, it would have been nice to hear that when I asked the WG, instead of after no one responded and I included the new text in the spec. Perhaps we can discuss this in London. PatC From owner-aaa-wg@merit.edu Fri Jul 27 10:51:42 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23798 for ; Fri, 27 Jul 2001 10:51:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1849B91206; Fri, 27 Jul 2001 10:51:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC6299133E; Fri, 27 Jul 2001 10:51:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5A9F91206 for ; Fri, 27 Jul 2001 10:51:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3175F5DDB1; Fri, 27 Jul 2001 10:53:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 90FF85DD9E for ; Fri, 27 Jul 2001 10:53:44 -0400 (EDT) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6REqJO16680 for ; Fri, 27 Jul 2001 16:52:19 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Jul 27 16:52:18 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 16:52:17 +0200 Message-ID: <3DFC2DB418B2D211A1950008C7A4E1EA611FD4@eestqnt102> From: "Guillermo Guardia-Lozano (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Accounting question Date: Fri, 27 Jul 2001 16:52:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Hello, One single question related to accounting that maybe someone can answer. When a client uses both authentication and accounting services, there are two flows of messages related to the same Session-Id one for authentication/authorization (AuthenReq->answer->ReAuthenReq->answer....STR->STA) and other for accounting (ACR-start->ACA->ACR-Interim->ACA->...->ACR-Stop->ACA) The question is: from the point of view of the Home Server these flows can be considered independant or on the contrary accounting flow must be always tied to the authen/author flow ? Is it a MUST for the Diameter client, to sent all the accounting messages related to a session (and wait for the successful answer from the Diameter server), before sending the Session Termination Request message ? A sequence like the following one must be always expected ?, .. OR ... for instance one like this could be also possible ? client Home Server client Home Server | | | | | Authen/Autho REQUEST | | Authen/Autho REQUEST | |------------------------------->| |------------------------------->| | ANSWER | | ANSWER | |<-------------------------------| |<-------------------------------| | ACR START | | ACR START | |------------------------------->| |------------------------------->| | ACA | | ACA | .. interims .. .. interims .. | ACR STOP | | STR | |------------------------------->| |------------------------------->| | ACA | | STA | |<-------------------------------| |<-------------------------------| | STR | | ACR STOP | |------------------------------->| |------------------------------->| | STA | | ACA | |<-------------------------------| |<-------------------------------| | | | | Thanks From owner-aaa-wg@merit.edu Fri Jul 27 11:38:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28232 for ; Fri, 27 Jul 2001 11:38:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B5DAD9121E; Fri, 27 Jul 2001 11:38:18 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 83C1B9123C; Fri, 27 Jul 2001 11:38:18 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AC2E9121E for ; Fri, 27 Jul 2001 11:38:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD01D5DDBA; Fri, 27 Jul 2001 11:40:18 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 516A65DDB3 for ; Fri, 27 Jul 2001 11:40:18 -0400 (EDT) Received: (qmail 20325 invoked by uid 500); 27 Jul 2001 15:27:47 -0000 Date: Fri, 27 Jul 2001 08:27:47 -0700 From: Pat Calhoun To: "Guillermo Guardia-Lozano (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Accounting question Message-ID: <20010727082746.A13541@charizard.diameter.org> Mail-Followup-To: "Guillermo Guardia-Lozano (ECE)" , "'aaa-wg@merit.edu'" References: <3DFC2DB418B2D211A1950008C7A4E1EA611FD4@eestqnt102> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3DFC2DB418B2D211A1950008C7A4E1EA611FD4@eestqnt102>; from guillermo.guardia-lozano@ece.ericsson.se on Fri, Jul 27, 2001 at 04:52:03PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Fri, Jul 27, 2001 at 04:52:03PM +0200, Guillermo Guardia-Lozano (ECE) wrote: > Hello, > One single question related to accounting that maybe someone can answer. > > When a client uses both authentication and accounting services, there are two flows of messages > related to the same Session-Id one for authentication/authorization (AuthenReq->answer->ReAuthenReq->answer....STR->STA) and other for accounting (ACR-start->ACA->ACR-Interim->ACA->...->ACR-Stop->ACA) > The question is: > from the point of view of the Home Server these flows can be considered independant > or on the contrary accounting flow must be always tied to the authen/author > flow ? Accounting can be done without any authentication and/or authorization. There is a state machine for accounting only applications. > Is it a MUST for the Diameter client, to sent all the accounting messages related to a session (and wait for the successful answer > from the Diameter server), before sending the Session Termination Request message ? It would be a REALLY good idea, but I am not sure that we can enforce that :( > A sequence like the following one must be always expected ?, .. OR ... for instance one like this could be also possible ? > > client Home Server client Home Server > | | | | > | Authen/Autho REQUEST | | Authen/Autho REQUEST | > |------------------------------->| |------------------------------->| > | ANSWER | | ANSWER | > |<-------------------------------| |<-------------------------------| > > | ACR START | | ACR START | > |------------------------------->| |------------------------------->| > | ACA | | ACA | > .. interims .. .. interims .. > > | ACR STOP | | STR | > |------------------------------->| |------------------------------->| > | ACA | | STA | > |<-------------------------------| |<-------------------------------| > > | STR | | ACR STOP | > |------------------------------->| |------------------------------->| > | STA | | ACA | > |<-------------------------------| |<-------------------------------| > | | | | That would be my preferred approach, but again, it isn't mandatory. PatC From owner-aaa-wg@merit.edu Fri Jul 27 12:15:41 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02218 for ; Fri, 27 Jul 2001 12:15:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC1A091340; Fri, 27 Jul 2001 12:13:36 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D23D9134A; Fri, 27 Jul 2001 12:13:36 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23A8591340 for ; Fri, 27 Jul 2001 12:13:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A980D5DDB1; Fri, 27 Jul 2001 12:15:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id DF5855DD9E for ; Fri, 27 Jul 2001 12:15:32 -0400 (EDT) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6RGE7O08070 for ; Fri, 27 Jul 2001 18:14:07 +0200 (MEST) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Jul 27 18:14:07 2001 +0200 Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 18:14:06 +0200 Message-ID: <577066326047D41180AC00508B955DDA04D1AA15@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Pat Calhoun'" , "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" Subject: RE: [AAA-WG]: Issue 98: Peer role in Peer table? Date: Fri, 27 Jul 2001 18:14:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk > hmmm.... now I'm really upset that I was convinced to remove > all of the > verbage that I had originally proposed :( > > See my comments below. > > On Thu, Jul 26, 2001 at 10:31:29AM +0200, Martin Julien (ECE) wrote: > > I guess that it suggests that the DRT should return a > > list of servers, which should be looked into to find out > > whether one of them is primary and available? If not, > > then a secondary server is searched for. That means that > > load-balancing would occur only if several servers with > > the same role are defined for the DRT entry. Does that > > mean that the Diameter node needs to make sure that > > for all DRT entry, there is at least 2 servers available > > all the time, I guess that is what it comes down to, right? > > A peer could be marked as primary, but this isn't really necessary. > A DRT lookup could return multiple servers, and if they aren't > marked with any form of priority, then some mechanism should > be employed > to determine which one should become primary. The same is done for > the secondary. It is recommended that there be at least 2 possible > servers for a given realm, but this isn't mandatory (of > course, without > it you have no failover capabilities). > > > > > That would mean that when a Peer becomes suspect, then the > > DRT has to be looked into in order to find out which DRT > > entry is affected in order to possibly initiate a new > > connection to another host????? > > Well, that's why you typically want a secondary up and available. > So, if you have a secondary connection, should the primary become > suspicious, you can start sending messages to the secondary right > away. > > However, this is not a function of the routing table, but > rather of the > peer table. > > > Also, when receiving the Alternate-peer AVPs in the > > CER/CEA, should one of them be defined as secondary, while > > the others as alternate?, unless they are already defined > > as primary or secondary, of course. The reason for this > > being that for routing based on Route-Record, Source-Route > > and Destination-Host, I guess it would also be nice to > > have to same kind on feature, no? > > well, perhaps the language here is mixed up. Alternates, as defined > in the CER/CEA is ONLY for server-initiated messages, and not for > determining which peer is primary/secondary/alternate. OK, let's move aside this primary/secondary/alternate question and concentrate on the Alternate-Peer AVP thing. So, if I understand correctly, this new AVP was introduced only for the purpose of the Source-Route AVP, am I right? So, if I were an administrator of a Diameter proxy, then I would have to configure the DRT so that messages are routed based on realms to the next peer. If that peer fails, messages would be forwarded to another server from the list defined in the DRT for that realm, right? Of course, among the list of primary or secondary list of servers... When the answer is returned, and an agent of the list of Route-Records is down, then it is impossible to route the answer. That means that the originator of the request should be expected to re-send the same message. For server-initiated messages, if Destination-Realm and Destination-Host is used, then the same scenario as before in the last 2 par. is applied. For server-initiated messages, if the Source-Route AVPs are used, then the administrator needs to configure for the local node a possible list of Alternate-Peers, which are probably a duplicate information of the list of servers defined in the DRT entries of the surrounding nodes, BTW. That is weird to me. Should all Alternate-Peers be considered as secondary, since they would be used in case the node fails? I guess yes. I still find this really messy...maybe because it's friday... Note that there should not exist alternates nodes defined for clients and servers, since the Alternate-Peer AVP is not used to indicate redundant nodes. That means that Alternate-Peer AVP should not be used for servers and clients, as far as I understand. Otherwise, I don't know why we should be restricted from using it for the last HOP of the request as well, i.e. Destination-Host? Here is an idea about the Alternate-Peer... The thing is that with the Destination-Realm and Destination-Host solution, the takeover node was handled by the DRT, which was returning a list of servers. The only problem was that nothing could indicate a redundant server or client in the DRT, since that information should be stored in the Peer table. I think it is an interesting feature, but different then the original intention you had. So, could't it be used for finding a redundant server or client host as well? I mean that I would prefer seeing clients and servers use it when they support back-end redundancy between 2 hosts, e.g. a NAS 1 and NAS 2 are redundant in traffic, which means that they would use the Alternate-Peer AVP to inform the other nodes that they are considered as the same node. That would mean that each node would have to support 2 host-Id. Otherwise, this AVP should not be used for a client, neither for a Home server. The same concept as the one described previously could also apply to routing the answers, based on Route-Record AVPs. With that new definition, the Alternate-Peer could be renamed Redundant-Peer AVP. > > > So, as I see it, it is quite a lot of work to support this > > concept of connections, from a point of view of a Diameter > > agent and server, at least. Since I am not really sure > > up to what point agents are expected to have openned > > connections, I am wondering if this is really something > > important for Diameter nodes? > > Absolutely. However, if you prefer to not include any failover > code in your implementation, then that's your perogative. > > PatC > From owner-aaa-wg@merit.edu Fri Jul 27 12:41:10 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05082 for ; Fri, 27 Jul 2001 12:41:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 341D291343; Fri, 27 Jul 2001 12:40:50 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0549691344; Fri, 27 Jul 2001 12:40:49 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9497C91343 for ; Fri, 27 Jul 2001 12:40:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1FD175DDAF; Fri, 27 Jul 2001 12:42:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 919DE5DD9E for ; Fri, 27 Jul 2001 12:42:49 -0400 (EDT) Received: (qmail 21607 invoked by uid 500); 27 Jul 2001 16:30:17 -0000 Date: Fri, 27 Jul 2001 09:30:17 -0700 From: Pat Calhoun To: "Martin Julien (ECE)" Cc: "'Pat Calhoun'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Issue 98: Peer role in Peer table? Message-ID: <20010727093017.H13541@charizard.diameter.org> Mail-Followup-To: "Martin Julien (ECE)" , 'Pat Calhoun' , "'aaa-wg@merit.edu'" References: <577066326047D41180AC00508B955DDA04D1AA15@eestqnt104.es.eu.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <577066326047D41180AC00508B955DDA04D1AA15@eestqnt104.es.eu.ericsson.se>; from Martin.Julien@ece.ericsson.se on Fri, Jul 27, 2001 at 06:14:04PM +0200 Sender: owner-aaa-wg@merit.edu Precedence: bulk Martin, I believe that your comments below simply demonstrate that we shouldn't have adopted a new scheme for server-initiated messages, and should have relied on assuming that the configuration that is necessary for the forwarding of messages towards the server needs to be correct. sigh. PatC On Fri, Jul 27, 2001 at 06:14:04PM +0200, Martin Julien (ECE) wrote: > > hmmm.... now I'm really upset that I was convinced to remove > > all of the > > verbage that I had originally proposed :( > > > > See my comments below. > > > > On Thu, Jul 26, 2001 at 10:31:29AM +0200, Martin Julien (ECE) wrote: > > > I guess that it suggests that the DRT should return a > > > list of servers, which should be looked into to find out > > > whether one of them is primary and available? If not, > > > then a secondary server is searched for. That means that > > > load-balancing would occur only if several servers with > > > the same role are defined for the DRT entry. Does that > > > mean that the Diameter node needs to make sure that > > > for all DRT entry, there is at least 2 servers available > > > all the time, I guess that is what it comes down to, right? > > > > A peer could be marked as primary, but this isn't really necessary. > > A DRT lookup could return multiple servers, and if they aren't > > marked with any form of priority, then some mechanism should > > be employed > > to determine which one should become primary. The same is done for > > the secondary. It is recommended that there be at least 2 possible > > servers for a given realm, but this isn't mandatory (of > > course, without > > it you have no failover capabilities). > > > > > > > > That would mean that when a Peer becomes suspect, then the > > > DRT has to be looked into in order to find out which DRT > > > entry is affected in order to possibly initiate a new > > > connection to another host????? > > > > Well, that's why you typically want a secondary up and available. > > So, if you have a secondary connection, should the primary become > > suspicious, you can start sending messages to the secondary right > > away. > > > > However, this is not a function of the routing table, but > > rather of the > > peer table. > > > > > Also, when receiving the Alternate-peer AVPs in the > > > CER/CEA, should one of them be defined as secondary, while > > > the others as alternate?, unless they are already defined > > > as primary or secondary, of course. The reason for this > > > being that for routing based on Route-Record, Source-Route > > > and Destination-Host, I guess it would also be nice to > > > have to same kind on feature, no? > > > > well, perhaps the language here is mixed up. Alternates, as defined > > in the CER/CEA is ONLY for server-initiated messages, and not for > > determining which peer is primary/secondary/alternate. > > OK, let's move aside this primary/secondary/alternate question > and concentrate on the Alternate-Peer AVP thing. > > So, if I understand correctly, this new AVP was introduced > only for the purpose of the Source-Route AVP, am I right? > > So, if I were an administrator of a Diameter proxy, then I > would have to configure the DRT so that messages are > routed based on realms to the next peer. If that peer > fails, messages would be forwarded to another server > from the list defined in the DRT for that realm, right? > Of course, among the list of primary or secondary list > of servers... > > When the answer is returned, and an agent of the list of > Route-Records is down, then it is impossible to route > the answer. That means that the originator of the request > should be expected to re-send the same message. > > For server-initiated messages, if Destination-Realm and > Destination-Host is used, then the same scenario as before > in the last 2 par. is applied. > > For server-initiated messages, if the Source-Route AVPs > are used, then the administrator needs to configure for > the local node a possible list of Alternate-Peers, which > are probably a duplicate information of the list of > servers defined in the DRT entries of the surrounding > nodes, BTW. That is weird to me. Should all Alternate-Peers > be considered as secondary, since they would be used in > case the node fails? I guess yes. I still find this really > messy...maybe because it's friday... > > Note that there should not exist alternates nodes defined > for clients and servers, since > the Alternate-Peer AVP is not used to indicate redundant nodes. > That means that Alternate-Peer AVP should not be used > for servers and clients, as far as I understand. Otherwise, > I don't know why we should be restricted from using it for the > last HOP of the request as well, i.e. Destination-Host? > > > > Here is an idea about the Alternate-Peer... > > The thing is that with the Destination-Realm and Destination-Host > solution, the takeover node was handled by the DRT, which > was returning a list of servers. The only problem was that > nothing could indicate a redundant server or client in the > DRT, since that information should be stored in the Peer > table. I think it is an interesting feature, but different > then the original intention you had. > > So, could't it be used for finding a redundant server or > client host as well? > > I mean that I would prefer seeing clients and servers > use it when they support back-end redundancy between 2 hosts, > e.g. a NAS 1 and NAS 2 are redundant in traffic, which means > that they would use the Alternate-Peer AVP to inform the other > nodes that they are considered as the same node. That would mean > that each node would have to support 2 host-Id. Otherwise, this > AVP should not be used for a client, neither for a Home server. > > The same concept as the one described previously could also > apply to routing the answers, based on Route-Record AVPs. > > With that new definition, the Alternate-Peer could be renamed > Redundant-Peer AVP. > > > > > > > So, as I see it, it is quite a lot of work to support this > > > concept of connections, from a point of view of a Diameter > > > agent and server, at least. Since I am not really sure > > > up to what point agents are expected to have openned > > > connections, I am wondering if this is really something > > > important for Diameter nodes? > > > > Absolutely. However, if you prefer to not include any failover > > code in your implementation, then that's your perogative. > > > > PatC > > From owner-aaa-wg@merit.edu Fri Jul 27 13:10:16 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08536 for ; Fri, 27 Jul 2001 13:10:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6753A9121B; Fri, 27 Jul 2001 13:10:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3133691346; Fri, 27 Jul 2001 13:10:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2CFE59121B for ; Fri, 27 Jul 2001 13:10:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BCFEB5DDB1; Fri, 27 Jul 2001 13:12:13 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3234B5DDAF for ; Fri, 27 Jul 2001 13:12:13 -0400 (EDT) Received: (qmail 9804 invoked by uid 500); 27 Jul 2001 17:10:47 -0000 Date: Fri, 27 Jul 2001 12:10:47 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Another editorial change :( Message-ID: <20010727121047.R820@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk in Section 4.6 of the base protocol, the table ambiguously uses base and derived types. Submitter name: Dave Frascone Submitter email address: dave@frascone.com Date first submitted: July 27th, 2001 Reference: N/A Document: base Comment type: E Priority: 1 Section: Rationale/Explanation of issue: In section 4.6 of the base protocol draft, there is a table of all base protocol AVPs. Most AVPs are only mentioned with their Base types (with the exception of a few IPAddress's). But, further on when the AVPs are described in detail, they mention their derived types. (i.e. section 5.3.7 Product-Id is called a UTF8String) Requested change: Update table in section 4.6 to contain derived types, when applicable. From owner-aaa-wg@merit.edu Fri Jul 27 15:58:29 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25959 for ; Fri, 27 Jul 2001 15:58:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4CC3A9134F; Fri, 27 Jul 2001 15:58:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1BEFB91350; Fri, 27 Jul 2001 15:58:33 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC2A79134F for ; Fri, 27 Jul 2001 15:58:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD0045DDC8; Fri, 27 Jul 2001 16:00:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 40C555DDC0 for ; Fri, 27 Jul 2001 16:00:33 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f6RJu4m00409; Fri, 27 Jul 2001 15:56:04 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma000406; Fri, 27 Jul 01 15:55:55 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f6RJwQB27342; Fri, 27 Jul 2001 15:58:26 -0400 (EDT) Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman via smap (V2.1) id xma027297; Fri, 27 Jul 01 15:57:12 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <3RZSJFW6>; Fri, 27 Jul 2001 15:57:11 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Cc: "'pcalhoun@diameter.org'" Subject: [AAA-WG]: Issue 102: clarification on difference between session and peer c onnection Date: Fri, 27 Jul 2001 15:57:01 -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-wg@merit.edu Precedence: bulk Submitter name: Jacques Caron, Yiwen Jiang Submitter email address: Yiwen.Jiang@tic.siemens.ca Date first submitted: July 27th, 2001 Reference: N/A Document: base Comment type: E Priority: 1 Section: Rationale/Explanation of issue: The relationship between peer-to-peer connection vs. user session was not specified in the base protocol. Requested change: (Below is my first attempt at modifying the initial email that Pat sent out to clairfy such. Maybe we can added in section 8.0.) While peer-to-peer connections is a transport level connection, a user session is a logical concept at the application level. It exists over one or many peer-to-peer connections. +--------+ +-------+ +--------+ | Client | | Relay | | Server | +--------+ +-------+ +--------+ <----------> <----------> peer connection A peer connection B <------------------------------> User session x In the above example, peer connection A is established between the Client and its local Relay. Peer connection B is established between the Relay and the Server. User session x spans from the Client via the Relay to the Server. Each "user" of a service causes an auth request to be sent, with a unique session identifier. Once accepted by the server, both the client and the server are aware of the session. Because of this behaviour, all Diameter clients will need to first initiate a peer-to-peer connection before it can issue user requests to its immediate Diameter peer. All user sessions are "multiplexed" through a single connection. Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-wg@merit.edu Sat Jul 28 20:16:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05493 for ; Sat, 28 Jul 2001 20:16:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2839691234; Sat, 28 Jul 2001 10:21:31 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA69691354; Sat, 28 Jul 2001 10:21:30 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C192891234 for ; Sat, 28 Jul 2001 10:21:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 05A645DD9E; Sat, 28 Jul 2001 10:23:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116]) by segue.merit.edu (Postfix) with ESMTP id 44FC15DD9B for ; Sat, 28 Jul 2001 10:23:32 -0400 (EDT) Received: from viruswall1.entp.attws.com (viruswall1.entp.attws.com [135.214.40.161]) by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id HAA07176; Sat, 28 Jul 2001 07:21:22 -0700 (PDT) Received: from neastmail.entp.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc.) id HAA22562; Sat, 28 Jul 2001 07:21:32 -0700 (PDT) Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192]) by neastmail.entp.attws.com (8.8.8+Sun/8.8.8) with ESMTP id HAA26715; Sat, 28 Jul 2001 07:21:31 -0700 (PDT) Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19) id ; Sat, 28 Jul 2001 10:21:30 -0400 Message-ID: <0D3BDFD96647D211B43A00805F15E5890508695F@ner-msg03.wireless.attws.com> From: "Kobylarz, Thaddeus" To: "'Bernard Aboba'" , aaa-wg@merit.edu Subject: RE: [AAA-WG]: Preliminary AAA WG Agenda for IETF 51 Date: Sat, 28 Jul 2001 10:21:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-wg@merit.edu Precedence: bulk Bernard, Please remove my presentation from the August IETF agenda. Based on 3GPP SA5 progress, the talk would be premature and needs to be postponed to a future meeting. My apologies for the inconvenience. Thad -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Wednesday, July 25, 2001 7:43 PM To: aaa-wg@merit.edu Subject: [AAA-WG]: Preliminary AAA WG Agenda for IETF 51 Based on the agenda requests that have been received, here is a preliminary shot at the agenda for IETF 51. Comments welcome. ================================================================== AAA WG Agenda IETF 51, London, UK Wednesday, August 8, 2001 1300 - 1500 PRELIMINARIES (5 minutes) Agenda bashing Blue sheets Minute takers DIAMETER ISSUES Open Diameter Issues (30 minutes) Pat Calhoun http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt 3G COMMENTS ON DIAMETER Diameter as a 3G Accounting Protocol (10 minutes) Thaddeus Kobylarz 3GPP Comments on Diameter EAP extensions (10 minutes) Peter Howard Ileana Leuca SUPPORT FOR MOBILE IPv6 Franck Le (10 minutes) Diameter support for Mobile IPv6 http://www.ietf.org/internet-drafts/draft-le-aaa-diameter-mobileipv6-00.txt Franck Le (10 minutes) AAA Local Security Association (LSA): The Temporary Shared Key (TSK) http://www.ietf.org/internet-drafts/draft-le-aaa-lsa-tsk-00.txt SUPPORT FOR SIP/HTTP AUTHENTICATION Jari Arkko (10 minutes) HTTP Authentication with EAP http://www.ietf.org/internet-drafts/draft-arkko-http-eap-basic-04.txt Baruch Sterman (10 minutes) Digest Authentication in SIP using RADIUS http://www.ietf.org/internet-drafts/draft-sterman-sip-radius-00.txt Sengodan Senthil (10 minutes) Diameter support for Basic and Digest authentication http://www.ietf.org/internet-drafts/draft-srinivas-aaa-basic-digest-00.txt From owner-aaa-wg@merit.edu Sun Jul 29 23:43:19 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14516 for ; Sun, 29 Jul 2001 23:43:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1F8069120A; Sun, 29 Jul 2001 23:43:02 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E599F9120C; Sun, 29 Jul 2001 23:43:01 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C505B9120A for ; Sun, 29 Jul 2001 23:43:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E72225DD99; Sun, 29 Jul 2001 23:45:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3BC025DDE4 for ; Sun, 29 Jul 2001 23:45:06 -0400 (EDT) Received: (qmail 3527 invoked by uid 500); 30 Jul 2001 03:43:37 -0000 Date: Sun, 29 Jul 2001 22:43:36 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Another editorial change :( Message-ID: <20010729224336.A3514@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu References: <20010727121047.R820@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010727121047.R820@newman.frascone.com>; from dave@frascone.com on Fri, Jul 27, 2001 at 12:10:47PM -0500 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Sorry there is no number yet. I'm not sure how to get one. But, here is a list of the table changes, and one other question (perhaps it should be a different issue?) Section 4.6: AVP table Accounting-Record-Number should be Unsigned32 Acct-Application-Id should be Unsigned32 Alternate-Peer should be DiameterIdentity Auth-Application-Id should be Unsigned32 Destination-Host should be DiameterIdentity Destination-Realm should be UTF8String Error-Message should be UTF8String Error-Reporting-Host should be DiameterIdentity Origin-Host should be DiameterIdentity Origin-Realm should be UTF8String Product-Name should be UTF8String Proxy-Host should be DiameterIdentity Redirect-Host should be DiameterIdentity Route-Record should be DiameterIdentity Session-Id should be UTF8String Source-Route should be DiameterIdentity Also, since it seems like things are in alphabetical order, Session-Binding should come before Session-Id And finally, should Vendor-Id be considered Enumerated? In the ethereal packet dissector, I've switched it to enumerated, so it can attempt to look up the vendor-id in it's VERY limited table. -Dave On Fri, Jul 27, 2001 at 12:10:47PM -0500, David Frascone wrote: > > in Section 4.6 of the base protocol, the table ambiguously uses base and > derived types. > > Submitter name: Dave Frascone > Submitter email address: dave@frascone.com > Date first submitted: July 27th, 2001 > Reference: N/A > Document: base > Comment type: E > Priority: 1 > Section: > Rationale/Explanation of issue: > > In section 4.6 of the base protocol draft, there is a table of all base > protocol AVPs. Most AVPs are only mentioned with their Base types (with > the exception of a few IPAddress's). But, further on when the AVPs are > described in detail, they mention their derived types. (i.e. section 5.3.7 > Product-Id is called a UTF8String) > > Requested change: > > Update table in section 4.6 to contain derived types, when applicable. > From owner-aaa-wg@merit.edu Mon Jul 30 08:38:22 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19731 for ; Mon, 30 Jul 2001 08:38:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5FBB91247; Mon, 30 Jul 2001 08:38:27 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ABB7C91248; Mon, 30 Jul 2001 08:38:27 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AEA591247 for ; Mon, 30 Jul 2001 08:38:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 770785DD92; Mon, 30 Jul 2001 08:40:33 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id 040E25DD8E for ; Mon, 30 Jul 2001 08:40:33 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f6UCa0p14351; Mon, 30 Jul 2001 08:36:00 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma014349; Mon, 30 Jul 01 08:35:45 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f6UCcGC18839; Mon, 30 Jul 2001 08:38:16 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma018798; Mon, 30 Jul 01 08:37:39 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <3RZSJG4P>; Mon, 30 Jul 2001 08:37:35 -0400 Message-ID: From: Yiwen Jiang To: "'aaa-wg@merit.edu'" Cc: "'pcalhoun@diameter.org'" Subject: [AAA-WG]: Issue 101: More description on Session state machine Date: Mon, 30 Jul 2001 08:37:30 -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-wg@merit.edu Precedence: bulk Hi there, Issue 101 that I submitted didn't seem to pop up on the list. So here it is. -----Original Message----- From: Yiwen Jiang Sent: Friday, July 27, 2001 3:30 PM To: 'aaa-wg@merit.edu' Subject: Issue 101: More description on Session state machine Submitter name: Yiwen Jiang Submitter email address: Yiwen.Jiang@tic.siemens.ca Date first submitted: July 27th, 2001 Reference: N/A Document: base Comment type: E Priority: 1 Section: 8.1 and 8.2 Rationale/Explanation of issue: In Section 8.1 and 8.2, there is only a description of the Authentication state machine without any explaination on what the states actually means. In addition, the last line of the state machine, "New State" was not specified. Requested change: Some text should be added in describing the individual states mentioned, similar to the sections after the peer state machine. Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-wg@merit.edu Mon Jul 30 10:00:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22706 for ; Mon, 30 Jul 2001 10:00:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53EBF9124F; Mon, 30 Jul 2001 10:00:13 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 728459124E; Mon, 30 Jul 2001 10:00:12 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5E9729124C for ; Mon, 30 Jul 2001 10:00:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7331F5DDEC; Mon, 30 Jul 2001 10:02:16 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id D8C0C5DD8E for ; Mon, 30 Jul 2001 10:02:15 -0400 (EDT) Received: (qmail 4024 invoked by uid 500); 30 Jul 2001 13:49:31 -0000 Date: Mon, 30 Jul 2001 06:49:31 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Another editorial change :( Message-ID: <20010730064931.A4017@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu References: <20010727121047.R820@newman.frascone.com> <20010729224336.A3514@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010729224336.A3514@newman.frascone.com>; from dave@frascone.com on Sun, Jul 29, 2001 at 10:43:36PM -0500 Sender: owner-aaa-wg@merit.edu Precedence: bulk I assign the numbers when I integrate the issue into the web page. I am a little behind, but will catch up by the end of the day. If you could, though, file an official issue (format and [issue] in the subject), that would make it easier for me. Thanks, PatC On Sun, Jul 29, 2001 at 10:43:36PM -0500, David Frascone wrote: > Sorry there is no number yet. I'm not sure how to get one. But, here > is a list of the table changes, and one other question (perhaps it should > be a different issue?) > > Section 4.6: AVP table > > Accounting-Record-Number should be Unsigned32 > Acct-Application-Id should be Unsigned32 > Alternate-Peer should be DiameterIdentity > Auth-Application-Id should be Unsigned32 > Destination-Host should be DiameterIdentity > Destination-Realm should be UTF8String > Error-Message should be UTF8String > Error-Reporting-Host should be DiameterIdentity > Origin-Host should be DiameterIdentity > Origin-Realm should be UTF8String > Product-Name should be UTF8String > Proxy-Host should be DiameterIdentity > Redirect-Host should be DiameterIdentity > Route-Record should be DiameterIdentity > Session-Id should be UTF8String > Source-Route should be DiameterIdentity > > Also, since it seems like things are in alphabetical order, > Session-Binding should come before Session-Id > > And finally, should Vendor-Id be considered Enumerated? In the ethereal > packet dissector, I've switched it to enumerated, so it can attempt to > look up the vendor-id in it's VERY limited table. > > > -Dave > > On Fri, Jul 27, 2001 at 12:10:47PM -0500, David Frascone wrote: > > > > in Section 4.6 of the base protocol, the table ambiguously uses base and > > derived types. > > > > Submitter name: Dave Frascone > > Submitter email address: dave@frascone.com > > Date first submitted: July 27th, 2001 > > Reference: N/A > > Document: base > > Comment type: E > > Priority: 1 > > Section: > > Rationale/Explanation of issue: > > > > In section 4.6 of the base protocol draft, there is a table of all base > > protocol AVPs. Most AVPs are only mentioned with their Base types (with > > the exception of a few IPAddress's). But, further on when the AVPs are > > described in detail, they mention their derived types. (i.e. section 5.3.7 > > Product-Id is called a UTF8String) > > > > Requested change: > > > > Update table in section 4.6 to contain derived types, when applicable. > > From owner-aaa-wg@merit.edu Mon Jul 30 10:20:24 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23644 for ; Mon, 30 Jul 2001 10:20:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CD8489124E; Mon, 30 Jul 2001 10:20:17 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9531591250; Mon, 30 Jul 2001 10:20:17 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8903B9124E for ; Mon, 30 Jul 2001 10:20:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD7C05DDDD; Mon, 30 Jul 2001 10:22:23 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 6A2E65DDA0 for ; Mon, 30 Jul 2001 10:22:23 -0400 (EDT) Received: (qmail 4209 invoked by uid 500); 30 Jul 2001 14:09:39 -0000 Date: Mon, 30 Jul 2001 07:09:39 -0700 From: Pat Calhoun To: aaa-wg@merit.edu Subject: [AAA-WG]: Getting an Issue Number Message-ID: <20010730070939.I4017@charizard.diameter.org> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-aaa-wg@merit.edu Precedence: bulk All, I've received a couple of requests on how one gets an Issue number. Some folks just pick the next available number, and in some cases this works (e.g. when no conflicts occur). The best way, though, is simply to submit an issue, and let me assign it a number when I enter it on the web page. I am normally quick about adding issues to the web page, expect the past couple of days. I believe that only the issues filed on Friday are missing from the web page, and I'll take care of those today. PatC From owner-aaa-wg@merit.edu Mon Jul 30 10:24:58 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23973 for ; Mon, 30 Jul 2001 10:24:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3DD1791250; Mon, 30 Jul 2001 10:24:53 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0DB5391251; Mon, 30 Jul 2001 10:24:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DDC0791250 for ; Mon, 30 Jul 2001 10:24:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 168B95DDDD; Mon, 30 Jul 2001 10:26:58 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 43EE15DDA0 for ; Mon, 30 Jul 2001 10:26:57 -0400 (EDT) Received: from fredrikj (sierra.local.ipunplugged.com [192.168.4.88]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA09737; Mon, 30 Jul 2001 16:27:04 +0200 From: "Fredrik Johansson" To: "AAA Listan" Cc: Subject: [AAA-WG]: Issue 103: More editorial comments Date: Mon, 30 Jul 2001 16:26:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Submitter name: Fredrik Johansson Submitter email address: fredrik@ipunplugged.com Date first submitted: July 30th, 2001 Reference: N/A Document: base Comment type: E Priority: 1 Section: Rationale/Explanation of issue: Some of these comments may be duplicates of earlier posted issues, I've tried to find them but might have missed a few. Section 1.1 Last sentence "An example of an unsolicited message would be for a request that the client issues an accounting update" If I'm not misstaken that feature was removed, if so, use another example e.g. "... for a request that the client re-authenticate" Section 1.3 Reference in the NAI should be 8 instead of 3. Section 2.1 3rd paragraph, replies MAY any -> replies MAY be any Section 2.3.2 "Note that new AVPS to be used with an existing application MUST NOT be defined to have the 'M'andatory bit set." is contradictory with section 2.4 "An implementation MAY add arbitrary AVPs to any command defined in an application, including vendor-specific AVPs. However, implementations that add such AVPs with the Mandatory 'M' bit set are not compliant, and are at fault if the peer rejects the request." remove sentence in 2.3.2 Section 2.6 - Status. This is the state of the peer entry, and MUST match one of the values listed in section 5.6. Do you mean the values in 5.5.3? Section 3.0 E(error) - If set, the message contains a protocol error Just a protocol error, why not any error? Section 4.4 "If no rule matches, the packet is dropped if the last rule evaluated was a permit, and passed if the last rule was a deny." To me it seems a bit strange that what to do with the packet should be determined by the last rule evaluated even if it doesn't match that rule. Even more strange when you decide to pass the packet based on the fact that the last rule was a deny even if it didn't match. But that might be the correct behavior for ipf, just wanted to point this out to see if someone who perhaps knows more about this reacts to it. Section 4.5 "All AVPs included in a Grouped AVP Every Grouped AVP defined MUST include a corresponding grammar, using ABNF [31] (with modifications), as defined below." Strange sentence. Section 6.1.4 "A request is known to be for local consumption when one of the following conditions occur: - The Destination-Host AVP contains the local host's identity, - The Destination-Host AVP is not present, the Destination-Realm AVP contains a realm the server is configured to process locally, and the Diameter application is locally supported, or - The Destination-Realm AVP is not present." If the Destination-Host AVP contains a non local host identity and the Destination-Realm AVP is missing this will evaluate to be a request for local consumption. But on the other hand, a request with a Destiantion-Host AVP and without a Destination-Realm AVP is considered wrong, right?!? Section 6.3 Might want to clearify that the route records removed must be saved with the pending request so that they can be restored when answering. Section 7.0 "Figure 8 provides an example of a Diameter message that caused an application error. When application errors occur, the Diameter entity reporting the error clears the 'R' bit in the Command Flags, and adds the Result-Code AVP with the proper value. Application errors do not require any proxy or relay agent involvement, and therefore the message would be forwarded back to the originator of the request. Should one realy return the whole request but with the 'R'-bit cleared and a result code AVP? Why not have the same abnf for all errors, the request that caused the error is stored as pending anyway. Set the 'E'-bit and return the abnf specified in section 7.2. Section 7.2. {Destination-Host AVP} if I'm not misstaken, this avp should never be present in any answers. Section 8.4 " When a user session that required Diameter authorization terminates, the access device that provided the service MUST issue a Session- Termination- Request (STR) message to the Diameter server that authorized the service, to notify it that the session is no longer active. An STR MUST be issued when a user session terminates for any reason, including user logoff, expiration of Session-Timeout, administrative action, termination upon receipt of an Abort-Session- Request (see below), orderly shutdown of the access device, etc." add something like: "unless an Auth-Session-State AVP was received set to 'NO_STATE_MAINTAINED'." Section 8.9 Authorization Lifetime is of type Unsigned32, i.e. it can never become a negative number remove the (-1) or change the number. Section 8.11 It's not clear that it's the answer from the server that should be applied, even if it's stated in section 8.0 Section 10.1 Could you send a Class AVP in a DWR? it's marked as 0+ in the table. Can't all answers have a Failed AVP? That's all for now, /Fredrik From owner-aaa-wg@merit.edu Mon Jul 30 16:44:10 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23249 for ; Mon, 30 Jul 2001 16:44:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 56BAF9125A; Mon, 30 Jul 2001 16:44:54 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 228709125B; Mon, 30 Jul 2001 16:44:54 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 288C69125A for ; Mon, 30 Jul 2001 16:44:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0E2345DDF8; Mon, 30 Jul 2001 16:44:53 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 614285DDE3 for ; Mon, 30 Jul 2001 16:44:52 -0400 (EDT) Received: (qmail 29461 invoked by uid 500); 30 Jul 2001 20:44:51 -0000 Date: Mon, 30 Jul 2001 15:44:51 -0500 From: David Frascone To: diameter@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Ethereal Support for Diameter -07 Message-ID: <20010730154451.L16530@newman.frascone.com> Mail-Followup-To: diameter@diameter.org, aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Ethereal now supports the Diameter Base Protocol as defined in http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt It does *not* support any extensions yet, but will soon. (It *will* dissect the packets, but will not print the names of the command codes or attributes that are not defined in the diameter baese protocol) You can get the new dissector from http://www.ethereal.com. You will have to download the changes directly from CVS until a nightly snapshot is built. Changes (besides -07 support): o Diameter Header and AVP flags are now parsed like flags in other dissectors. (It looks much nicer now) o Replaced large dictionary with a VERY compact one. (A large XML dictionary will be implemented soon.) Please let me know if you have any problems with it. -Dave From owner-aaa-wg@merit.edu Tue Jul 31 10:58:59 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19575 for ; Tue, 31 Jul 2001 10:58:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF7E09128C; Tue, 31 Jul 2001 10:53:46 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D2E669128B; Tue, 31 Jul 2001 10:53:44 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30DA39128C for ; Tue, 31 Jul 2001 10:53:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 104215DDDD; Tue, 31 Jul 2001 10:53:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by segue.merit.edu (Postfix) with ESMTP id A29175DDDB for ; Tue, 31 Jul 2001 10:53:30 -0400 (EDT) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Tue, 31 Jul 2001 15:53:23 +0100 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-32) id PAA17274; Tue, 31 Jul 2001 15:53:24 +0100 (BST) Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 80256A9A.0051ACEE ; Tue, 31 Jul 2001 15:52:06 +0100 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Valeria Garello" To: aaa-wg@merit.edu Message-ID: <80256A9A.00518A10.00@marconicomms.com> Date: Tue, 31 Jul 2001 16:50:02 +0200 Subject: [AAA-WG]: RADIUS Authentication Server IP address Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-aaa-wg@merit.edu Precedence: bulk Hi all, I've just recently subscribed to the AAA working group and I've some questions about RADIUS Authentication. We are going to implement the Radius Authentication Client MIB from RFC2618 and I've seen that the RADIUS Server IP address is READ-ONLY in that MIB: 1) What is the reason for that ? How should an SNMP manager tell to the RADIUS client the IP address of its RADIUS servers ? Which MIB should we implement in order to have the RADIUS Server IP address settable from an SNMP manager ? Is it not reasonable for an SNMP manager to set the Radius servers IP address into the RADIUS client ? 2) How comes that radiusAuthServerTable is indexed by an integer (ra diusAuthServerIndex) and not by an IP address (i.e. radiusAuthServerAddress) ? In my opinion it would be more usable for an SNMP manager to retrieve an entry in that table by using as an index the RADIUS Server IP address instead of a simple integer, that would force the SNMP manager to read first the entire table in order to find out all the indexes. Thank you and regards Valeria Garello From owner-aaa-wg@merit.edu Tue Jul 31 11:00:48 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19691 for ; Tue, 31 Jul 2001 11:00:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 944D99124A; Tue, 31 Jul 2001 11:00:47 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 50CEF91203; Tue, 31 Jul 2001 11:00:47 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 47B479124A for ; Tue, 31 Jul 2001 11:00:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F19C25DDE3; Tue, 31 Jul 2001 11:00:34 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4BF125DDDD for ; Tue, 31 Jul 2001 11:00:34 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id HAA89587; Tue, 31 Jul 2001 07:50:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 31 Jul 2001 07:50:56 -0700 (PDT) From: Bernard Aboba To: Valeria Garello Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: RADIUS Authentication Server IP address In-Reply-To: <80256A9A.00518A10.00@marconicomms.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk This is the mailing list of the AAA WG, which is focussed on standardizing the Diameter protocol. Questions relating to RADIUS are off-topic, except as they relate to the design of Diameter. Please take these issues to the RADIUS WG mailing list, available at ietf-radius@livingston.com. From owner-aaa-wg@merit.edu Tue Jul 31 11:20:11 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20971 for ; Tue, 31 Jul 2001 11:20:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4C9AC9127A; Tue, 31 Jul 2001 11:18:52 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1FF8F91268; Tue, 31 Jul 2001 11:18:52 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 360059127D for ; Tue, 31 Jul 2001 11:18:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A2635DDE3; Tue, 31 Jul 2001 11:18:45 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 74CB95DDDA for ; Tue, 31 Jul 2001 11:18:44 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id IAA89621 for ; Tue, 31 Jul 2001 08:09:13 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 31 Jul 2001 08:09:12 -0700 (PDT) From: Bernard Aboba To: aaa-wg@merit.edu Subject: [AAA-WG]: Reminder: Issue submission and status tracking Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk Just a reminder on how to submit issues and track their status of issues. Pat Calhoun is maintaining a Diameter issues web page at: http://www.diameter.org/issues.html As soon as you obtain an issue # and submit an issue (ask Pat for an issue #, please don't just make up your own), your issue will be tracked on the issue web page. There are categories for open issues as well as resolved issues. If for some reason the resolution of an issue is not satisfactory, please speak up and it will be reopened. Note that this issue tracking page will be used to track the issues for *all* drafts currently in WG last call. That includes: http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-nasreq-07.txt http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-04.txt If you haven't read *all* of these drafts, there is no better time to do this than right now! AAA WG Issue Template To file an issue with one of the AAA WG specifications, you first need to obtain an issue # from Pat Calhoun . After obtaining the issue number, fill in the template below, and send it to aaa-wg@merit.edu, with "[issue] XXX" pre-pended to the subject line. ================================================================ Submitter name: Submitter email address: Date first submitted: Reference: Document: Comment type: E=Editorial, T=Technical Priority: 1=showstopper, 2=Should fix, 3=low priority Section: Rationale/Explanation of issue: Requested change: From owner-aaa-wg@merit.edu Tue Jul 31 13:24:49 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01743 for ; Tue, 31 Jul 2001 13:24:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 661849127D; Tue, 31 Jul 2001 13:25:32 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3D7191280; Tue, 31 Jul 2001 13:25:31 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B6EB19127D for ; Tue, 31 Jul 2001 13:25:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9A9665DDE5; Tue, 31 Jul 2001 13:25:30 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 10B635DDED for ; Tue, 31 Jul 2001 13:25:30 -0400 (EDT) Received: (qmail 14351 invoked by uid 500); 31 Jul 2001 17:25:29 -0000 Date: Tue, 31 Jul 2001 12:25:29 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 106 - More changes to table in Section 4.6 Message-ID: <20010731122529.Y16530@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Dave Frascone Submitter email address: dave@frascone.com Date first submitted: 31-JUL-2001 Reference: Document: Base Comment type: E Priority: 1 Section: 4.6 Rationale/Explanation of issue: Ok, I think this is the last of my complaints about Section 4.6 :) I think all AVPS should have all flags defined in the table. For example, since Acct-Application-Id no long has a P bit in the "may" column, should we assume that it is a "must-not" now? I think the ambiguity needs to be cleaned up and all three bits need to be present under a colum for all AVPs Requested change: Include all three bits under a column in the table. From owner-aaa-wg@merit.edu Tue Jul 31 14:23:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05929 for ; Tue, 31 Jul 2001 14:23:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B33291287; Tue, 31 Jul 2001 14:24:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AD9291289; Tue, 31 Jul 2001 14:24:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52AC391287 for ; Tue, 31 Jul 2001 14:24:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3518D5DDF1; Tue, 31 Jul 2001 14:24:22 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by segue.merit.edu (Postfix) with ESMTP id E03BE5DDE9 for ; Tue, 31 Jul 2001 14:24:21 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6VIOLp22098 for ; Tue, 31 Jul 2001 13:24:21 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6VIOLi08989 for ; Tue, 31 Jul 2001 13:24:21 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA18820 for ; Tue, 31 Jul 2001 13:24:20 -0500 (CDT) Received: from ericsson.com ([138.85.159.113]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA17746 for ; Tue, 31 Jul 2001 13:24:17 -0500 (CDT) Message-ID: <3B66F653.69B205E8@ericsson.com> Date: Tue, 31 Jul 2001 11:17:55 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: More editorial comments Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: July 31th, 2001 Reference: N/A Document: base Comment type: E Priority: 2 Section: Rationale/Explanation of issue: Page 12, section 2.0, 2nd paragraph: “The CMS Diameter security application [11]…” should be The Diameter CMS security application [11]….” Page 16, section 2.5: "The following Application Identifier values are defined: NASREQ 1 [7] End-to-End Security 2 [11] Mobile-IP 4 [10] Relay 0xffffffff" For consistency the End-to-End Security should be changed to CMS security. Page 12, section 2.0, 2nd paragraph: The two bullets say almost the same thing. So what about deleting the first sentence in bullet 1 and start with “1. A set of AVPs are defined to sign and encrypt AVPs…” and keep bullet 2 as is. Page 68, section 6.2.2, 3rd and 4th paragraph: “If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. The agent MUST then send the answer to the host which it received the original request from.” The above paragraph needs to better clarify what the relay/proxy agent sends back to the access device. Suggested change: “If the agent receives an answer message with a Result-Code AVP indicating success, and it wishes to modify the AVP to indicate an error, it MUST issue an STR on behalf of the access device. The agent MUST then send the answer to the access device with the modified Result-Code AVP indicating the error and MUST also add the Error-Reporting-Host AVP, which will contain the identity of this agent.” Page 78, section 7.1.5,4th paragraph from the bottom: ”DIAMETER_NO_COMMON_APPLICATION 5012 This error is returned when a CEA message…” should be “This error is returned when a CER message…” From owner-aaa-wg@merit.edu Tue Jul 31 15:58:46 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16545 for ; Tue, 31 Jul 2001 15:58:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 15BAE91313; Tue, 31 Jul 2001 15:59:33 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB30C91314; Tue, 31 Jul 2001 15:59:32 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DBAE691313 for ; Tue, 31 Jul 2001 15:59:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAE615DDFB; Tue, 31 Jul 2001 15:59:31 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 7365C5DDFA for ; Tue, 31 Jul 2001 15:59:31 -0400 (EDT) Received: (qmail 15691 invoked by uid 500); 31 Jul 2001 19:59:30 -0000 Date: Tue, 31 Jul 2001 14:59:29 -0500 From: David Frascone To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue 108: Errata in Mobile-Ip Application Message-ID: <20010731145929.A15635@newman.frascone.com> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Submitter name: Dave Frascone Submitter email address: dave@frascone.com Date first submitted: 31-JUL-2001 Reference: Document: Mobile-Ip Comment type: E Priority: 1 Section: 4.0, Throughout Rationale/Explanation of issue: Editorial errata. Requested change: In Section 4.0: MIP-Filter-Rule type should be IPFilterRule. MIP-Foreign-Agent-Host type should be DiameterIdentity. MIP-Previous-FA-Host type should be DiameterIdentity. Throughout: There is no "FilterRule" type. It should be "IPFilterRule" From owner-aaa-wg@merit.edu Tue Jul 31 16:06:15 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17316 for ; Tue, 31 Jul 2001 16:06:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C47DB9127B; Tue, 31 Jul 2001 16:06:51 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8E33B91282; Tue, 31 Jul 2001 16:06:51 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FC499127B for ; Tue, 31 Jul 2001 16:06:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 508935DDFC; Tue, 31 Jul 2001 16:06:50 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130]) by segue.merit.edu (Postfix) with ESMTP id A14A65DDFB for ; Tue, 31 Jul 2001 16:06:49 -0400 (EDT) Received: (from mail@localhost) by ahab.tic.siemens.ca (8.11.4/8.11.4) id f6VK4FA28801; Tue, 31 Jul 2001 16:04:15 -0400 (EDT) X-Authentication-Warning: ahab.tic.siemens.ca: mail set sender to using -f Received: from (mailman [172.21.24.8]) by ahab via smap (V2.1) id xma028799; Tue, 31 Jul 01 16:03:58 -0400 Received: (from root@localhost) by mailman.innovation.siemens.ca (8.11.4/8.11.4) id f6VK6Vo27844; Tue, 31 Jul 2001 16:06:31 -0400 (EDT) Received: from (ticsmtp1.innovation.siemens.ca [172.21.24.34]) by mailman via smap (V2.1) id xma027741; Tue, 31 Jul 01 16:05:43 -0400 Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21) id <3RZSJ2GJ>; Tue, 31 Jul 2001 16:05:37 -0400 Message-ID: From: Yiwen Jiang To: "'diameter@diameter.org'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Diameter API changes? Date: Tue, 31 Jul 2001 16:05:32 -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-wg@merit.edu Precedence: bulk Hi there, I'm not sure if anyone has looked into this, we would need a new signature for AAANewMessage for the API to support the error bit now. Also, since Extension-Id is removed, the functions that reference Extension-Id has to be changed as well in the API, wouldn't it? Will -05 have support these changes? Thanks! Cheers, Yiwen --- Yiwen Jiang Mobile IP Networking Email: Yiwen.Jiang@tic.siemens.ca Phone: (613)271-7710 Telecom Innovation Centre 505 March Road Kanata, Ontario, Canada K2K 2M5 From owner-aaa-wg@merit.edu Tue Jul 31 16:31:40 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19317 for ; Tue, 31 Jul 2001 16:31:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5FDD591282; Tue, 31 Jul 2001 16:32:23 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 33AF89128D; Tue, 31 Jul 2001 16:32:23 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 198B891282 for ; Tue, 31 Jul 2001 16:32:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E7E835DDF4; Tue, 31 Jul 2001 16:32:06 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3EA285DD9C for ; Tue, 31 Jul 2001 16:32:06 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id NAA90070; Tue, 31 Jul 2001 13:22:05 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Tue, 31 Jul 2001 13:22:05 -0700 (PDT) From: Bernard Aboba To: "Shahrier, Sharif M." Cc: "'david@mitton.com'" , "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Re: FW: Billing requirements for MIPv6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-wg@merit.edu Precedence: bulk The Diameter Protocol includes support for the accounting functionality outlined in RFC 2989 and 2975. I believe that this includes sufficient features for handling accounting in Mobile IPv6. If this is not the case, please file an issue against the Diameter specifications. From owner-aaa-wg@merit.edu Tue Jul 31 16:52:05 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20748 for ; Tue, 31 Jul 2001 16:52:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9F04791296; Tue, 31 Jul 2001 16:52:45 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66937912A0; Tue, 31 Jul 2001 16:52:45 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6338191296 for ; Tue, 31 Jul 2001 16:52:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44FE95DDFB; Tue, 31 Jul 2001 16:52:43 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220]) by segue.merit.edu (Postfix) with SMTP id 441455DDFD for ; Tue, 31 Jul 2001 16:52:42 -0400 (EDT) Received: (qmail 15621 invoked by uid 500); 31 Jul 2001 20:41:48 -0000 Date: Tue, 31 Jul 2001 13:41:48 -0700 From: Pat Calhoun To: Bernard Aboba Cc: "Shahrier, Sharif M." , "'david@mitton.com'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Re: FW: Billing requirements for MIPv6 Message-ID: <20010731134148.J6031@charizard.diameter.org> Mail-Followup-To: Bernard Aboba , "Shahrier, Sharif M." , "'david@mitton.com'" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aboba@internaut.com on Tue, Jul 31, 2001 at 01:22:05PM -0700 Sender: owner-aaa-wg@merit.edu Precedence: bulk On Tue, Jul 31, 2001 at 01:22:05PM -0700, Bernard Aboba wrote: > The Diameter Protocol includes support for the accounting functionality > outlined in RFC 2989 and 2975. I believe that this includes sufficient > features for handling accounting in Mobile IPv6. > > If this is not the case, please file an issue against the Diameter > specifications. Please keep in mind that the issue should be applied against the base protocol, not the Mobile IP application. There is separate work ongoing on defining the Mobile IPv6 application. PatC From owner-aaa-wg@merit.edu Tue Jul 31 17:04:12 2001 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21770 for ; Tue, 31 Jul 2001 17:04:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D64D591316; Tue, 31 Jul 2001 17:01:16 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFC609131A; Tue, 31 Jul 2001 17:01:13 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A53EE91316 for ; Tue, 31 Jul 2001 17:00:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 871D55DDFA; Tue, 31 Jul 2001 17:00:24 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from frascone.com (unknown [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id E6CCC5DD9C for ; Tue, 31 Jul 2001 17:00:23 -0400 (EDT) Received: (qmail 16203 invoked by uid 500); 31 Jul 2001 21:00:23 -0000 Date: Tue, 31 Jul 2001 16:00:23 -0500 From: David Frascone To: Yiwen Jiang Cc: "'diameter@diameter.org'" , "'aaa-wg@merit.edu'" Subject: Re: [AAA-WG]: Diameter API changes? Message-ID: <20010731160023.C15635@newman.frascone.com> Mail-Followup-To: Yiwen Jiang , "'diameter@diameter.org'" , "'aaa-wg@merit.edu'" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Yiwen.Jiang@tic.siemens.ca on Tue, Jul 31, 2001 at 04:05:32PM -0400 X-encrypt-payload: no Sender: owner-aaa-wg@merit.edu Precedence: bulk Yes, it does need to be brought up to date. I'll start working on it soon. On Tue, Jul 31, 2001 at 04:05:32PM -0400, Yiwen Jiang wrote: > Hi there, > > I'm not sure if anyone has looked into this, we would need a new signature > for AAANewMessage for the API to support the error bit now. > > Also, since Extension-Id is removed, the functions that reference > Extension-Id has to be changed as well in the API, wouldn't it? > > Will -05 have support these changes? > > Thanks! > > Cheers, > Yiwen > --- > Yiwen Jiang > Mobile IP Networking > Email: Yiwen.Jiang@tic.siemens.ca > Phone: (613)271-7710 > > Telecom Innovation Centre > 505 March Road > Kanata, Ontario, Canada > K2K 2M5 > From owner-aaa-wg@merit.edu Tue Jul 31 17:57:19 2001 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25381 for ; Tue, 31 Jul 2001 17:57:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9824D91319; Tue, 31 Jul 2001 17:55:10 -0400 (EDT) Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F4DC9131A; Tue, 31 Jul 2001 17:55:10 -0400 (EDT) Delivered-To: aaa-wg@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADE4D91319 for ; Tue, 31 Jul 2001 17:55:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E13D5DDF8; Tue, 31 Jul 2001 17:55:07 -0400 (EDT) Delivered-To: aaa-wg@merit.edu Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by segue.merit.edu (Postfix) with ESMTP id 1E7735DDD3 for ; Tue, 31 Jul 2001 17:55:07 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.92.13]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6VLt7512494 for ; Tue, 31 Jul 2001 16:55:07 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f6VLt6i26913 for ; Tue, 31 Jul 2001 16:55:06 -0500 (CDT) Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA29091 for ; Tue, 31 Jul 2001 16:55:06 -0500 (CDT) Received: from ericsson.com ([138.85.159.113]) by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA20398 for ; Tue, 31 Jul 2001 16:55:03 -0500 (CDT) Message-ID: <3B6727B8.DC40C09A@ericsson.com> Date: Tue, 31 Jul 2001 14:48:40 -0700 From: Tony Johansson X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: aaa-wg@merit.edu Subject: [AAA-WG]: Issue: Request for a new AVP called Missing-AVP Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-aaa-wg@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Submitter name: Tony Johansson Submitter email address: tony.johansson@ericsson.com Date first submitted: July 31th, 2001 Reference: N/A Document: base Comment type: T Priority: 2 Section: 7.1.5 Rationale/Explanation of issue: Page 77, section 7.1.5: ” DIAMETER_MISSING_AVP 5006 The request did not contain an AVP that is required by the Command Code definition. If this value is sent in the Result- Code AVP, a Failed-AVP AVP SHOULD be included in the message. The Failed-AVP AVP MUST contain an example of the missing AVP” To reduce the amount of processing in the event of a missing AVP it would be better not have to create the "missing AVP" and add it in a Failed-AVP. A simpler approach would be to define a new AVP called Missing–AVP, which just includes the AVP code of the missing AVP. Requested change: 7.6 Missing-AVP AVP The Missing-AVP (AVP Code XXX) is of type unsigned32 and contains the AVP code of the missing AVP. This AVP MUST be added in an answer where the Result Code-AVP is set to DIAMETER_MISSING_AVP. There could be multiple Missing-AVP AVPs added in an answer, in cases where more than one AVP is missing.